01Lifecycle systems
Aven Hospitality
- Role
- E-commerce Customer Engagement Lead
- Dates
- August 2025 – Present
- Location
- New York City metro
I own customer engagement for Aven’s retail business: an account base of 1,000+ customers scaling toward 4,000, and end-to-end product account ownership on the SynXis Retailing platform — storefront architecture, SKU strategy, platform configuration, merchandising and pricing.
Three systems sit underneath that work. They are one method, not three projects. Each one starts with a diagnostic of how the work actually happens, converts that diagnosis into a data-backed model, and then designs an automated, measurable system around it.
$1M+
Customer retail revenue
85%
Year-over-year growth across 80 medium-to-high-maturity hotel properties
113% including two accounts run with a colleague
1,000+
Customer account base, scaling toward 4,000
Dynamic Messaging
Lifecycle marketing automation
Client outreach was designed by hand every iteration, with no reusable template system, no scheduling, and no analytics layer at all.
~20%
action completion rate across 7 playbooks, reaching the full 1,000+ account base
I mapped the five-step process end to end, then built a library of campaign themes, each tied to a trigger condition, a commercial purpose and a decision-maker persona — so choosing who receives what became a data rule rather than a judgment call.
It gave the channel its first engagement-measurement capability, and I am named as the designated owner of this workstream in the annual marketing plan.
Read the approach
Problem
Client outreach was designed by hand every iteration. There was no reusable template system, so design-to-email conversion came out inconsistent and needed manual code correction each cycle. Data was merged by hand, nothing was scheduled, and sends went out individually — which capped volume at a handful of recipients. There was no analytics layer at all: no engagement signal, and no way to prove the channel returned anything.
Approach
I mapped the existing five-step process end to end, capturing the time cost and the failure mode at each step. Then I ran a structured tooling evaluation against the criteria that actually mattered for this use case — HTML design control, dynamic content injection at send time, scheduling, audience data handling, engagement tracking, and cost at scale — and produced a written recommendation with a modelled cost structure behind it.
Before scaling it, I designed and ran a structured feedback exercise with pilot recipients across multiple regions. Two questions needed answering: whether the benchmark framing changed how they thought about their own performance, and whether the recommendations were directional enough to act on.
I then built a library of campaign themes. Each theme maps to a trigger condition, a commercial purpose and a decision-maker persona, so choosing who receives what became a data rule rather than a judgment call.
What it produced
The seven playbooks cover account health, reactivation, category expansion, content quality and bundling.
Every send analyses a client’s own commercial performance, benchmarks it against an anonymized peer cohort, and closes with one specific action. The designs are built and converted to production HTML, with cross-client rendering resolved.
Dynamic Reporting
Productized performance analytics
Every KPI carries a definition, threshold-based logic and a recommendation for each performance band — and I derived those bands from actual distribution percentiles within comparable cohorts rather than arbitrary cutoffs, so every recommendation is statistically defensible.
Performance data existed, but nobody was turning it into a narrative a commercial leader could act on, and bespoke per-client reporting could not scale.
An ad-hoc analytical exercise became a defined, repeatable product: a recommendation engine that scales prescription without scaling analyst time. I authored the internal reference that defines the distinction between the two products for commercial teams.
Read the approach
Problem
Performance data existed, but it was not organized into a narrative any commercial leader could act on. Reporting was bespoke and effort-intensive per client, which made it impossible to deliver across an account base of this size. Insight and recommendation were disconnected: clients saw numbers, but nobody told them what to do about them.
Approach
I designed a KPI framework for revenue-focused decision makers, separating headline outcome metrics from the supporting diagnostics that explain them.
It took several versions, worked through with a senior peer and my manager, and the iteration resolved real definitional problems rather than cosmetic ones. We distinguished theoretical margin from realized profitability, so the same story was not told twice under two labels, and added revenue-realization and net-new-contribution metrics to make the expansion case quantifiable.
Underneath sits a rules-based recommendation matrix. Every KPI has a definition, a rationale, threshold-based conditional logic, a customer-facing recommendation for each performance band, and a specified visualization. I derived the performance bands from actual distribution percentiles within comparable cohorts rather than arbitrary cutoffs, so every recommendation is statistically defensible.
Privacy is built into the architecture. Peer comparisons surface an anonymized cohort average only, never an identifiable competitor, and the internal segmentation that routes the logic is never exposed to the client.
What it produced
It has its own value proposition and commercial positioning. A client no longer receives numbers alone. They receive the action those numbers imply, with the threshold that triggered it and the reasoning behind it attached.
Authoring that internal reference resolved an ambiguity that kept resurfacing between commercial teams. I also scoped and negotiated the analytics and engineering support the product required, including a defined weekly commitment from a specialist resource.
Process Optimization & Automation
Delivery workflow redesign
A delivery function where nobody could say where the time actually went — only that the team was busy.
200+
hours of manual work per month, per team
Projected, from a workload diagnostic.
The task-level time data understated reality, so I interviewed practitioners to surface the overhead nobody was measuring — context switching, chasing incomplete inputs, exception handling — and corrected the model until the utilization picture was credible to leadership.
It reframed “the team is busy” into an evidenced model of recoverable hours, on a roadmap achievable with existing tools and existing headcount at no new spend. I presented it to delivery leadership across multiple service lines and to a cross-functional acceleration forum, where the methodology was received as a reusable template — and then expanded the assessment into a broader professional services programme at leadership direction.
Read the approach
Problem
A delivery function where nobody could say where the time actually went — only that the team was busy.
Approach
I mapped every tracked task in the implementation workflow to its stage in the customer journey, then quantified effort by stage and by work cluster: configuration, communication and follow-up, calls, and administration.
Effort turned out to be heavily concentrated. A small minority of tasks accounted for the large majority of total workload — exactly the condition under which automation pays off.
The task-level time data understated reality, though. Through practitioner interviews I identified the overhead nobody was measuring — context switching, chasing incomplete inputs, exception handling — and corrected the model. That correction changed the conclusion materially, and it is what made the utilization picture credible to leadership.
Before proposing anything, I validated every automation idea against what was already planned on the platform roadmap, in direct conversation with the owning teams, so the proposal added to the roadmap instead of colliding with it. Every automation I proposed runs on tooling already approved and in use — no new procurement, no new headcount — and branches by customer tier.
What it produced
The proposals span intake, discovery, configuration, activation and close-out: replacing unstructured spreadsheet intake with a validated, tier-aware form that cannot be submitted incomplete; a recommendation engine that proposes product assortment for a new customer from property attributes and historical patterns; automated follow-up and status flows triggered by workflow milestones, with human review retained wherever the customer is contacted; and an automated handoff pack at close-out, so the downstream growth team inherits full context — a gap I identified that sat outside the original brief.
Expanding it meant running discovery sessions with vertical leaders in adjacent delivery functions, mapping how much of the same diagnostic held outside the service line it was built for.
Built with
- SQL
- Customer.io
- Salesforce Pardot
- Precursive
- Figma
- Make
- Looker
- Claude
- Alteryx