# Convoora

By Munawar Khel / Independent Practice / Freelance UI/UX Designer / 2025 / 9 min read

Published at https://munawarkhel.com/work/independent-practice/convoora/

Designed a multi-brand live chat and customer support platform end to end as sole designer, spanning onboarding, three role-based dashboards, visitor monitoring, ticketing, conversations, brand management, user and organisation management, membership and billing, internal team chat, settings, and a client-facing embeddable widget

- Company: Independent Practice
- My role: Freelance UI/UX Designer
- Timeline: 2025
- Platform: Web application (enterprise SaaS, desktop-first at 1440x1024) with an embeddable client-side chat widget
- Category: Enterprise SaaS / Customer Support and Live Chat / CX Technology
- Status: New design, delivered
- Tools: Figma, Align UI
- Team: Solo designer, working directly with the client

## Context

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.

The category is crowded and well funded. Zendesk Chat, Intercom, LiveChat, and Tidio all cover the base case competently, which meant the product could not win on live chat as a feature. It had to win on what happens when a support team is running four brands at once, and the design had to make that difference legible from the first screen rather than buried in settings.

## The problem

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 design problem underneath all six was one question: what happens to an interface when brand stops being the boundary of the workspace and becomes an attribute of the work inside it? Every module had to answer it, because a conversation, a visitor, a ticket, an agent, and a billing seat each relate to brand differently.

## What I did

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.

**Real-time visitor monitoring.** A dedicated Visitors module groups people on site by activity status, active or idle, and shows referrer URL, visit count, chat history, and time on page. This turns support from reactive to proactive, since an agent can open a conversation with a high-intent visitor before that visitor leaves.

**A complete ticketing lifecycle.** Tickets move through New, Pending, and Solved with filtering, search, and threaded conversation detail. Assignment, escalation, and resolution tracking work across brands from a single view.

**Three-tier role-based access.** Super Admins control organisations, membership plans, and all settings. Admins and Managers oversee team operations and brand assignments. Agents work only with visitors, tickets, and conversations. Each role gets its own navigation and feature set rather than one interface with disabled controls.

**Organisation and user management.** Customer relationship management style capability for tracking end-user organisations, suspending and restoring users, setting access levels, applying tags, and holding profiles with language and timezone preferences.

**An embeddable client-side widget.** A branded, lightweight chat widget that collects visitor name and email, supports pre-chat forms, and connects to the agent dashboard in real time.

**Internal team chat.** Agent to agent messaging built into the platform, so coordination on a live customer issue never requires leaving the context the issue lives in.

**Membership and billing.** Tiered pricing across Basic, Standard, and Professional with seat-based scaling, upgrade flows, card billing, and clear cost breakdowns, all handled inside the product.

**Configurable settings.** Shortcuts as canned responses with placeholders and tags, banned visitor management, portal management for admins and agents, and per-agent brand assignment.

**Guided nine-step onboarding.** A Start Your Free Trial flow that collects work email, name, and business detail progressively, with visible progress and privacy compliance messaging.

Holding it together is a custom design system, Align UI, with themed components, light and dark mode, and multi-brand theming, so a new brand inherits a working interface rather than requiring one.

## Outcomes

- Designed a multi-brand live chat and customer support platform end to end as sole designer, spanning onboarding, three role-based dashboards, visitor monitoring, ticketing, conversations, brand management, user and organisation management, membership and billing, internal team chat, settings, and a client-facing embeddable widget
- Consolidated capability that previously required three to five separate tools, live chat, ticketing, visitor analytics, internal messaging, and billing management, into one platform built for multi-brand operation
- Built a custom design system, Align UI, with themed components, light and dark mode, and multi-brand theming, so a new brand inherits a working interface rather than requiring a design pass
- Removed cross-brand context switching for support teams by unifying the inbox while keeping visitor, ticket, and agent scope correctly bound to brand
- Enabled proactive engagement by making real-time visitor activity a destination in its own right rather than a byproduct of the conversation queue
- Gave leadership cross-brand support visibility that siloed per-brand tools structurally cannot produce

## Decisions

### Make brand an attribute of the work, not a boundary around the workspace

What: Designed one unified inbox and one workspace where brand is a property carried by conversations, visitors, tickets, and widgets, with agents assigned to the brands they service rather than to separate environments.

Why: A brand switcher is the interface expression of the exact problem the product exists to solve. It preserves the context loss and the switching cost while appearing to fix them, because an agent still cannot see two brands at once. Treating brand as an attribute means a manager sees the whole operation in one view and an agent sees only their assigned brands, and both come from the same structure rather than from two different products. It also made the scaling story honest: adding a fifth brand adds rows, not another place to go.

### Build three role-specific navigations rather than one interface with permissions

What: Gave Super Admin, Admin or Manager, and Agent their own navigation and feature set, so each role sees a product shaped for its job.

Why: Permission-hiding leaves the shape of a bigger product visible in the negative space, and it optimises for nobody. An agent taking a conversation does not need billing, organisations, or membership plans to exist in their peripheral vision, and a Super Admin configuring plans is not mid-conversation. Separating the navigations also made access control legible rather than implicit, which matters when the things being protected are billing, user suspension, and organisation management. The cost is three navigations to maintain, which the component library absorbs.

### Give visitors their own module rather than a list inside the inbox

What: Built Visitors as a first-class module grouping people on site by activity status, active or idle, with referrer URL, visit count, chat history, and time on page visible before any conversation exists.

Why: Support software is built around the request, which means it only starts working once a customer asks. The commercial value of live chat sits earlier, with the visitor who is on a pricing page and will leave without asking anything. Making that population a destination rather than a side panel changes what an agent does with quiet time, from waiting for the queue to reading intent signals and opening conversations. It also gave managers a real-time picture of demand across brands that no ticket count can produce.

### Build theming into the design system rather than applying brand as a late-stage skin

What: Built Align UI with themed components, light and dark mode, and multi-brand theming from the start, so a new brand is a configuration rather than a design pass.

Why: For most products a theming layer is a nice addition. For this one it is the product, since the entire proposition is that adding a brand should be cheap. If brand identity is retrofitted, every new brand becomes a design ticket, and the tool reproduces the setup friction it was built to remove. Handling it in components also protected the client-facing widget, which has to carry a customer's brand convincingly on the customer's own page while remaining one artefact to maintain.

## What I learned

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.

I would push harder on validation next time. The client was an unusually strong proxy user, since they ran the exact operation the product targets, and that made review sessions productive enough that it was easy to treat them as sufficient. A proxy who knows the problem intimately is still one operation's worth of evidence, and multi-brand support teams outside that operation will have arranged their workflow differently.

Tags: Information Architecture, Interaction Design, Brand Identity, Design Systems, Web, Enterprise SaaS, B2B SaaS, Dashboard, Component Library