Stop duplicate follow-up rather than trying to stop customers contacting you twice. Give each enquiry a reference, match recent submissions using verified details and request scope, and keep both channel histories under one operational case. If the evidence is unclear, ask a person to decide before combining the work.
A website confirmation should explain how to continue on WhatsApp using that reference. Customers can still choose either channel. The proposed workflow below makes those choices visible to the same team without assuming every repeated contact is a duplicate.
Define what counts as the same enquiry
Treat submissions as the same enquiry only when they concern the same unresolved request. The same customer can legitimately need two quotes, contact different branches or raise a new issue after a previous job closes.
Separate three records in your design:
- Contact: the person or organisation making contact.
- Case: the operational request that needs an owner and a next action.
- Event: an individual website submission, WhatsApp message or delivery attempt.
Contact deduplication does not settle case deduplication. Source: HubSpot's record deduplication documentation describes matching contacts by email and companies by domain. That does not establish that two messages concern the same work. It also notes that companies created through its API are not deduplicated by company domain.
For this proposed process, write a plain-language case definition before configuring tools: “One request for a specified service at a specified site.” Agree how amendments, complaints and new locations should behave. AI CRM integration provides useful terminology for connecting intake records to the team's working system.
Capture both channels in a common event format
Send each channel into the same intake process, while keeping the original message and its source. Matching becomes difficult if website records contain structured fields but WhatsApp records contain only a summary.
Use this proposed minimum data dictionary:
| Field | Meaning and handling |
|---|---|
| Event key | Channel plus source event ID; unique for each received message or submission. |
| Channel | Website or WhatsApp; never overwritten after linking. |
| Source and receipt times | When the sender submitted and when intake received it, with time-zone information. |
| Claimed case reference | Reference supplied by the customer; unverified until checked. |
| Contact values | Original and normalised phone or email, plus verification status and method. |
| Request scope | Service, site or branch, and requested action; unknown values stay unknown. |
| Original content pointer | Controlled-access location of the message, form and attachments. |
| Case ID and decision | Linked case, rule used, reviewer where applicable, and decision time. |
Propose consistent phone formatting, including handling local and international South African formats. Formatting is not verification. Never infer ownership from a neatly formatted number.
Give the website submission its own event ID before delivery. Agree access and retention with the responsible privacy and security people rather than copying all customer information into every tool.
Give customers a reference they can reuse
Issue a case reference after the enquiry has been stored successfully, then show it in the website confirmation and acknowledgement. Do not display a success message that implies a case exists when storage failed.
A proposed confirmation might say: “Your enquiry reference is CASE-EXAMPLE. If you contact us on WhatsApp about this request, include this reference so our team can continue the same enquiry.”
The reference should identify work, not authorise access to private information. Someone typing a valid reference must not automatically receive the case history. Your team should decide what contact verification is appropriate before disclosing details or changing account information.
Where your channel setup supports it, a website WhatsApp button could prefill the reference. Otherwise, let customers copy it. Keep the ordinary contact route available for people who lose the reference or need a different service.
For the conversation design around this handover, see WhatsApp AI agents for business. The deduplication rules here are a proposed integration design, not a claim that a WhatsApp agent provides them natively.
Match references first, then inspect recent candidates
Use a verified case reference as the strongest routing signal, with customer association and request scope checked before linking. A reference copied incorrectly, shared by another person or attached to a different request needs review.
Without a reference, search recent cases using verified contact details. Then compare the service, site and requested action. Timing narrows the search; it does not prove that the requests are identical.
A proposed starting window is the previous 48 hours for unresolved enquiries. This is a design suggestion, not a measured optimum. Teams handling long quote cycles may need a different window. Keep explicit-reference lookup separate so an older case can still be found.
Use wording similarity only to suggest candidates. “Please quote for repairs” could describe several unrelated jobs. Do not turn a similarity score into authority to combine records.
If AI extracts fields from free text, require unknown values rather than guesses. Source: OpenAI's Structured Outputs documentation describes schema-constrained output and handling refusals or incomplete responses. A valid structure is not evidence that the extracted reference or address is correct. Validate fields against the original message and stored records.
Prevent retries and simultaneous arrivals creating extra cases
Make intake safe to repeat before adding customer-level matching. A webhook retry is a second delivery of an event, not necessarily a second enquiry from the customer.
Use the event key to record processing state. If a completed event arrives again, return the recorded result rather than creating another task. If an earlier attempt stopped midway, resume or repair it using stored progress, without repeating already completed writes.
Also protect case creation when website and WhatsApp events arrive together. Both processes could search, find nothing and create separate cases. Use a shared intake queue or a database transaction with an appropriate lock and a fresh candidate check before creation. A developer should select the mechanism for your storage system.
Source: Make's webhook documentation states that instant webhook scenarios run in parallel by default and offers ordered processing. Each webhook has its own queue, so ordering one channel alone is not a cross-channel guarantee.
Keep failed events visible for reconciliation. An acknowledgement that a webhook entered a queue should not be treated as proof that the operational case was updated.
Keep the histories and give one person the next action
Attach matching events to a case without deleting either channel's history. The case should show where each message came from, when it arrived and what it added.
Retain the original assigned owner unless an agreed routing rule or a person changes it. Add the second submission as an update, then decide whether it changes the next action. A follow-up saying “This is urgent” may be duplicate intake but still contain important new information.
Separate receipt acknowledgements from sales follow-up. Both channels may need acknowledgement, but one case should not automatically trigger two sales tasks. Before sending an outbound message, check the case's latest activity and task state.
Avoid treating the newest submission as the most authoritative source for all fields. Preserve conflicting addresses or contact details for review instead of silently overwriting them.
A customer-service agent workflow can help frame the handover to staff. Linking enquiries must not itself approve a refund, payment, account change or other consequential action. Those actions need their own controls and appropriate human judgement.
Use this proposed intake decision procedure
Apply the following procedure to each event before creating or suppressing follow-up work. Its timing window is proposed and should be evaluated against your actual enquiry patterns.
Reusable cross-channel intake checklist
- Store the original event, channel, source ID and timestamps before matching.
- Check the channel-plus-source-ID event key. Resume incomplete processing; do not repeat completed writes.
- Look up any supplied case reference and check its customer association and request scope.
- Without a usable reference, search unresolved cases from the proposed previous 48 hours using verified contact details.
- Compare service, site and requested action; record missing or conflicting fields.
| Evidence | Proposed decision | Follow-up handling |
|---|---|---|
| Verified reference, consistent customer association and scope | Attach to existing case | Keep owner; review new information. |
| One recent candidate, verified contact and consistent scope | Send candidate for human confirmation | Keep a visible review task. |
| Shared contact, missing scope or multiple candidates | Hold linking for review | Ask a targeted clarification question. |
| Clearly different request or no credible candidate | Create a separate case | Assign normal follow-up. |
| Previously completed event key | Reuse recorded processing result | Create no additional task. |
- Record the decision, evidence, case ID and reviewer where required.
- Confirm both channel histories remain accessible to authorised staff.
- Check outbound task state before sending another follow-up.
Completion check: every event has a traceable outcome, uncertain matches have an owner, and no history was deleted to hide duplication.
Walk through a normal match and uncertain arrivals
A normal match should continue existing work; an uncertain match should remain visible until a person resolves it. All references, times and records in this walkthrough are hypothetical.
At 09:00, a customer submits a website request for gate repairs at a Johannesburg site. Intake stores event WEB-A and creates case CASE-A. At 09:12, WhatsApp event WA-A arrives with CASE-A, consistent site details and a contact association verified through the team's chosen method.
The expected result is one case with both events, the same owner and an update noting the WhatsApp message. Any new access instructions remain visible. A later delivery of WEB-A reuses its recorded processing result rather than creating another task.
Now suppose WA-B arrives from a shared office number saying only “Please send the quote”. Two unresolved cases use that number, one for gate repairs and another for a different site. The proposed 48-hour window finds both. Intake must not choose whichever wording looks closest.
The reviewer sees both candidate summaries and asks which site or reference the sender means, without exposing unnecessary details. Pending clarification, WA-B remains an owned review item. If the sender confirms a different job, create a separate case. If two cases were already created for one request, a person chooses the surviving case, moves the event links and reconciles tasks while keeping a record of the correction.
Evaluate links before widening automation
Judge the process by correct handling, not just by a lower case count. A falling count could mean unrelated enquiries were combined or uncertain requests disappeared from staff queues.
Start with a proposed review-only pilot: the process recommends links while staff confirm them. Include straightforward duplicates, shared numbers, missing references, delayed deliveries and genuinely separate requests from the same customer.
Record false links, missed duplicates, repeated follow-up tasks, unresolved review items and lost events. For each false link, identify the rule and evidence that caused it. Check whether staff can reverse the link and recover the original task context.
Only consider automating the narrowest confirmed rule after the team sets acceptable limits and reviews the evidence. Keep a way to pause linking while continuing intake. Potential reductions in duplicate work depend on that evaluation, not on the presence of AI or a CRM deduplication feature.
If your business needs a shared intake process, Symaxx's lead generation systems service is the relevant starting point. For wider workflow planning, explore AI automation and get in touch to discuss the rules, exceptions and human review needed.
FAQs
Should we merge the contact records as well as the enquiries?
Not automatically. Two channel events can belong to one case without justifying a permanent contact merge. A shared business phone or inbox may represent several people. Review contact identity separately and preserve channel-specific details. If your CRM needs a merge, have an authorised person check associations and field conflicts first. The enquiry-linking process should remain reversible even if the contact records stay separate.
What if a customer sends WhatsApp from a different number?
Use the case reference to find a candidate, then check the association through your agreed verification process. A different number is not proof of a different enquiry, but the reference alone is not proof of identity either. Keep the incoming message in review and ask a focused clarification question. Do not disclose private case content or replace the stored phone number just because the new sender knows the reference.
Should we reopen a closed case when the website form arrives again?
Check whether the event is a delivery retry, a delayed submission or a new request. A completed event key should not reopen anything. A new event referring to closed work needs scope review: it may be a complaint, amendment or fresh job. Let the responsible team decide whether to reopen the case or create a linked new one. Preserve the earlier outcome and record why the new event changed the work.