Skip to content
← All scenarios

Illustrative Scenario

Turning a website submission into an owned CRM record

Illustrative scenario · not a client engagement

Current situation

A visitor completes a high-intent form on the website. The open question is whether that submission reliably becomes an owned record somewhere, not just an email in an inbox.

The flow we propose

The same accessible, validated journey the site already has is extended so a successful submission also creates or matches a CRM record with an owner, using the same adapter the lead-crm scenario defines. A calendar click and a CRM-confirmed lead are always counted and reported separately.

From a real run

The same reference build shown for lead intake — this solution pairs that flow with the website form that feeds it.

Terminal output of a real reference-build run: leads processed, duplicates caught, one case queued for review

Captured from our synthetic reference build — not a client result.View full size →

How it works today

The submission is validated and an email is sent to the team today. There is no CRM record behind it, so nothing confirms the enquiry was captured, routed, or given an owner beyond the inbox itself.

Human control points

  • There is no mid-flow approval step here; the discipline is measurement honesty rather than a human gate.
  • A booking is never counted until it is confirmed on the calendar or CRM side, never from a link click alone.

Failure and delay points

  • A calendar link click and a confirmed meeting are two different things, and today they are hard to tell apart from the outside.
  • Without a CRM record, success is read from proxy signals rather than an actual owned lead.
  • A double submission is not clearly distinguished from a genuinely new request.

What the pilot measures

  • Form completion rate on consented traffic
  • CRM routing success rate for a completed submission
  • Double-submission rejection rate
  • Mobile and desktop field Web Vitals on the journey
Technical detail and assumptions

More evidence

An ambiguous case queued for a person, then resolved with a noteEvidence table: expected vs. actual outcome per case

Systems and data

The website own form and journey, plus the same CRM adapter the lead-crm scenario uses. No new personal-data field is collected beyond what the form already asks for.

Baseline assumptions

  • No numeric fixture count is given for this scenario; the Astra plan treats it as a content-and-behaviour fixture (form-validation cases, consent states, a viewport set) rather than a labelled dataset, and this content does not invent a count.

Pilot scope

One existing journey on the site, joined to the same stub CRM adapter the lead-crm scenario uses. No new marketing claim is made until the join between the two is actually working.

Risks, exclusions and fallback

  • If the CRM adapter is unavailable, the existing email path continues to work unchanged; the CRM join is additive and never blocks a visitor from submitting.
  • This scenario is about capture and routing honesty. It makes no claim about how many of those leads will convert.

What moving to production would require

The same requirement as the lead-crm scenario: a real CRM adapter, since none exists yet. Until that exists, this remains illustrative like the rest of these scenarios.