Convoora

Convoora is a live chat and customer support platform built for businesses that run more than one brand. Support teams monitor website visitors in real time, hold live conversations, move tickets through their lifecycle, and coordinate internally, all from one role-segmented workspace. End users never see that workspace. They see a small embeddable chat widget on the business's own site, branded to whichever company they arrived through.

The startup arrived with an internal working name, Chat V2, and a problem they had firsthand. Their own operation ran several brands at once, including LogoGenies, LogoDesign360, Markfortified, and AccurateResume, so they lived daily with the assumption every live chat tool makes: that a business is one brand.

A business managing multiple brands does not get a multiplied version of the single-brand support problem. It gets a different one. The tools available treat brand identity as an account boundary, so each brand means a separate dashboard, a separate login, and a separate configuration. That single architectural assumption produced six connected failures:

1. **Operational inefficiency.** Agents lost time switching between platforms and lost conversation context and visitor history every time they crossed a brand boundary. 2. **No real-time visibility.** Managers and admins had no unified view of who was on which site right now, which visitors were idle, or which conversations were live across the portfolio. 3. **Ticket fragmentation.** Tickets from different brands landed in siloed systems, making resolution rates, priority, and service level agreements impossible to track holistically. 4. **Rigid role structures.** Granular access control was rare, which left billing, user suspension, and organisation management exposed to team members who had no business touching them. 5. **Onboarding and scaling friction.** Adding a brand, an agent, or an organisation meant cumbersome setup, with no clean way to manage plans, seat allocation, or team growth. 6. **No internal communication.** Coordinating on a customer issue meant leaving for Slack or email, breaking the workflow at exactly the moment response time matters most.

The product consolidates what a multi-brand team was previously running across three to five tools, and the design organises it around two structural ideas: brand as an attribute rather than a boundary, and role as the thing that shapes the workspace.

**One workspace, many brands.** Super Admins create and configure brands, each with its own identity, logo, and embeddable widget, while every conversation from every brand funnels into one centralised inbox. Agents are assigned to the brands they service, so scope is controlled without fragmenting the interface.

The most useful question on this project was not what the product should do but what brand means to each object in it. Once I had written down that a conversation has one brand, a visitor has one brand, a ticket has one brand, an agent has several, and a billing seat has none, most of the information architecture stopped being a matter of preference. Ambiguity in a product is usually ambiguity about relationships, and it is cheaper to resolve on a wall than in a screen.

Designing for three roles taught me that permissions and navigation are different problems that look like one problem. Hiding what a role cannot use is an access decision. Deciding what a role should be thinking about is a design decision. Conflating them produces an interface that technically protects the right things while still asking everyone to ignore most of what they can see.