Modelling a customer's world
Hook was built on a simple, powerful idea: use machine learning to tell a CSM whether an account is likely to churn. It worked. Businesses bought it because it worked.
As Hook began attracting larger, more complex customers, that model started to break down – not because the scoring was wrong, but because the question itself was. "Will this account churn?" assumes one account, one subscription, one health story. It's the wrong unit for a business managing five independent products, or a global organisation with four layers of subsidiaries.
This case study covers two connected pieces of work that rebuilt how Hook models a customer's world – multi-product scoring, which introduced independent health scores per product, and parent/child accounts, which brought organisational hierarchy into Hook for the first time. Together they're used by 39 customers representing $2.7m ARR, concentrated in Hook's highest-value segment.
Part one: Multi-product
The problem
A CSM could see Medium at the account level, think "fine for now", and miss a Low on one product that was quietly eroding the relationship. As one user put it: "I cannot clearly see what products an account has bought, how engaged they are with each one, or make a meaningful judgment on renewal likelihood by product."
The fundamental unit of health needed to change. Not account-level. Product-level.
Discovery and what we learned
We ran structured discovery calls with four businesses – from two products to fourteen, from tightly-coupled SKUs to entirely separate buyer relationships. Three things came back consistently.
Products churn independently, but CSMs own the whole account – meaning product-level risk was invisible without explicit product-level scoring. The long tail was most exposed: strategic accounts could manage the complexity manually, but scale accounts had no systematic way to identify product risk at all. And how to aggregate product scores back to an account level was genuinely contested – ARR weighting, sentiment weighting, a separate model – no consensus. We treated it as an open question and kept moving.
What the first prototype got wrong
I moved quickly to a prototype – not to get it right, but to get everyone out of the theoretical and into a shared space. The first version showed product scores on the account page with an aggregate engagement score at the top alongside suggested actions.
The reaction identified a core problem: CSMs scan first, then act. The design was pushing action before it had enabled scanning. The top of the page was too busy, the aggregate score raised the same unresolved questions from discovery, and suggested actions above the product health picture was the wrong sequence.
The resolution
A second round moved suggested actions below the product scores. Better – but still pushing content too far down.
The final design made two calls together. First: remove the aggregate score entirely. No amount of iteration was going to resolve the fundamental disagreement about what the number should mean – and the real need, glanceability across products, could be met without it. Second: introduce the scorebar – each product as its own row with icon, renewal timing, ARR, sparkline, and engagement level all visible at a glance, expanding to reveal suggested actions per product. Scan first, act second. The insight-to-action flow finally matched how CSMs actually work.
A platform audit early in the project had mapped how deeply the engagement score ran across every surface. Every page needed to support both single-product and multi-product accounts without a mode switch – the UX had to feel native regardless of which model was running underneath.
Outcome
Multi-product launched end of November. In use by 23 of Hook's 65 active customers, representing $1.9m ARR – Hook's highest-value accounts, concentrated in the segment where multiple models cost more to run.
Part two: Parent/child accounts
The problem
Multi-product solved horizontal complexity – one account, multiple products. A different class of customer had vertical complexity: one organisation, multiple entities, each with their own CSM, subscription, and health story.
A global holding company is not one account. It is a parent with subsidiaries beneath it, each managed by a different CSM with its own renewal dates and ARR. A manager responsible for the whole relationship was manually stitching together a picture from separate account pages. This wasn't a UX problem. Hook had no concept of organisational hierarchy – every account was a flat, independent entity.
Understanding the structure
Partnering with two customers for discovery, we quickly found that real organisational structures were considerably more complex than anticipated – running to four levels of nesting, with subscriptions that didn't always map neatly to hierarchy. A parent account might hold no subscription itself, existing purely as an aggregation point.
Before any design work began, I developed systems diagrams mapping real-world structures to Hook's underlying concepts of accounts, subscriptions, and users. Without a shared, accurate model of how these structures actually worked, every design decision downstream would be on uncertain foundations.
Scope reduction
The natural first direction was a full aggregate rollup – a parent account page pulling together health, ARR, and engagement across every child. We prototyped it. Users thought it sounded desirable, but when pressed on how they'd actually use it, the hypothetical value didn't hold up. It raised the same questions the multi-product aggregate had, and the MVP would have required a full new page type and aggregated models before a single user could benefit.
The answer was a popover. A single interaction surfaces a complete breakdown of child subscriptions – health, ARR, renewal timing – for every entity in the hierarchy. No new page type. No aggregate model. The full rollup remains on the roadmap; the popover delivered the core job first.
Outcome
Parent/child is live with 39 customers, representing $2.7m ARR. Designed to work alongside multi-product from the start – a business managing multiple products across multiple child accounts can now see product-level health within each entity and understand risk across the whole organisation. Something entirely impossible before either piece of work existed.