00 · Available in English only (nur auf Englisch verfügbar)
01Context
The product gave hotels a shared inbox across all their channels, plus contact management, reporting, PMS integrations, and more. This case study is about one part of it: Automations, the feature that sent outbound messages automatically along the guest's stay. Outbound ran mostly on WhatsApp templates, SMS as a fallback, nothing else. Automations wasn't the one reason customers paid, but it was the product's outbound-messaging feature and a big part of what it did.
02The problem
Automations was a conditional-tree builder. Powerful on paper: you could nest conditions and make them depend on each other. In practice almost nobody used it on their own. The people meant to run it were hotel staff with little technical background, and the feature assumed a technical user. So support set it up and maintained it for every customer by hand.
That created two problems that fed each other:
- It blocked scale. No customer could run the outbound feature without support setting it up and babysitting it. Going from 200 customers toward 1,000 just doesn't work when every account needs hands-on support.
- It broke onboarding and retention. The feature targeted a technical user our customers didn't have, so sales oversold how usable it was and support absorbed the gap. New customers often didn't realize they couldn't run it without a technical person, and support capacity is finite. They were frustrated from onboarding on. Churn ran well above healthy SaaS levels, and a lot of users never really activated. (Specific figures withheld for confidentiality.)
03The call
A rebuild was already mandatory. During my onboarding, engineering found that upcoming changes to the app would break the existing automations anyway. The open question was what to rebuild toward, and that's where I made the call: self-service.
My reasoning went past the feature itself. If we wanted to scale the way the CEO intended, with onboarding and retention numbers that bad, the math didn't work. The core of the product had to be something a real customer could use without us. So I argued a broader point: the company had to move from sales-led to product-led sales, and self-service was the foundation for that, both for how the product gets sold and demoed and for how customers onboard and stay. Automations was where to prove it.
04Working it out without data
No analytics, no usage data, nothing to point to. So I built the picture from the people with the customer exposure. I ran a lot of internal interviews with everyone customer-facing, especially support, who saw the most customers and knew exactly where they got stuck. That told me what our actual users could and couldn't be trusted to do on their own. I wrote the specs with them, built a prototype, validated it back with them, and got clear feedback from them that it matched what they needed.
05The core trade-off: power for usability
Scope was the hardest part, and it took several intense rounds with the CPO. The old tree was genuinely powerful, with nested, interdependent conditionals. The new design was deliberately the opposite. Connect your WhatsApp Business account, connect your PMS, get pre-built WhatsApp template drafts, fill them with your hotel's details, pick when they go out. Done.
I traded theoretical power for a flow our real users could actually finish on their own. The goal: a UX a non-technical hotel employee could run end to end.
The product bet: map automations onto the guest journey. That was the big assumption. I built the feature around a five-step guest journey we defined ourselves, each step tied to a concrete PMS trigger. When the trigger fires, the automated WhatsApp template goes out. Each event holds up to three messages, and each message has a timing (at the trigger, before, or after). So outbound messaging maps onto the guest's phase of the stay, and the marketer can shape content to fit where the guest actually is. That mattered to our ICP: high-end hotels that care a lot about the guest experience.
One limit I'll name: this guest-journey model was validated through the people closest to the customer, not with hoteliers directly. Under the no-analytics constraint that was the fastest reliable signal I had, but it was tested against support's picture of the user, not the user. With more runway I'd have put it in front of real hoteliers.
Prioritization was the easy part. I wanted to build other things first, but this had to ship now, otherwise automations would stop working entirely, and that would have been a catastrophe for existing customers.
06A decision I lost, and why I committed anyway
Early on I pushed back hard on a webhook-receive feature the CPO wanted: an endpoint customers could send data to and then use in automations, with how the data gets there left to them. To me it was the old mistake again, a feature for a technical user we didn't have.
The context: our ICP was high-end hotels, but sales liked to sell to short-term-rental operators and similar. There was a lot of noise from users who were in the base but not ICP, and they were the loudest. The CPO decided it was a must, so we built it.
I disagreed, committed, and shipped it. Then I checked the outcome: we'd basically built it for one "north-star" customer. No broader user need, exactly as I'd expected.
07Outcome
80%+
of new users could use Automations without support (CS-observed), against almost none before.
Near-zero
hands-on support to run Automations, down from setup and babysitting on every account.
- The assumption held: users don't need more than three message automations per event.
- Strong qualitative feedback: customers were grateful for the pre-built templates, which removed the blank-page problem.
- Support load dropped to a residual. What was left mostly wasn't about the feature at all. The hardest step for most users was connecting the WhatsApp Business account, which is what unlocks Automations, and most of the leftover requests were about that. That connection follows Meta's process, which we can't change, only support, so I logged a backlog item to guide users through that step better.
What the 80% actually is, and isn't. The company had no analytics, and my attempt to get instrumentation in (a full event-tracking plan) didn't ship before I left. The 80%+ above isn't an activation curve, it's CS-observed: across the ~20 onboardings in that window, CS reported 3 to 4 customers that couldn't run Automations on their own, the rest could. Small sample, straight from the people doing the onboardings. I'd rather say that plainly than dress up a number I couldn't cleanly measure.
What this meant for the scale thesis: onboarding a new customer no longer needed hands-on support per account, so support capacity stopped being the ceiling on growth. That was the whole point of the rebuild. I left before we could measure the growth curve itself, so I'll call the thesis addressed, not proven.
08What went wrong, and what I'd do differently
- Small timezone bug for the first few days. We hotfixed it.
- The webhook-receive call I lost is as much an organizational lesson as a product one: loud non-ICP users and a single reference customer can pull scope away from a strategy you've just set.