Quick Answer

When one enquiry creates two records, tasks or replies, first identify what repeated: the customer’s submission, delivery of an event, or the business action itself. Preserve the original evidence and test with synthetic data before deleting records or changing the live workflow.

Name the duplicate the business can observe

Start with a bounded statement such as one test submission created two owner tasks. That describes a result you can verify. Two notification emails alone do not prove there are two customer records, and two records do not prove the customer clicked twice.

For an Island business with a small enquiry queue, the immediate cost may be two people returning the same call or a customer receiving conflicting answers. Identify that specific unwanted outcome before buying a replacement form or adding an AI classifier.

Draw the handoffs for one request

Write down the browser submission, stored enquiry, delivery event, CRM record, owner task and customer reply. Record a redacted identifier and timestamp at each relevant stage. If a step has no evidence, mark it unknown.

A customer email address is not a safe unique identifier for a request: the same person may ask a second question or discuss another job. Text that looks similar can also represent separate intent. Preserve the request identity rather than merging everything from the same sender.

Understand why retries need a policy

Stripe’s webhook documentation provides a concrete example: event deliveries can repeat, and handlers should track processed events. It also distinguishes repeated delivery of one event from separate events about the same underlying object. That is platform guidance for Stripe, not proof that a particular contact-form provider behaves identically.

The broader design question is whether repeating a delivery repeats an action. Ask the maintainer how the workflow recognises an already-handled request, how that decision survives a restart, and how two simultaneous deliveries are prevented from both creating the same task.

Agree what counts as a new request

Define the rule in plain language before implementation. A retry of the same accepted submission should not create a second owner task. A genuinely new enquiry from the same customer should remain visible. A customer correction may need a linked update rather than silent deletion.

A time window or similar wording can flag possible duplicates for review, but neither establishes identity by itself. AI can assist a reviewer with a summary; it should not be the sole authority for erasing requests or suppressing replies.

Run a safe acceptance test

Use a test environment or an explicitly isolated synthetic route. Submit a harmless request, repeat its delivery through the supported test method, and confirm the agreed action occurs once. Then submit a distinct request from the same fictional customer and confirm it remains separate.

Ask the maintainer to test restart and overlapping-delivery cases too. Define the expected record, task and reply counts before the test. Do not trigger real payments, customer messages or bulk deletion to demonstrate a deduplication change.

Use an acceptance record that can fail

Write the test conditions before the maintainer demonstrates the repair. For the first synthetic request, expect one stored enquiry and one owner task. Replaying its supported delivery should leave those counts unchanged. For a separate request from the same fictional sender, expect an additional enquiry and task. If either expectation fails, the repair is not accepted.

Include the delayed-retry case: let the first action complete, restart the test worker where applicable, and replay the same event. A temporary in-memory list may pass an immediate retry test and fail after restart. The implementation choice belongs to the maintainer, but the business should receive the observed result, test environment, date and remaining limits.

Also ask what happens when a downstream provider accepts an action but the acknowledgement is lost. The safe response is evidence-based reconciliation, not an automatic second reply. Keep the test identifiers and outcome counts in the handover without retaining unnecessary customer data.

Keep an exception path

When the workflow cannot tell whether a reply was sent, mark the outcome uncertain and check the provider record before sending again. A failed network response is not necessarily a failed business action. Record the evidence used to resolve it.

If duplicate records already exist, retain a recoverable copy and get an owner-reviewed merge decision. The repair should prevent recurrence while preserving genuine enquiries. No automation can infer the customer’s intent solely from two similar messages.

Bring Halo one bounded example

The useful initial brief is the form URL, the unwanted repeated action, the systems involved and a redacted example showing the handoff where evidence diverges. Keep account secrets and customer exports out of the initial audit.

Halo’s first task is to establish a safe route and testable scope. A successful synthetic check proves the checked behaviour; it does not prove more leads, increased revenue or flawless operation under every future condition.

FAQ

Should I merge all enquiries with the same email address?

No. One customer can make several genuine requests. Use request identity and owner review rather than email address alone.

Can a retry create a duplicate task?

Yes, if the workflow repeats the action for a repeated delivery. The maintainer should demonstrate the handling of retries and simultaneous deliveries.

Does an AI duplicate score justify deleting a lead?

No. It can be a review signal, but the underlying requests and business rule need checking.

What should a duplicate-enquiry test prove?

A repeated delivery produces the agreed action once, while a distinct new request remains visible. Test safely with synthetic data.

Next step

Bring Halo one redacted duplicate example and the action that should have happened once. Start with a bounded enquiry-route audit before commissioning a wider rebuild.

Sources