Use social CRM to connect an incoming conversation with the right customer record, a named reply owner and an explicit next action. Keep the channel identity and customer identity distinguishable until their relationship is established. Test reassignment and follow-up with a fictional conversation before relying on the workflow for customer service.
A message can arrive through a social profile while the related order or earlier enquiry uses an email address. The practical problem is deciding which information belongs together and who should respond. A useful brief describes that decision with an example, then asks the proposed system to demonstrate the relevant record and conversation behaviour.
This article uses Chatwoot’s own contact, inbox and conversation guides, checked on 24 October 2026, as concrete product examples. The original worksheet applies those mechanisms to a proposed social-enquiry handover. For the broader selection process, use choosing a CRM; this guide stays with identity, conversation ownership and continuity through a handover.
What connects a social message to a customer record?
Chatwoot distinguishes a channel type from an inbox connected to an account. Every Chatwoot conversation lives inside an inbox. Chatwoot supports Facebook Page direct messages through its Facebook Messenger channel. Chatwoot supports Instagram direct messages through a connected Instagram Business account. Its inbox documentation describes the connection requirements. Record the actual business account, inbox and intended message route in the brief, rather than using a social network’s name as the complete configuration description.
Chatwoot’s contact record is account-wide and can have conversations across channels. Inbox membership is explicit; adding an agent to the account does not grant access to every inbox. These distinctions help frame separate questions about identity and staff access. Ask which contact the sample message belongs to, then ask which staff member can see and act on the inbox where it arrived.
Treat a similar display name as a reason to investigate, rather than a complete matching rule. In the proposed identity register, retain the channel reference, claimed relationship, evidence checked and reviewer. Decide which discrepancies require a second look. A customer asking about another person’s order needs the organisation’s approved verification process, not an improvised record match based on the message alone.
Chatwoot can import contacts from a CSV file. Chatwoot contact filters include Contact Identifier. Chatwoot contact filters include custom attributes defined on the account. A filtered contact list can be saved for later use. These are documented in the contact guide. They provide useful mechanisms for organising a known set of records, while the team remains responsible for choosing what each identifier and attribute means.
Write the source and owner of each imported field into the implementation brief. If an identifier comes from an existing CRM, establish how the proposed connection will preserve and correct it. Keep any integration requirement visible as a requirement to design and verify. The existence of a contact field does not, by itself, demonstrate a working connection to another system.
Who owns the reply after a handover?
A Chatwoot conversation’s assignee identifies the agent responsible for replying. Conversation participants can collaborate without taking over that responsibility. The conversation toolkit guide makes that distinction explicit. Use an assignee for the reply owner and participants for the colleagues whose input is needed, following the actual configuration under review.
Changing the assignee and changing conversation status are independent actions. Chatwoot describes private notes as messages visible to the team inside a conversation. For a proposed handover, write down the unresolved question, evidence already collected and action expected from the next owner. Keep the internal explanation separate from the response that the customer should receive.
Chatwoot macros are saved sequences of actions run manually. Chatwoot macros can assign a team. Chatwoot macros can add a label. Chatwoot macros can resolve a conversation. Inspect the actual macro before including it in a handover procedure. The process owner should be able to explain what each step does and whether any step sends a customer-facing message.
Use this original handover card alongside the proposed configuration. Each row should be answerable from the sample record or the agreed business process.
| Handover field | What to record | Question for the next owner | Evidence of completion |
|---|---|---|---|
| Arrival | Channel, inbox and conversation reference | Where did the customer contact us? | Intended message is present |
| Identity | Contact reference and verification state | Which relationship has been established? | Matching decision and its basis |
| Request | Customer’s question in plain language | What remains unresolved? | Scope of requested action |
| Reply owner | Named responsible agent | Who will send the next response? | Assignee visible in the agreed view |
| Contributor | Colleague and reason for involvement | What input is needed? | Internal contribution attached |
| Next step | Action, responsible person and agreed review point | What would move this forward? | Recorded outcome or owned exception |
Avoid filling the next-step row with “follow up” alone. State what the owner needs to find out or do, and identify the record that will show the result. Choose the review point through the actual service process. Keep any customer commitment grounded in what the responsible team has agreed to provide.
A worked social-enquiry handover
Consider a hypothetical customer who sends an Instagram message asking about an earlier enquiry. The social display name differs from the name on the email enquiry. A second person with a similar name is already in the contact list. Use fictional contacts and an authorised test arrangement; this is a proposed exercise rather than a report of real messages or a completed deployment.
Prepare the expected record relationships before the demonstration. Give the two contacts distinct identifiers and specify what evidence would establish the intended match. Ask the first agent to locate the incoming conversation, record the uncertainty and use the approved verification route. The reviewer should be able to distinguish a possible match from a confirmed relationship in the resulting notes.
Then introduce a question that needs another colleague’s input. Keep the first agent as reply owner while adding the colleague through the proposed collaboration route. Record the question asked internally and the evidence returned. Inspect whether the customer-facing draft accurately reflects the information received without copying unnecessary internal detail into the reply.
Next transfer reply responsibility to a second agent. Ask that person to explain the customer’s request, the identity decision and the remaining action using the handover record alone. Record where they had to ask for missing context. Revise the card or proposed configuration to address those observed gaps when the exercise is actually run.
Finally include a further customer message after the team considers the enquiry complete. Define the expected ownership and review process before testing that case. Inspect the actual conversation route and state, then record whether someone can identify the next responsible action. Keep the customer’s continued question visible until the business’s agreed completion condition is met.
Retain the sample references, chosen settings, observations and unresolved cases for handover. Review the arrangement when channels, inbox membership or reply ownership rules change. For transaction-record boundaries, see connecting CRM and POS records. Discuss the wider integration through web development and business systems, or get started with a representative conversation and its difficult handover.
By Spout Team. AI-assisted drafting by Codex using the linked primary documentation.