Review and merge duplicate enquiries carefully

Separate a matching contact from a matching issue

The same contact can ask about billing today and request a new product tomorrow. Merging on email alone can erase a real task. Compare contact details, submission times, product, order reference and question summary. Use separate outcomes for the same contact, the same issue and an uncertain match. Automated matching can propose candidates, but the decision to connect or merge them should follow the meaning of the request rather than a single shared value.

Preserve candidate and canonical identifiers

If Q-401 and Q-408 concern the same order, store a canonical case ID and the related submission IDs. Retain the original receipt time, message, attachments and channel for each submission. Mark the secondary item as linked rather than deleting it from the history. Remove it from the ordinary unassigned queue only after an owner confirms the relationship. A follow-up may contain new evidence, so do not overwrite it with the older message.

Normalise matching fields without changing the evidence

Create comparison values by trimming accidental surrounding spaces from identifiers, while retaining the original values. Do not aggressively shorten the customer’s free text to make two messages look similar. Decide that a similar company name, shared surname or repeated question wording is insufficient on its own. A general company mailbox can represent multiple people and projects. When a match is uncertain, leave both tasks visible and ask the customer or responsible owner to clarify.

Choose one owner and response route after review

Once the issue matches, decide the responsible owner, next response deadline and message history to use. Do not keep two independent reply workflows active after linking the cases. Add a reference to the new information on the canonical case and record the reviewer on the secondary record. The customer usually needs assurance that the information was received and one person is handling it, not a detailed explanation of your internal duplicate-detection system.

Make mistaken merges reversible

Preserve the previous owner, status and due date so a mistaken merge can be reversed. Unlink the records, reopen the original case ID and review reminders or reply tasks that were suppressed. Reuse the original submission rather than copying its entire history into a new duplicate. Record who linked the cases and why. Reversibility is especially important when a later customer message reveals that two apparently similar requests had different delivery or billing requirements.

Evaluate false matches as well as duplicates removed

Check examples for a new issue from the same person, the same issue through another channel, two people with the same name, a shared mailbox and an attachment-only follow-up. Counting removed duplicates rewards over-merging. Also check that distinct work remains visible, new files survive and the canonical case keeps the correct deadline. Restrict access to reviewers who are permitted to see the customer details needed for the match.

Q-401 and Q-408: retain the follow-up evidence

Q-401 asks about dimensions; Q-408 contains the same order reference and an extra photograph. After confirming the issue matches, link Q-408 while preserving its photograph and receipt time. Do not extend the canonical deadline automatically merely because new evidence arrived. Q-410, a billing question from the same customer, remains separate. If the photograph later proves to concern another product, unlink and reopen Q-408 under its original ID. Walking this reversal demonstrates that duplicate review preserves evidence instead of using deletion to make the queue look smaller.

Choose a tool and budget around the actual workload

At low volume, a reviewed candidate list may be all you need. If you automate matching, budget separately for candidate generation, human review and reversal of mistakes. A workflow with fewer execution credits can still be expensive if it frequently joins unrelated cases. Start with proposed matches rather than automatic merges, and examine a small sample of false positives. When the evidence is weak, preserving two visible cases is often cheaper than repairing a wrongly closed enquiry.

• Build an Airtable enquiry tracker: intake, owners and follow-up states
• Connect Make and Airtable: search, create and update intake records
• Design webhook handling for duplicates, ordering and safe replay