Chat Experience
How the AI talks to customers,the widget, its personality, what it looks like, how it behaves, when it hands off.
Core Platform Structure,Making the Product Make Sense
HelloRep grew fast. Features were added where there was space, not where there was logic. At some point the product became hard to navigate for merchants and hard to extend for engineers,for the same reason.
When structure becomes the problem
For the first year or so, HelloRep's navigation was good enough. There weren't that many features, and merchants could find things by exploring. Then the product grew,analytics, insights, AI training, skills, knowledge base, integrations, multiple settings sections,and the navigation didn't grow with it in any principled way. Features ended up where there was room. Labels were inconsistent. Some things appeared in multiple places. Others were buried deep enough that merchants didn't know they existed.
Engineers had the same problem from the other side. Without a clear model for where things belonged, new features didn't have an obvious home. Similar components got built differently by different teams. There was no shared reference for how the product was supposed to be organised.
Four core domains
The restructuring started by identifying the four core jobs the platform does for merchants. Not features,jobs. What does a merchant fundamentally need HelloRep to do?
Flow Builder
Structured automation for specific scenarios,the explicit logic layer for cases that need it.
Training & Testing
What the AI knows and how it learns,knowledge base, FAQ, test conversations, corrections.
Analytics & Dashboard
How things are performing,conversation volume, helpfulness, live chats, unanswered questions.
These four domains became the architecture. Everything in the product belongs to one of them. The navigation reflects them directly. A new merchant can look at the nav and understand what the product does,and where to go to do each thing.
Navigation principles
The new navigation was built on three rules. Every item maps to one job,no item should make you wonder if it's in the right place. Nothing important is more than two clicks from anywhere. And the navigation is the same regardless of what you've configured,a merchant who has never set up a flow and one who has fifty see the same structure.
That last rule sounds obvious but wasn't how the old navigation worked. Some sections only appeared after setup steps were completed. Others changed based on enabled features. This made the product feel unstable. Fixing it meant accepting some redundancy,showing sections that aren't yet relevant,in exchange for a structure that's learnable and stays consistent.
The onboarding flow mirrors the platform structure. By the time merchants finish setup, they've been introduced to the four domains naturally,they know where their store settings live, what their AI is configured to do, and where to go to change things.
Shared language
One high-impact but less visible part of this work was establishing a shared vocabulary. Before, the same concept had different names in the UI, the codebase, and internal documentation. "Skills" meant one thing to a product manager, something slightly different to a developer, and something different again to a merchant reading the interface. These gaps compounded into bugs, misunderstood specs, and slow engineer onboarding.
Part of the restructuring was agreeing on names and making them stick everywhere,in the nav, in the codebase, in tickets, and in customer documentation. Not glamorous work. But shared language is what makes a team fast.
HelloRep went from a product that required explanation to one that supports navigation by intuition. Merchants know where things live. Engineers know where new things should go. And the product has room to grow without becoming unrecognisable from one version to the next.