Define a contact, an enquiry and a deal
One person can write several times about the same need or ask about a different purchase later. Keep the contact identity separate from each deal. For example, an existing company contact asking about a team course creates a new opportunity; a second message correcting the participant count updates that opportunity. Write down the event that opens a deal and the event that closes it so every message does not produce another unexplained record.
Start with an actionable record
A planning example might contain contact reference C-01, deal reference D-01, source channel, requested course, participant count, owner, stage, last customer question and a dated next action. These are example field labels to validate in your chosen tool. Add a field only when it changes routing or a decision. Keep an original source value when a conversation moves channels, and establish who may view or export the data before collecting unnecessary personal information.
Give each stage an observable entry rule
Use a short sequence such as new enquiry, details needed, ready for proposal, proposal sent, decision pending and closed. “Ready for proposal” requires the details your team actually quotes from; “proposal sent” requires a real proposal reference; “closed won” requires your defined commercial event. If the customer asks to wait, keep a next action date and owner. A stage should describe the evidence available, not the salesperson’s confidence that the deal will succeed.
Handle duplicates without losing separate purchases
Check for an existing contact and active deal before creating another. A matching name alone may be insufficient to merge records, especially when colleagues share a business account. Test a repeated message in one channel and the same enquiry arriving in another. Merge only after the team can establish that the identity and request match; preserve the history and any communication preferences. A separate course purchase by the same contact should remain a separate opportunity.
Make handoffs usable during absences
Pass the original question, confirmed details, unresolved point, previous promise and next action to the new owner. Have a colleague continue example D-01 without asking the customer to repeat the participant count. Define who receives unassigned work and who covers an absent owner. Pause incompatible automatic follow-ups when a person takes over or the customer asks to stop; otherwise the CRM can record a good handoff while the customer still receives a conflicting message.
Check roles, search and a small export
MaviBot has a CRM product; demonstrate the required fields, channels and permissions in a working example before migration. Let a salesperson and manager perform their normal tasks with their own roles. Search for the test contact from each intended channel and export a small sample. Verify that references, stages, owners and dates remain understandable outside the platform. Do not assume that seeing a field in the interface proves it is included in an export.
Use a pilot that distinguishes errors
Test a new enquiry, missing quote information, a repeated message, a second legitimate deal for an existing contact, a channel change, an absent owner and an opt-out. For each, record the expected contact, deal, owner and next step; compare those with the resulting records. Fix duplicate active deals and unowned enquiries before adding more stages or channels. This checklist defines what to verify, rather than claiming any candidate already passes it.
Review progression and maintenance
Review open deals without an owner or dated next action, overdue follow-ups, duplicates and time to first useful action. Count completed deals using the same commercial definition in every period. More contacts do not establish more revenue. Include staff cleanup, integrations, exports and ongoing administration alongside the subscription when comparing the CRM with the current workflow.
Questions and answers
Should every new message create a deal?
No. Update the active deal when the message concerns the same request. Create a separate deal when there is a distinct purchase or business need.
Which fields belong in the first version?
Use the fields needed to identify the request, assign an owner and choose a dated next action. Add others only when somebody uses them to make a decision.
Can we merge contacts that have the same name?
A name alone may not prove identity. Review the channel references and context, and preserve separate purchases and communication preferences when resolving duplicates.