Stop repeat submissions from creating duplicate enquiry work

Locate where duplication begins

Compare the timestamps and identifiers of apparently repeated enquiries. Two emails for one stored request suggest a notification problem. Two stored requests seconds apart may reflect repeated taps, retry behavior or separate submissions. Identical names alone are not enough: the same customer may ask about different properties or add a missing detail.

Separate request identity from contact identity

Wix automations can have multiple actions and frequency settings. Inspect which rules act on your form, but do not use a contact-level limit as a substitute for understanding request identity. A workflow that suppresses every later message from one person can hide real corrections. Decide which records are genuinely copies and which require independent attention.

Source checks: Wix Forms: Creating Automated Email Responses for Form Submissions · W3C WAI: User Notification

Reproduce one deliberate submission

Use a marked request and watch both storage and notifications. Ask the maintainer to inspect duplicate-submit protection in a safe test. Staff should not respond while the test is running. Document the original request identifier, any duplicate record and each email generated so the change addresses the exact duplicated step.

• Submit TEST-DUPLICATE-801 once and count saved records separately from alert emails.
• Check whether overlapping notification rules send the same alert to the same recipient.
• Test rapid repeated taps in an agreed environment and inspect the resulting identifiers.
• Add or repair the pending state and server-side duplicate handling where the platform supports it.
• Group confirmed copies under one staff owner while preserving their timestamps and original records.

Keep legitimate second messages intact

Disabling all follow-up notifications may make a second genuine request invisible. Deleting similar records before review can remove an updated phone number or job description. A disabled button does not prevent every network retry. Ask the developer to explain how the receiving system handles repeated requests rather than relying only on a visual spinner.

Track duplicate handling rather than duplicate names

Count verified duplicate records, duplicate alerts and duplicate staff responses separately. Keep changes in total enquiries out of this calculation until test records and copies are excluded. Review examples of merged messages to ensure meaningful updates remain available. A lower duplicate count is useful only if customers can still send legitimate new requests.

Assign one reviewer to a grouped enquiry

Use an enquiry reference in the handling log and note which copies belong to it. Tell staff who sends the response and where new information is appended. If a customer resubmitted because the receipt was unclear, improve that message as part of the repair. Do not treat the customer as the source of the technical problem.

Worked example: an illustrative customer journey

For example, a painting company receives two emails for TEST-DUPLICATE-801, but the dashboard contains one request identifier. Two automations notify the same mailbox. Removing the redundant notification action leaves one saved record and one email on the next marked test.

Later, the same fictional contact sends a separate request for another property. Staff retain it as a new enquiry. This distinction fixes duplicate handling without assuming that one person can have only one legitimate job.

Questions about this task