CRM or shared inbox: which does a service business actually need?

A shared inbox organises messages. A CRM organises people. Most small service businesses start with one, discover the gap, and bolt on the other, which is how a customer's history ends up split across two systems that disagree.

What each is actually for

A shared inbox answers: what needs a reply right now? It gives you a queue, assignment so a message has an owner rather than an audience, and a sense of what is unanswered. It is organised by conversation, and its natural unit is the thread.

A CRM answers: who is this person and what has happened with them? Contact details, history, stage in your pipeline, notes, value. Organised by person, and its natural unit is the contact.

The failure of using only an inbox: a customer texts and nobody knows they were in last month, complained, and got a discount. Their history is three threads back and nobody scrolls.

The failure of using only a CRM: somebody messages and nothing tells you it needs an answer. CRMs are built for deliberate outbound work, not for a queue that arrives on its own.

Why "we'll use both" goes wrong

The obvious answer is to buy one of each. In practice, at a business with under fifty staff, it produces a specific mess:

The link between them is manual. Somebody has to notice a message came from a known customer and log it. During a busy morning, nobody does.

They disagree about who a person is. The inbox knows a phone number. The CRM knows an email. Nothing connects them, so one human becomes two records with half a history each.

Notes land in whichever tool was open. Six months later the important context (this customer is difficult about timing) is in the tool nobody thought to check.

The channel dictates the record. A conversation that started as an Instagram DM lives in the inbox; one that started as a form fill lives in the CRM. Same customer, two universes.

The thing to actually look for

Not "inbox with CRM features" or "CRM with an inbox". Ask instead: does a message from a customer automatically attach to that customer?

That is the whole question, and it has an unglamorous answer: identity resolution. When a text arrives from a number, does the system recognise whose number it is and put the conversation on their timeline? When the same person messages on WhatsApp from that number, is it the same contact?

If yes, inbox and CRM are two views of one thing and the distinction stops mattering.

If no, you have two tools and a human being asked to be the integration.

What identity resolution needs to handle

It is harder than matching a string, and it is worth asking a vendor how they do it:

• The same number on SMS and WhatsApp should be one person.
• Number formatting. (555) 123-0000 and +15551230000 are the same number and a naive match misses it.
• Somebody with an email and a phone who uses each on different channels.
• Genuine duplicates from CSV imports and manual entry, which no automatic rule should be confident about, so it should be suggested for merge rather than merged silently.
• Merging without losing anything. This is where systems quietly fail: merge two contacts and the appointments, notes, or opt-out flag attached to the losing record vanish. Ask what happens to the merged record's history.

That last one has a compliance edge. If a person's opt-out is attached to the contact and the contact is merged away, somebody who told you to stop is reachable again.

What a service business actually needs

Not a sales CRM. Pipelines with seven stages and forecasting are built for a different job: long, multi-touch B2B deals with named owners.

A dental practice or a plumber needs:

• One record per person, with everything on it: every message on every channel, appointments, notes, tags.
• A queue of what needs a reply, with an owner.
• Enough lead structure to know who has not been followed up, which is a short list of stages, not a funnel.
• Search that finds a person by any of their identifiers.
• A timeline you can read, so somebody picking up a conversation cold sees the history in one place.

Questions for a demo

1. "Text this number, then email from a different address. How do I see one person?"
2. "Show me merging two duplicates. What happens to the appointments and notes on the one that loses?"
3. "Where does an internal note live, and can the customer ever see it?"
4. "Somebody replies STOP. Where is that recorded: on the conversation, or on the person?" (The second is the right answer, and it is the most common thing to get wrong.)
5. "Can I export it?" Ask now, not when you leave.

How Frontiva does it

One contact per customer across channels: identity resolution matches the same phone number arriving over SMS and WhatsApp to a single person, so the inbox and the CRM are two views of the same record rather than two systems to reconcile.

Merging moves everything: identities, notes, timeline, conversations, appointments, leads, tasks, in-flight automations, attribution and the record that somebody asked you to stop. That list is explicit because it was got wrong once: an earlier version moved four of those tables and deleted the rest, and a test now enumerates every foreign key pointing at a contact and fails when a new one appears that merging does not handle.

Duplicates that no automatic rule should be confident about are suggested rather than merged, and everything exports as CSV.