“CRM for DMs” is sold as a single idea and is really three records that behave very differently. Confusing them is why teams end up with customer history trapped in a messaging tool, scoped to an account id, impossible to report on and impossible to merge with anything.
The platform gives you an identity you cannot alter. The inbox gives you a conversation you can annotate. Your own system holds the only record that can describe a person – and the three connect through a key the customer hands you, never automatically.
Getting that straight early is cheap and getting it wrong is expensive, because the cost arrives as a migration rather than as a bug. Why identities cannot merge in the first place is explained in the unified social inbox.
Key takeaways
- Three records: the platform identity, the conversation, and your own customer record. Only the third describes a person.
- An inbox is not a CRM. History kept only there is scoped to one platform identity and cannot be merged or reported on properly.
- The three connect through a key the customer gives you – order number, email, booking reference. There is no automatic link.
- Store the key, the outcome, the promises made and the consent given. Leave the full transcript where it is.
- Write one outcome line per resolved conversation. It is worth more than any amount of stored transcript.
- Pushing conversation data into your systems makes you responsible for it – set a retention period at the start.
- Per-customer lifetime value across social channels is not computable from platform data. It is computable from yours, once the key is captured.
The Three Records
Different owners, different rules, different lifespans.
The Platform Identity
An account id on one channel, a phone number on another. It is handed to you, you cannot add fields to it, and you cannot connect it to the same person’s identity elsewhere because no platform exposes that link.
It is also not durable in the way a customer record is: a person can change the handle, lose the number, or message you from a second account, and nothing announces that it happened.
The Conversation Record
The thread itself, plus whatever structure your inbox allows around it – lists it belongs to, notes your team attached, templates used. This is genuinely useful and it is scoped to one platform identity.
Treat it as a working record rather than as history. It answers “what is happening with this thread?” and not “who is this customer?”.
The Customer Record
In your own system: orders, value, previous issues, consent, whatever you already hold. It is the only one of the three that can describe a human being rather than an account, and it is the only one you fully control.
If you have no such system, the honest version is a spreadsheet keyed on order number. That is a real answer for a small business and far better than letting the inbox become the archive.
The Join Key
Everything useful depends on this one habit.
Ask Early, Not When You Need It
An order number, an email address, a booking reference – something the customer already has and your systems already know. Ask for it in the first couple of messages, before anybody needs it, because asking later interrupts a conversation that is already going somewhere.
With the key, the conversation can be as informed as your data allows. Without it, every thread starts from nothing regardless of how good your CRM is.
Capture It Where It Can Be Reused
A key sitting in message four of a thread is not captured. Collected replies are available to later steps as variables, so the flow can take the number once and both look it up and push it onward – the mechanics are in social inbox integrations.
The difference between a key that is typed and a key that is stored is the difference between a lookup and a CRM.
Accept That Some Threads Never Join
Plenty of conversations are from people who have never bought anything and have no key to give. That is fine – they are prospects, not records, and trying to force an identity onto them produces junk data.
Record the outcome, leave the rest, and let the key arrive when there is something to attach it to.
What You Become Responsible For
Short section. Worth reading before the first webhook rather than after.
Moving Data Moves the Obligation
While a conversation lives on the platform, the platform carries much of the weight. The moment you copy it into your own systems you are holding customer data you must secure, honour requests about, and eventually delete.
None of that is a reason not to do it. It is a reason to decide the retention period at the start, when it costs a sentence.
Record Consent as an Event
What the customer agreed to, and when. Consent recorded as a flag loses the date, and the date is the part that matters if anybody ever asks.
This also keeps you honest about outbound: an opt-in to order updates is not an opt-in to marketing, and treating them as the same is how businesses lose a channel.
Do Not Copy What You Did Not Ask For
Customers volunteer things – health details, documents, identity numbers – because a DM feels informal. A thread is not the place for it and your CRM usually is not either.
Handle it in the conversation, do not replicate it into storage, and where it is genuinely needed move the customer to a channel built for it.
What You Can and Cannot Report On
Set expectations before somebody asks for the dashboard.
| Question | Answerable? | From where |
|---|---|---|
| How many conversations per channel? | Yes | The inbox |
| How fast do we reply? | Yes | The inbox, one definition everywhere |
| Which channel produces revenue? | Partly | Only with a key captured and joined |
| Lifetime value of a social customer | Yes, with the key | Your system, never the platform |
| Is this the same person as on WhatsApp? | No | Nothing exposes it |
| How many unique customers messaged us? | No | Unique identities, not people |
Those reply-time numbers only compare if every channel is measured the same way, which is one of the four things the unified social inbox is for.
Setting It Up
Half a day of decisions and one flow change.
- Decide where the customer record lives. Your CRM, your database, or a spreadsheet keyed on order number. Not the inbox.
- Pick one join key and use it everywhere. Order number is usually best: customers have it, your systems know it, and it is not sensitive.
- Ask for it in the first two messages. Before it is needed. Asking mid-conversation interrupts something that was working.
- Write one outcome line per resolved conversation. What they wanted, what happened. This is the habit that compounds.
- Record consent with a date, as an event. A flag without a date answers nothing if you are ever asked.
- Set a retention period before the first webhook fires. It costs a sentence now and a project later.
Doing It With DMpro
What exists, and what deliberately does not.
The Conversation Side
DMpro holds the conversation record: threads grouped by the person on each platform, conversation lists you create and maintain, conversation metadata, and saved message templates for consistent replies.
Lists are the practical structure here – by status, by owner, by topic – and they are the right place for working state.
There Is No Tagging or Segmentation Layer
Said plainly because it affects how you plan. There is no contact-tagging or audience-segmentation feature, so DMpro does not pretend to be your CRM.
Given that the record would be scoped to a single platform identity anyway, that is the right place for the boundary – but it means the customer record has to live in your system, not in the inbox.
Getting Data Where It Belongs
A webhook step posts the conversation’s data, including the answers the customer typed, to a URL you control – which is how the key and the outcome reach the system that should hold them.
Keep the Customer Record Where It Belongs
The expensive mistake is letting a messaging tool become the archive. History kept there is tied to one account id on one platform, and the day you change tools or the customer changes handle, it is gone.
DMpro handles the conversation side – one queue, lists, notes, saved replies – and pushes the key and the outcome into your own systems through a webhook, where the customer record belongs.
Conclusion
Three records. The platform identity is given and cannot be merged. The conversation record is working state, useful and correctly scoped to one channel. The customer record is yours, and it is the only one that can describe a person.
They connect through a key the customer hands you, which is why asking for an order number in the first two messages is the single habit that makes social DMs reportable at all.
Store the key, the outcome, the promises and the consent. Leave the transcripts. And decide the retention period on the day you start moving data, because that is the day the obligation moves with it.
Frequently asked questions
Can a social inbox work as a CRM?
Not as the customer record. An inbox holds the conversation – the thread, lists and notes – scoped to one platform identity. The record that describes a person has to live in your own system, joined by a key the customer gives you.
How do I link a DM to a customer in my CRM?
Ask for a key the customer already has – an order number, email or booking reference – in the first couple of messages, then join on it in your own system. There is no automatic link between a platform identity and your records.
Can I see lifetime value for a social customer?
Yes, but from your own data rather than the platform’s, and only once the join key has been captured. Platform identities carry no purchase history.
What should I store from a conversation?
The join key, a one-line outcome, any promises made, and consent with a date. Leave the full transcript – it is rarely read and increases what you must protect and later delete.
Does DMpro have contact tags or segments?
No. It provides conversation lists, conversation metadata and saved message templates for the conversation side, and a webhook to push data into your own system, where the customer record belongs.
Can I count unique customers across channels?
No. You can count unique platform identities, which is not the same thing – the same person on two channels counts twice, and nothing exposes the link between them.
