The thread that’s actually one thread - across the four tools the customer’s using and the three you are

“Customer texted a leak video on WhatsApp Wednesday. Agent emailed about a payment query Thursday. Landlord rang me on Tuesday. Each one thinks they’re the only one I’m talking to; none of them know what the others know. The phone I had in May is dead and the WhatsApp thread with the customer from March is gone with it.”

Most UK SMEs don’t have a comms problem. They have a one thread per channel and four channels per relationship problem. The customer texts a leak video on WhatsApp; the agent emails about who’s paying; the landlord rings on a hands-free; the tenant DMs on Instagram; the loss adjuster posts a hard-copy letter. Five touchpoints, five tools, no shared record. The “what did we agree last week” question turns into a fifteen-minute search across four screens at midnight. And when the trade’s phone changes in May the March WhatsApp thread goes with it - along with the photo evidence that would have settled the deposit dispute six months later.

This is the build that captures every inbound and outbound across every channel against one structured per-customer record. Voice, SMS, WhatsApp, email, web chat, in-app, the agent portal, the landlord portal, the legal portal - channel of origin tagged, participants identified, decisions and dates and agreed prices extracted as structured events, three-way relationships visible to the right party at the right step. The shape is sealed against mendbuddy, our own multi-channel agent platform whose first-class object is the customer thread, and ports cleanly across reactive trades running WhatsApp-native operations, lettings-agent + landlord + tenant three-way comms, professional-services client threads, solicitor matter chains, construction programme communication, and clinic-to-OOH veterinary handovers.

What gets lost when the thread isn’t one thread

The shape repeats; the lost information is always the same in a different costume. A few moments - pick the ones that sound like your week:

• Reactive trades running WhatsApp-nativethe leak video the customer dropped on Tuesday morning is the job record, but it lives in a personal WhatsApp thread on the plumber’s phone. The voice-note reply is verbal-only. The invoice generates in Tradify / ServiceM8 from a different system. The payment-link goes back into the thread but the receipt’s emailed. Five surfaces, one job, no canonical record.
• Lettings - three-way comms breakdownthe tenant rings the agent about a boiler. The agent emails the landlord. The landlord rings the gas engineer. The gas engineer WhatsApps the tenant to arrange access. None of the four know what the other three said, and the same fault gets explained four times. The agent thinks the landlord’s approved repair-up-to-£300; the landlord thinks repair-up-to-£150; the engineer thinks she’s been authorised to swap the boiler. Tuesday afternoon disappears in clarification calls.
• Plumbers and electricians doing lettings workthe agent’s portal is one queue, the trade’s job-app is another, the tenant’s WhatsApp is a third, the landlord’s email is a fourth. The cert PDF gets re-asked-for monthly because none of the four tools know which one holds it. “Can you re-send 14 Mill Lane March” eats every Tuesday morning.
• Gas engineers running the landlord-CP12 roundthe November round runs across 200 properties, three agents, dozens of landlords, hundreds of tenants. Access-coordination is a four-party conversation on each property. Currently it’s four threads per property, one engineer’s phone trying to hold all of them, and the missed access is invariably the property where the WhatsApp thread fell to page four of the inbox.
• Solicitors - the conveyancing chainbuyer + seller’s solicitor + lender + estate agent on every transaction. Each party has a version of “where we are this week”. The status conversation gets re-explained on every chase call because nobody owns the canonical thread. When the chain breaks, untangling who-said-what-when costs everyone a Friday afternoon.
• Construction multi-trade programme commsthe programme manager / client / sub-contractor / QS conversation on the “when does the steel land” question fragments across four phones and three email threads. By the time it reconciles, the slot’s gone and the float’s blown.
• Professional-services client threadsSlack with the client team, email with the procurement contact, WhatsApp with the partner-side principal, the project portal with the formal status. Same project, four channels, no single source. The decision audit (“we agreed week 3 to push the launch to October”) is buried in a Slack thread the new associate doesn’t have access to.
• Vet OOH handoverthe practice’s records, the consented-and-shared handover summary, the OOH service’s notes, the family’s evening WhatsApp updates. Every handover risks the “didn’t anyone tell you about her thyroid medication” moment because no single thread carries the patient.
• Funeral directorsthe arranger’s notes with the family, the venue’s catering thread, the celebrant’s eulogy iterations, the florist’s confirmation, the obituary-wording correspondence - all sat in the arranger’s inbox and her notepad. When the second arranger picks up the file, the threads aren’t where they should be.
• The trade phone that gets replacedyour iPhone died in May. The WhatsApp thread from March with the customer who’s just rung you back is gone. The video evidence of the leak that would have settled the deposit dispute is gone with it. The customer remembers what she sent; you don’t.

These aren’t problems for a generic CRM. They’re the bit between the conversation happened and the canonical record exists - which is where dispute risk, scope clarity, and the relationship itself actually live.

What solved looks like

1. The per-customer thread is the unit, not the channel

The “she rang earlier, then texted, then emailed” moment: the same customer interacted across three channels today and you’ve got three separate conversations to read. None of them stand alone; together they’re the actual context. By the time you’ve reconstructed what she’s actually asking, an hour’s gone.

Solved looks like: every inbound on every channel writes to the same structured per-customer record. Every outbound from you (or the trainable inbound AI agent running on your behalf) writes back to the same thread. The customer’s voice call at 9am, her WhatsApp at 11am, her email at 3pm, and her web-chat at 6pm are one conversation, displayed in time order with the channel of each touchpoint tagged. The “what did we agree” question is answered in two clicks - open the customer, scroll. Same engine for repeat customers, new prospects, three-way relationships, multi-trade programmes, and one-off enquiries.

2. Three-way (or N-way) visibility per role

The “each thinks they’re the only one I’m talking to” moment: the tenant texts you about the leak. The agent emails about the same leak. The landlord rings about whether it’s a tenant-caused or landlord-side fault. Each gets a slightly different version of what you said. By Thursday the agent’s saying repair-up-to-£300, the landlord’s saying £150, and the tenant’s saying “the plumber said the boiler’s gone”. Nobody’s lied; nobody’s clear either.

Solved looks like: where a relationship involves multiple parties (agent + landlord + tenant; buyer + seller + lender; programme manager + sub + client + QS; practice + OOH service + family), each party sees the slice of the thread relevant to them. The audit trail is the whole thread; the per-party view respects the permissions you’ve configured. The tenant sees the contractor-side scheduling and the “I’ll be there Friday morning” update; the landlord sees the cost authorisation and the cert state; the agent sees the access coordination and the invoice trail. One canonical thread, three role-scoped views, no “each thinks they’re the only one” breakdown.

3. Structured event extraction - decisions, dates, agreed prices

The “we agreed week 3 to push the launch” moment: the decision was made on a Slack thread that’s now buried under four hundred messages. The new associate’s reading the project portal and there’s nothing in it about the launch shift. The client thinks the decision was confirmed in writing; the partner thinks the decision was provisional. Untangling who-said-what-when costs the project lead a Friday afternoon.

Solved looks like: the agent reads the thread with your business context loaded and extracts decisions, dates, agreed prices, scope changes, authorisations, and consent moments as structured events tagged against the relationship. “We agreed week 3 to push the launch to October” lives as a structured note searchable across every relationship - not just buried in a WhatsApp thread. Ambiguous extractions surface for you to confirm; clear ones extract automatically. The decision audit six months later answers from the structured layer, not from re-reading a thread.

4. Channel-of-origin tagging and reply-on-the-same-channel discipline

The “she doesn’t read email but I emailed her anyway” moment: the customer’s done every interaction so far on WhatsApp. You reply on email because that’s the channel that’s open on your laptop. She doesn’t see it for two days. Meanwhile she texts again, and the loop’s now two threads behind itself.

Solved looks like: every message in the thread carries its channel of origin. The default reply lands on the channel the customer’s been using, not the channel that’s convenient for you. Where channel-switching is appropriate (the homeowner who’s been texting wants the formal scope-of-work in email; the partner who’s been emailing wants a quick voice-note on a sensitive matter), the switch is deliberate and the thread records the reason. Channel routing per customer-type sits on the customer record; you don’t have to remember which channel each customer reads.

5. The thread is in your back-end, not your phone

The “phone died in May” moment: your iPhone has a swollen battery and gets replaced. The WhatsApp thread from March with the customer who’s just rung you back is gone with it. So is the voice-note where the homeowner agreed to the variation. So is the photo evidence of the leak that the agent’s now disputing. The customer remembers what she sent; you don’t.

Solved looks like: every conversation across every channel writes to the canonical back-end record at the moment it happens. Your phone is a window onto the record, not the record itself. The phone gets replaced and the threads carry across instantly. The five-year-old conversation from a customer who’s just rung you back is still searchable. The photo evidence the agent’s disputing is still attached, with the timestamp and the channel-of-origin intact. The deposit-deduction case at month eighteen of the tenancy gets answered from the record, not from a screenshot of a missing thread.

6. Hand-off with full context, not a “sorry, what’s the situation”

The “the apprentice picked it up” moment: the partner’s been talking to the client for three weeks. She’s on holiday and the associate’s picked up the file. The first conversation starts with “sorry, what’s the situation?” and the client feels it immediately. Or - the AI agent’s been handling the first three touches, but the deal’s now worth a voice call from you, and you don’t know what’s been said in the WhatsApp thread.

Solved looks like: the next participant - the associate, the apprentice, the on-call clinician, the partner stepping in for the principal - opens one URL and sees the full thread. The structured-event extraction means the decisions and the dates and the agreed prices are surfaced at the top; the conversational history is searchable below. Handing the conversation between human team members (or from the trainable inbound AI agent to you when the situation needs you) carries every bit of context. The “sorry, what’s the situation” re-start goes away.

How the thread engine runs, by default

The default reactive-trade shape runs:

• Inbound on any channelcustomer texts, WhatsApps, rings, emails, web-chats, or DMs. The inbound writes to the per-customer record with channel of origin tagged. The trainable inbound AI agent reads the inbound, qualifies, replies, escalates if the situation needs you.
• Outbound from you or the agentevery reply writes back to the same thread. Default channel is the one the customer’s been using; deliberate channel-switches record the reason.
• Structured-event extractiondecisions, dates, agreed prices, scope changes, authorisations, consent moments extract automatically. Ambiguous extractions surface for confirmation.
• Three-way scope where applicablefor relationships involving multiple parties (lettings, conveyancing, construction, vet handover), each party’s portal view is scoped to the slice they’re entitled to see. The audit trail is the whole thread.
• Continuous capture across channelWhatsApp thread, SMS thread, email thread, voice transcript, web-chat log, in-app message - all merge into the canonical record by customer identity (phone number / email / portal login), not by channel.
• Hand-off with full contextwhen the next participant picks up the file (associate stepping in, apprentice running the second visit, on-call clinician taking the OOH handover, AI agent handing to you for the voice call), one URL carries the thread.

Per-vertical tuning lives on top - the WhatsApp-native plumber’s thread doubles as the job record with the leak-video, voice-note reply, invoice link, and receipt all in the same conversation; the lettings three-way runs the per-party portal scoping with the tenant / landlord / agent views differentiated; the landlord-CP12 round runs the access-coordination thread per property with the engineer / agent / landlord / tenant routing; the conveyancing chain runs the buyer / seller-solicitor / lender / estate-agent slice; the construction programme runs the programme-manager / client / sub / QS slice; the vet OOH handover runs the consented-and-shared patient summary that flows into the OOH visit and the OOH summary writing back to the PMS.

Who this is for

The shape repeats across every UK SME whose relationships span multiple channels and multiple parties.

WhatsApp-native trades - plumbers, electricians, gas engineers, roofers, locksmiths. The customer texts a leak video → ticket auto-creates → your voice-note reply transcribes onto the ticket → invoice generates from the same ticket → payment-link drops back into the same thread. The personal-WhatsApp-as-business-tool problem closes; the canonical record carries forward.

Three-way comms - lettings agents, plumbers/lettings, decorators/property-maintenance, gas-engineers/landlord-cp12, electricians/eicr-specialist. Tenant + landlord + agent + contractor on one record; per-party view scoping; access-coordination thread per property; the agent-portal side carries through to Customer & Third Party Portal.

Multi-party professional services - professional services, solicitors, construction. The client + procurement + partner + associate thread; the conveyancing chain buyer + seller + lender + agent; the programme + client + sub + QS comms - all on one record per relationship.

Clinical handover - vet practices, private GPs, domiciliary care. The consented-and-shared handover from your practice into the OOH service, the OOH summary writing back, the family’s evening updates flowing into the same patient record - with the right consent-mediated scoping at each step.

Sensitive arrangements - funeral directors. The arranger’s thread with the family alongside the venue / celebrant / florist / obituary correspondence - one canonical record so the second arranger picking up the file isn’t reconstructing it from notepads and a shared inbox.

Same engine; different parties; different channel mix; different scoping rules.

The closest thing we’ve already built

mendbuddy - our own multi-channel agent platform. The per-customer thread is mendbuddy’s first-class object; every voice call, SMS, WhatsApp, web chat, Facebook Messenger DM, Instagram DM, and iOS app message writes to the same record. The clearest reference shape for any vertical that wants a canonical thread per customer across every channel they use.

RepairMinder - our own workshop-management software - runs the customer-side ticket-status thread across SMS + WhatsApp + the customer-facing portal with the conversation history per customer searchable. The structured per-customer ticket record pairs with the comms thread so the “where’s my phone” question and the “can you re-send the receipt” question are both answered from one record.

mendmyi - the founder’s own UK device-repair business - runs the customer-thread shape at the small-ticket end; the same WhatsApp-thread-as-job-record pattern that reactive trades need is live at the repair-bench scale.

pharmaceutical-analytics.com is the dashboard shape behind the studio / partner view of every active thread - open conversations sorted by aged-state, structured-event extraction surfaced as project-level decisions, the “what did we agree across our open relationships” question answered from one screen.

Tell us where the thread is now

What you do, what channels your customer comms currently runs across (SMS / WhatsApp / email / web chat / voice / a portal / a Slack / a job-app), how often the “what did we agree last week” search costs you a midnight half-hour, and which three-way relationships (tenant + landlord + agent; buyer + seller + lender; programme + sub + QS; practice + OOH + family) are the ones where the wires most often cross. Tell us the most expensive miscommunication of the last quarter and we’ll come back with a sketch of what we’d build so the next one doesn’t go the same way. No demo, no calendar widget. Email reply, scoped sketch, you decide.

FAQ