Client / Sector
SaaS - omnichannel customer messaging
Market
Sales, support and marketing teams, product in English
Engagement
Product design, design system, AI agent and workflow UX, brand and marketing site
Status / Year
Live, 2025
The situation
Customer conversations stopped living in email a long time ago. A business in Algiers, Dubai or Casablanca sells on Instagram, negotiates on WhatsApp, confirms on Messenger and only sends an invoice by email. The default CRM for a lot of these teams is a phone on the counter with three WhatsApp accounts logged into it, and the default help desk is whoever happens to be holding that phone.
That works until it does not. Nobody can see what was promised to a customer last week, two agents answer the same message with two different prices, and a lead that came in through Instagram is invisible to the person who handles email. Traditional ticketing tools were built around an email thread and a queue; they treat WhatsApp as a plug-in rather than as the main channel it actually is in most of the world.
Closini was built for that reality: one shared inbox where every channel lands, contact records that carry the whole cross-channel history, AI agents that handle the routine volume, and a clean handoff to a human the moment the conversation stops being routine. We designed the full product surface, from the inbox and conversation view through contacts and lifecycle, AI agent configuration, the workflow builder and reporting, plus the brand and the marketing site that sells it.
What made this hard
Seven channels, one customer
The same person arrives as a phone number on WhatsApp, a handle on Instagram and an address on email, and to the business they are one contact with one history. Identity resolution and merge rules had to be part of the data model from the start, not a settings screen bolted on later. Get it wrong and one shared inbox quietly becomes three.
Messaging platforms impose their own rules
WhatsApp only lets a business reply freely inside a customer service window that opens when the customer writes; outside it, you must send an approved template. That is a product constraint, not a footnote, so the composer has to show agents where they stand before they type a message that will never be delivered. Each channel has its own version of this, with different attachment limits, reaction support and read-receipt behaviour.
Automation is only trusted if the exit is obvious
Teams will not let an AI agent talk to their customers unless they can see exactly what it said, pause it mid-conversation and take over in one click. The design problem was the seam: making the moment an agent hands over to a human feel deliberate to the team and invisible to the customer. We treated the handoff as a first-class object in the interface rather than an event in a log.
An inbox and a CRM are usually two products
Agents were being asked to keep a messaging tool and a pipeline tool in sync by hand, which means the pipeline is always wrong. Putting lifecycle stage, tags, deal ownership and custom fields directly beside the thread meant designing a conversation surface dense enough to be useful and calm enough to work in all day. Every field added to the sidebar had to earn the pixels it took from the message.
Shared inboxes have a collision problem
Two agents opening the same thread and both replying is the classic failure of any team inbox, and it is worse when the customer sees both messages arrive on WhatsApp. Presence, assignment and typing state had to be genuinely realtime rather than polled, and the interface had to make ownership legible at a glance in a list of hundreds of conversations.
How we approached it
We started at the message, not at the module. Before drawing a single screen we mapped what each channel can and cannot carry, from replies and attachments to reactions, templates, delivery receipts and session windows, and used that matrix to define one normalised message model with per-channel capability flags. Everything above it, from the composer to the AI agents to the reporting, reads those flags instead of hard-coding channel behaviour.
From there the work ran as a single product design engagement: a design system built for information density, an inbox designed for eight hours a day rather than for a screenshot, an AI configuration surface that a support lead can operate without an engineer, and a marketing site that explains the product honestly enough that people arrive at the trial already understanding it.
Channel audit and message model
We inventoried every channel Closini would carry and reduced them to one envelope: sender identity, direction, body, attachments, channel capabilities and session state. This is the decision the rest of the product rests on, so it was made first and written down as a contract rather than discovered screen by screen.
The conversation surface
We designed the inbox around a three-pane rhythm of conversation list, thread and contact context, tuned so an agent can triage a full queue with the keyboard. Channel identity is carried by small persistent cues rather than heavy branding, so a busy queue reads as one list instead of seven.
Contacts and lifecycle
We folded the CRM into the same surface: contact records with custom fields, tags, assignment and a single lifecycle stage that moves from new lead through to closed. The activity timeline merges every channel chronologically, so the history of a customer is one column, not a set of tabs.
AI agents and workflows
We designed agent creation as a short, legible flow: pick a role, connect a knowledge base, set the escalation rules, watch it work in a sandbox before it touches a real customer. Alongside it, a drag-and-drop workflow builder handles the deterministic half of automation — routing, tagging, assignment and follow-up — so teams do not have to use a language model for things an if-statement solves better.
Reporting, brand and go-to-market
We closed with the reporting layer, the visual identity and the marketing site, pricing page included. The site reuses the product design system, so what a prospect sees before signing up is what they get after.
What we shipped
Unified inbox
- One shared team inbox per workspace
- WhatsApp, Messenger, Instagram, Telegram, email, SMS and live chat
- Channel-aware composer with session and template handling
- Assignment, teams and ownership visible in the queue
- Saved replies, snippets and internal notes
- Cross-channel activity timeline per contact
Contacts and CRM
- Contact records with custom fields
- Lifecycle stages from new lead to closed won
- Tag-based segmentation
- Deal assignment and tracking
- Merge and identity resolution across channels
AI agents and automation
- Agents trained on the workspace knowledge base
- Sales agent for lead qualification and booking
- Support agents for routine ticket resolution
- Pause, resume and take over any agent mid-conversation
- Drag-and-drop no-code workflow builder
- Escalation rules and human handoff
Reporting, brand and site
- Realtime analytics and performance reporting
- Integrations surface for external CRM, automation and commerce tools
- Full brand identity and design system
- Marketing site built on the product design system
Engineering decisions
The choices that shaped the build, and what each one traded away.
One message model, seven transports
Every inbound and outbound message is stored in a single normalised shape, with each channel described by a capability record: can it thread, can it carry attachments, does it have a session window, does it require templates. The composer, the AI agents and the workflow engine all read capabilities as data instead of branching on channel names. The trade-off is more work per channel adapter up front, but adding an eighth channel becomes a configuration and an adapter rather than a rewrite of the inbox.
The session window is rendered, not remembered
Rather than let agents discover platform restrictions through failed sends, the composer surfaces the state of the messaging window and switches to the template path when free-form replies are not allowed. It costs interface real estate and adds a concept agents have to learn, which we accepted, because the alternative is messages that appear sent and are silently never delivered, which is the most damaging failure mode a customer messaging product has.
Realtime over WebSockets with optimistic send
A shared inbox lives or dies on presence, assignment and typing state being immediate, so the client holds a persistent socket and renders sends optimistically before the server acknowledges them. That gives two sources of truth, so every message carries a client-generated idempotency key and reconnection replays from a cursor to deduplicate. It is more state to manage than request-response, but polling a team inbox at the frequency this product needs would have been both slower and more expensive.
Retrieval before generation, escalation before invention
The AI agents are grounded in each workspace's own knowledge base through retrieval, and are configured to escalate to a human when retrieval comes back weak rather than improvise an answer. The visible cost is that a brand-new workspace has agents that escalate a lot until its documentation is loaded, so onboarding makes knowledge base ingestion the first step rather than an optional one. We took that cost because an agent that declines to guess is worth more to a support team than one that always has an answer.
Lifecycle stage as one field, not a parallel pipeline
Most CRMs let each team build its own pipeline, which is flexible and immediately produces two versions of the truth about the same customer. Closini keeps a single lifecycle field per contact with tags and custom fields carrying the nuance. It is deliberately less configurable than a full sales CRM, and in exchange the inbox, the reporting and the AI agents all agree on where a customer stands.
The outcome
Closini today is a live product with the full surface in place: a business connects its channels, imports or grows its contacts, points an AI agent at its own documentation and starts working out of one inbox. The same design system carries the marketing site, so what a prospect reads before signing up describes the product they actually land in.
The change we care about is smaller than the pitch. It is the moment a salesperson opens a thread and can see, in one column, that this customer messaged on Instagram three weeks ago, was quoted a price on WhatsApp, and never got the follow-up email. That context used to live in someone's memory. Now it is a record, and the AI agents work from the same record rather than from a separate script.
For KinxLab, Closini is the reference for how we approach messaging products: define the protocol reality first, design for the operator who lives in the tool all day, and treat automation as something that must hand back cleanly rather than something that must win.
7
Channels in one inbox
WhatsApp, Messenger, Instagram, Telegram, email, SMS and live chat, all normalised into a single message model.
5
Product surfaces designed
Omnichannel inbox, contacts and CRM, AI agents, no-code workflows and reporting.
4
Workstreams delivered
Product UX and UI, the design system, AI agent and workflow design, and the marketing site.
2
Agent roles designed
A sales agent for lead qualification and a support agent for routine resolution, both with an explicit handoff to a human.
Honestly
The honest constraint of an AI-first inbox is that automation quality is a function of the customer's own documentation, not of the model. A workspace that loads real product knowledge gets agents that resolve routine volume on day one; a workspace that connects its channels and nothing else gets a polite escalation machine. We designed the onboarding around that truth rather than hiding it, and it remains the thing that most determines whether a team gets value in week one.
The other standing cost is that Closini sits on top of platforms it does not control. Messaging APIs change their windows, their template rules and their pricing on their own schedule, and per-channel fees are billed by the platforms separately. Building the capability layer as data was the hedge against that, and it is the piece of the architecture we would keep unchanged if we started again.
Frequently asked
What is Closini?
Closini is an omnichannel customer messaging platform. It brings WhatsApp, Messenger, Instagram, Telegram, email, SMS and live chat into a single shared team inbox, adds a built-in CRM with contact records and lifecycle stages, and lets AI agents handle routine support and lead qualification with a clean handoff to a human.
Who designed and built Closini?
KinxLab. We designed the full product: the omnichannel inbox, the conversation surface, contacts and lifecycle, AI agent configuration, the workflow builder and reporting, along with the brand identity, the design system and the marketing site.
Which channels does Closini support?
Seven: WhatsApp, Messenger, Instagram, Telegram, email, SMS and live chat. Each one is normalised into the same message model, so a contact's history reads as one timeline no matter which channel each message arrived on.
Can Closini's AI agents replace a support team?
No, and they are not designed to. The agents are trained on your own knowledge base to handle routine, repeatable volume and to qualify leads, and they escalate to a human whenever the retrieved knowledge is thin or the conversation leaves their scope. A human can pause an agent and take over any conversation at any point.
