Academy

One relationship, many specialists

A customer should feel one relationship, not be handed from bot to bot. Behind a single surface, specialists each own a domain — unified by default, separable by a setting, never by a rebuild.

The Felesh team 7 min

You have almost certainly been bounced between bots. You ask a sales question and get one assistant; you come back a week later with a billing problem and get another that has never heard of you. Each knows its own narrow script and nothing about the person on the other side. You are expected to carry the thread between them, repeating yourself at every handoff.

The customer carries the thread between botsIn week 1 Omid asks the sales bot for the price of 12 seats on the Team plan; the sales bot has only that chat. A week later he tells the billing bot his invoice says 12 seats but he only uses 9. The billing bot has nothing on Omid and asks which plan. Omid is the only one carrying the thread.week 1a week laterOmid asksprice for 12 seatson the Team plan?sales bothas: 12 seats, Teamplan, this chat onlyOmid asksinvoice says 12 seats,I only use 9billing bothas: nothing on Omidasks: which plan?Omid is the only one carrying the thread
Each bot knows only its own script, so Omid carries the thread from one bot to the next.

This is what happens when a company exposes its internal org chart as its customer interface. The seams between departments become seams the customer is forced to feel. We think that is backwards. To the person reaching out, your company is one company — and talking to it should feel like one relationship, not a tour through your back office.

One surface, specialists behind it

So we put a single surface in front of the customer. They talk to us — not to a sales bot, then a support bot, then a renewals bot. There is one conversation, one place that remembers them, and one relationship that accumulates over time.

Behind that surface, the work is divided among specialists. One understands sales, another support, and another whatever domains your business actually operates. When a question comes in, it reaches the specialist equipped to handle it — but that routing happens out of sight. The customer is never told to wait while they are transferred. They feel one continuous conversation; the specialisation is our responsibility to manage, not theirs to navigate.

Routing out of sightOn the left, what Omid sees: one conversation. He writes that his bill says 12 seats but he only uses 9. Behind the surface, out of his sight, three specialists wait: sales for quotes and seats, support for tickets and bugs, billing for invoices and refunds. The message is routed to billing, and billing answers in the same thread: you are on 9 seats from this month.what Omid seeswhat we manageOmidbill says 12 seats,I only use 9usYou are on 9 seatsfrom this month.salesquotes, seatssupporttickets, bugsbillinginvoices, refundsrouting happens out of sight: Omid sees one voice
The question reaches the billing specialist and the answer comes back in the same thread, with no transfer in between.

The same memory sits underneath all of it. Because every specialist draws on a shared picture of the customer, a single conversation can open a sales opportunity and raise a support request at once. The customer never has to split their request across two tickets. One person, one history, one relationship — viewed from whichever angle the moment demands.

One message, two records, one historyOmid writes one message: can I add 3 seats, and the CSV export fails for me. The sales specialist hears the first part and the support specialist the second. Sales writes an opportunity, plus 3 seats on the Team plan, and support writes a request, CSV export fails, both into Omid K’s one shared history, so there is no second ticket.Omid, one messagecan I add 3 seats? And the CSV export fails for mesaleshears: add 3 seatssupporthears: export failsOmid K. · shared historyone history, no second ticketopportunity+3 seats, Team plansupport requestCSV export fails
One message opens a sales opportunity and a support request together, both written to the same customer history.

Why specialists beat one generalist

The obvious alternative is a single agent that tries to do everything. We do not build that, for the same reason a good company does not ask one employee to be its entire staff. Breadth comes at the cost of depth. An agent stretched across sales, support, billing, and onboarding is shallow in each.

A specialist is the opposite: narrow on purpose, and deep because of it. It holds the specific knowledge, tone, and judgement its domain requires, without being diluted by trying to do three other things. The customer gets the depth of a specialist alongside the continuity of a single relationship. The context that usually has to be traded away is kept instead.

A generalist skims, a specialist goes deepA comparison. One generalist covering sales, support, billing and onboarding holds one shallow line for each: general pitch, generic apology, basic FAQ, welcome email. A billing specialist holds three deep things: knowledge (price book, proration, credit-note rules), tone (precise, numbers first, no sales pitch) and judgement (a customer on 9 seats mid-cycle gets a credit, not a refund). Narrow on purpose, deep because of it.one generalistbilling specialistsalesgeneral pitchsupportgeneric apologybillingbasic FAQonboardingwelcome emailknowledgeprice book, proration,credit-note rulestoneprecise, numbers first,no sales pitchjudgement9 seats mid-cycle: acredit, not a refundnarrow on purpose, deep because of it
Stretched across four domains an agent skims each one; a specialist holds one domain deep enough to judge a case.

Unified by default

Here is the part that matters most for how this holds up over time: keeping things together is the default, and keeping them apart is just a setting.

Most customers are best served by one unified assistant that quietly fans questions out to the correct specialist. But some businesses genuinely want sales and support kept separate — different teams, different rules, deliberately distinct front doors. That separation is a configuration choice, not a different product. You do not have to rebuild to move from unified to separate, or back again. The specialists, the shared memory, and the underlying structure remain identical; only the presentation changes.

Unified or separate is a settingA front-door setting flips from unified to separate. Unified: one door for every question, fanning out to sales, support and billing. Separate: a sales door that leads to sales, and a support door that leads to support and billing. Beneath both, the three specialists and the shared memory of Omid K. are identical.front-door settingunifiedseparateone door, every questionsales doorsupport doorsalesquotes, seatssupporttickets, bugsbillinginvoices, refundsshared memory · Omid K., 9 seats, Team planspecialists and memory: identical in both
Flipping the front-door setting splits one door into two; the specialists and the shared memory behind them do not change.

This is what keeps the model honest as you grow. Adding a new domain — a new speciality your business has taken on — is simply a matter of registering one more specialist behind the existing surface. It does not require standing up an entirely new system that has never met your customers.

Adding a specialist to the same memoryA timeline for one customer, Omid K. Month 1: sales quotes 12 seats on the Team plan. Month 2: support closes a ticket about the CSV export. Month 3: billing corrects the invoice to 9 seats. Month 4: installation is registered as a fourth specialist, and its first reply already knows Omid: Hi Omid, Tuesday works for your 9 seats. Every entry writes to the same shared memory.month 1salesquote for 12 seats, Team planmonth 2supportticket closed: CSV exportmonth 3billinginvoice corrected to 9 seatsmonth 4installationfirst reply already knows him:“Hi Omid, Tuesday works for your 9 seats”shared memory · Omid K., 9 seats, Team plan
A new domain is one more specialist registered behind the same surface, and its first reply already knows the customer.

Where this stands

This is a design principle we are committed to and actively building, not a finished product with deployments to point at. We are describing the shape — one surface, specialists behind it, unified by default — because the shape is the part we want to be judged on, ahead of any numbers.

The reason we lead with structure rather than a clever demo is that structure is what survives contact with a real, messy relationship. A demo shows one tidy exchange. The architecture is what decides whether, two years and four departments later, your customer still feels like they are talking to a single company.

A relationship is a single thing, even when the work behind it is divided many ways. The job of the structure is to keep that division invisible to the one person it would otherwise burden — so that what they experience stays whole, no matter how many specialists it takes to hold it up.