The handoff is where leads get lost

An enquiry form is only the beginning of a lead journey. The next part happens between an inbox, a customer record and a person who needs to respond. That handoff deserves as much attention as the form itself.

A useful automation makes the state of the lead visible. Someone should be able to answer what arrived, who owns it and what needs to happen next.

Map the current journey

Follow an enquiry from submission to response. Write down each destination it passes through, including the spreadsheet someone updates by hand and the notification that only one person receives.

At every step, ask what confirms success. A notification being delivered does not mean a person accepted responsibility. A record being created does not mean a response was sent.

Use a few recent, representative enquiries to check the map. Keep the examples inside the systems where your team is already authorised to use them.

Give each lead an explicit state

A short set of states is easier to manage than a collection of implicit signals. For example, your team might use received, assigned, awaiting response and closed.

Define who can move a lead between states and what each transition means. “Awaiting response” should distinguish waiting for your team from waiting for the customer if both situations matter to the process.

Record the next action alongside the owner. An owner without a next action can still leave a lead waiting indefinitely.

Make repeated events safe

Forms may be submitted twice. A delivery may be retried after a timeout. Design the receiving workflow to recognise an event it has already processed.

Keep a stable submission identifier with the lead. Before creating another record or sending another acknowledgement, check whether that identifier has already been handled. Decide separately how to treat a genuinely new enquiry from an existing contact.

For actions that cannot safely repeat, make the duplicate check part of the action itself rather than a separate, easily bypassed step.

Design the failure path

Write down what happens when a destination is unavailable. The visitor should receive an accurate result, and the team should have a way to recover submissions that were stored but not delivered onward.

A practical review checklist includes:

• Can the team find the original submission?
• Is a failed delivery distinguishable from a successful one?
• Can an authorised person retry without creating duplicates?
• Is someone responsible for unresolved failures?
• Does the visitor know whether the submission was accepted?

Avoid collecting more information than the team needs. Set access and retention rules for the stored records.

Review the whole journey

Test the ordinary path and the exceptions: a missing field, a repeated submission, an unavailable destination and an unassigned lead. Follow each one to its final state.

The automation is ready to evaluate when the team can explain where a lead is and recover when a step fails. The result is a process that can be operated, not just a form connected to an inbox.