Illustrative Scenario
Lead intake to CRM
Illustrative scenario · not a client engagement
Current situation
A B2B services company receives enquiries through a website form and a shared inbox. Two people check both surfaces during the day, and nobody owns the handover between them.
The flow we propose
A single, clearly defined flow captures both sources, validates and normalises the fields, checks the CRM for an existing record, applies written routing rules, and drafts an acknowledgement for a person to send.
Reference run outcomes
Missing required information
The enquiry is rejected before anything is written — no record is created from incomplete data.
Ambiguous company match
Two records look like the same company under different contact details. The case is flagged for a person, not merged automatically.
Clean enquiry
Validated, checked, and written to the CRM as a new record in one pass.
Raw run
From a real run
A live run of our reference build: a new enquiry comes in, duplicate and near-duplicate leads are caught automatically, an ambiguous case is queued for a person to resolve, and every step leaves a traceable record.
Captured from our synthetic reference build — not a client result.View full size →
How it works today
Someone reads the message, copies the details into the CRM by hand, guesses whether the company already exists as a record, then messages a colleague to decide who follows up.
Human control points
- A person sends the acknowledgement; the system only drafts it.
- Sensitive or high-value enquiries are escalated to a named owner before any reply leaves.
- Any suspected duplicate is flagged for review rather than merged automatically.
Failure and delay points
- Enquiries arriving outside working hours wait until someone opens the inbox.
- The same company is entered twice under slightly different names.
- Required fields are left empty because the enquiry did not contain them.
- Ownership is decided informally, so some leads have no owner at all.
What the pilot measures
- Time to first action against the agreed baseline
- Share of leads with a named owner
- Duplicate record rate on the test set
- Required-field completeness
Technical detail and assumptions
More evidence
Retry and recovery
A fourth real case in the same run (F07/F08) shows a CRM write that fails on a first attempt and succeeds on retry, still ending in exactly one record — never a duplicate.
Systems and data
The website form, one shared mailbox, and CRM systems through supported APIs and webhooks. Only the fields needed for routing and acknowledgement are read, and enrichment is limited to sources the client is permitted to use.
Baseline assumptions
- Assumed volume: about 60 enquiries a month across both channels. This is an assumption for scoping, not a measured figure.
- Assumed manual handling: roughly 6 minutes per enquiry today, based on a walkthrough rather than a time study.
- Assumed duplicate rate: around 1 in 10 records, taken as a planning assumption only.
Pilot scope
One lead source, one routing ruleset, one CRM object, and drafted acknowledgements only. No outbound campaign, no scoring model, no changes to existing CRM records outside the pilot ruleset.
Risks, exclusions and fallback
- If the CRM API is unavailable, the flow queues the record and alerts a person instead of dropping it.
- Ambiguous or malformed enquiries go to an exception queue for manual entry.
- This scenario is about handling and data quality. It makes no claim about sales results.
What moving to production would require
A named process owner, agreed routing rules in writing, CRM credentials with least-privilege scope, a retention decision for the queued payloads, and a rollback that disables the flow without losing enquiries.