The problem
Leads arrive through multiple forms and are manually copied into a spreadsheet, causing delays and duplicates. There is no visibility into which lead was assigned to whom, or whether a response was sent.
Assumptions
Forms are hosted on the website; a small team handles leads; duplicate detection is manual; the CRM has an API but it is not connected.
Guardrails
No lead is deleted automatically; duplicates are flagged for human review; personal data is stored only in approved systems; consent is captured at intake.
Evaluation criteria
Time from submission to first response; duplicate rate; number of leads with missing required fields; percentage of leads with a logged status.
What would change in production
Connection to the actual CRM; consent and retention rules; failure notifications to a monitored address; a recovery runbook for partial runs.
Walkthrough: from submission to accountable owner
Input: a form submits the fields needed for a first response, such as contact details, the requested service, a short description and consent where required. Server-side validation is authoritative; client-side checks are useful for guidance but can be bypassed. The system should reject or quarantine malformed submissions without losing a clear record of what happened.
Logic: normalise comparable fields, check for likely duplicates, verify required values and select a destination using explicit routing rules. A match should be treated as a review signal, not permission to merge or delete records automatically. If routing depends on service, geography, availability or budget, document the rule and define what happens when a value is missing or no route matches.
Action: create or update the record in the approved system, assign an owner, record the status and send a notification that contains only the information needed to respond. The notification should point to the protected record rather than distribute the entire enquiry across inboxes. Do not expose private enquiry details in public URLs or logs.
Control: keep a traceable event record for receipt, validation, duplicate review, assignment and notification result. A sent-email API response is not proof that a person has read the message, so the operating process should define an owner and a response-time expectation. If the team uses a CRM, the CRM record and its permissions should remain authoritative for the lead lifecycle.
Exceptions and safe recovery
Test duplicate submissions, invalid email addresses, missing consent, API timeouts, rate limits, notification failure and a CRM outage. Use a stable submission identifier or idempotency key where the receiving system supports it, so retrying a partial run does not create duplicates. If a destination is unavailable, keep the submission in a protected retry or review queue and alert a monitored owner; do not silently drop it or retry indefinitely.
Access should be limited to people who need the data. Define what is collected, where it is stored, when it is deleted, and which systems receive copies. Logging should favour event IDs and statuses over full message bodies. The recovery runbook should state how to locate the failed item, correct the cause, retry it safely, and record any manual intervention.
Acceptance checks
Before launch, exercise normal and edge-case submissions on staging. Confirm that the correct owner receives each valid lead, duplicates are flagged without destructive changes, consent is captured where applicable, and private records are not visible to unauthorised users. Verify the path for a failed notification and test that a successful retry does not duplicate assignment or record creation. Only then should routing rules be enabled for real enquiries.