01Context
HotelKey serves a platform of 4,000+ properties across major hospitality brands. The sales and support side of that business, onboarding new properties, managing brand relationships, and resolving property-level issues, had grown up across spreadsheets, email, and partially configured CRM objects. Every brand had a slightly different definition of a "qualified lead" and a "resolved case." Reporting across brands was manual, and support agents were re-asking questions the system should already have known.
The mandate was a single Salesforce Sales & Support platform that could hold every brand's process without forking the org per brand, and that would make agents faster rather than slower on day one.
02My role
I was the analyst and solution designer between the brand stakeholders and the engineering team: I ran discovery with each brand, owned the data model and automation design, wrote the user stories and acceptance criteria, and drove UAT through go-live. On the platform itself I built the declarative layer, Flows, assignment logic, and Einstein configuration, and specified the Apex where declarative tools ran out.
03Approach
- One data model, brand as a dimension. Rather than cloning objects per brand, brand became a first-class field driving record types, page layouts, and Flow branches. Adding a brand became configuration, not a project.
- Declarative first. Record-triggered and screen Flows handled routing, SLA timers, and case escalation, with entry criteria tight enough that Flows never fought each other on the same field. Apex was reserved for the two places Flows couldn't reach cleanly.
- Einstein where it changed a decision. Lead scoring and next-best-action recommendations were surfaced only in the moments an agent was actually choosing what to do next, which is why adoption stuck.
- Discovery as a contract. Each brand's "qualified lead" and "resolved case" definitions were documented as acceptance criteria before build, so UAT tested the agreed logic, not opinions.
04Outcome
The standardized model is what made the 30% implementation-effort reduction possible: each subsequent brand onboarding reused the same Flows, layouts, and reporting, with brand-specific configuration layered on top.
05What I'd do differently
Two things. I'd introduce an automation inventory from day one, a living register of every Flow and trigger by object and event, because the conflict risk grows silently as brands are added; that gap is exactly what Trowel now exists to close. And I'd budget more time for Einstein data readiness up front; the recommendations were only as good as the field hygiene underneath them, and cleaning that up mid-build cost a sprint.