Methodology

What we check on your demo flow, and where the proof stops.

We propose the Paths and a few buyer contexts, and you confirm them. We run each as an outside buyer on a schedule, including what happens after submit. Each finding links to the replay, screenshot, or email behind it and says where our view stopped.

A Path is one public route to a demo, contact-sales, quote, or trial request.

Demo request /demo

One run · EU · Mobile · example

  1. CTA and destinationScreenshot, replay
  2. FormFields shown, validation, form state
  3. Scheduler, if the Path has oneOpen slots, when it shows them
  4. SubmitOnly where you approve it
  5. Buyer inbox, 24hConfirmation, invite, ICS, follow-up
  6. Where our view stopsCRM, routing, ownerNot claimed

Applied on this run EU network · Mobile · Corporate email

Everything above the line is what an outside buyer could see. Below it, nothing is claimed.

What BookedDemo verifies

Seven things we check on every Path.

A passing test can miss a slow form, an extra step, or silence after submit. Each check below shows what the buyer actually got.

  1. 1 Reach
  2. 2 Qualify
  3. 3 Handoff
  4. 4 Follow-through
  5. 5 Context
  6. 6 Change
  7. 7 Limits
  1. Does the CTA land on a form or booking page at all?

    • What the CTA opens, and whether it does anything at all
    • A form or booking page appears
    • How long until the buyer can use it
    • Whether a vendor booking page is live or says it is unavailable

    Observed in our research

    42 sites

    where a sales button led to a dead end we confirmed: a missing page, a dead booking link, or a button that did nothing.

    We report what the buyer saw, and nothing about leads, routing, or revenue behind it.

    Why it matters

    The CTA points at the wrong page, the page is gone, the vendor's booking page was never published, or the button does nothing. A buyer who never reached the form never submitted anything, so there is usually nothing for your team to notice.

    See the dead ends we confirmed

  2. Can a normal buyer get through the form?

    • Which fields the buyer is shown
    • Validation and work-email rules
    • A required marketing opt-in, or consent text in another language
    • A signup or login wall where the sales form should be

    Example finding

    1. FormEnglish
    2. Required consent boxRussian

    The form works, but the box the buyer must tick is in another language. We report that as Degraded, not Works.

    We do not score the form or guess at conversion from how long it is.

    Why it matters

    A form can look fine from inside the company while a qualified buyer is stopped by a validation rule or a box they cannot read. We report what got in the way and leave the form design to you.

  3. Does it still work across popups, frames, and vendor pages?

    • Popups, new windows, and cross-origin frames
    • Vendor forms and hosted schedulers
    • A banner or popup covering the CTA
    • An extra step before the form
    • Booking fields or buttons the buyer cannot reach inside a vendor frame
    • Whether the page we land on is still the flow we started

    A common shape

    190 of 832 observed destinations sat on a host outside the company's own domain.

    Using a vendor is not a defect. We note it because that page can change without anyone on your side touching it.

    Why it matters

    A single request often crosses a page, a modal, a popup, a frame, and a vendor. Each of those handoffs can change without the others changing.

    Vendor pages in our research

  4. What happened after the buyer submitted?

    • What reached the buyer, even with no expectation set
    • Which channels we watch: the browser and the buyer inbox
    • How long we wait, the proof window

    One run, 24h window

    1. Submitobserved
    2. On-page confirmationobserved
    3. Acknowledgement emailnot observed
    4. Invite or ICSnot observed
    5. Sales follow-upnot observed
    6. Window closedreport settles

    All we can say is that nothing reached the buyer in the channels we watched before the window closed. Not what your CRM did, who was assigned, or whether a mail was sent and dropped.

    Why it matters

    HBR found that the longer a web lead waits for a reply, the lower the odds it is ever qualified. Silence after a demo request is the part most in-house checks do not reach, because the form itself submitted fine.

    Our Study never submitted a form, so it cannot say how often a reply arrives. We only measure that on your own Paths, once you approve submits.

    HBR, The Short Life of Online Sales Leads

  5. Does it break for one kind of buyer and not others?

    • Each confirmed buyer context, run separately
    • Whether the run used that region or device, or only had it set in the config
    • Meeting times inside the buyer's working day, in their own timezone

    Applied on this run

    A finding can say “EU mobile enterprise went silent” instead of “the funnel dipped”.

    A difference on its own is a reason to look, not proof of which context is wrong. A run that could not use its region or device says so instead of counting as checked.

    Why it matters

    The same Path can behave differently by region, role-based form, device, timezone, or email profile. A drop inside one of them barely moves the weekly total. Our Study ran one context per Path, so it cannot say how often this happens.

    See the approved contexts

  6. What changed since the last run that worked?

    One audit tells you how it looked that day. To know when it changed, you need the run before and the run after.

    • What is different from the last run that worked
    • How long the difference has likely been there
    • A rerun after the change or fix

    Reconstructing an incident

    1. Jun 9Last run that worked
    2. Up to 7 daysThe window your team has to explain
    3. Jun 16First affected run
    4. RerunWhether the change held

    The window is bounded by the last run that worked and the first that did not. It does not tell you how many buyers were affected.

    Why it matters

    Forms, schedulers, vendors, routing, and campaigns keep changing under a Path. One booking calendar we checked every week showed open days on September 16 and an invalid link on September 23. Without the run before, nobody could say when it broke.

    Routes that broke between our checks

  7. Where does our view stop?

    • CAPTCHA and bot challenges
    • Private channels such as phone or SMS
    • Vendor pages we cannot look inside
    • Anything past the point you approved, such as submitting or booking

    How a boundary is reported

    The run stops and says so. It never becomes a Works or a Broken verdict.

    A challenge shown to BookedDemo is not proof that every human buyer sees the same thing.

    Why it matters

    We would rather tell you where we got stuck than guess past it. A report that pretends to know what happened behind a CAPTCHA is worth less than one that says it could not see.

    Searles et al., Modern CAPTCHAs, USENIX Security 2023

What this looks like on real sites: dead ends, a long wait, and routes that broke between checks, from nearly 2,300 company websites.

How we pick buyer contexts.

We propose a few buyer situations that can behave differently. You confirm the ones that matter. Each report records the context the run used, next to the evidence.

  • Region or network
  • Language and timezone
  • Mobile or desktop
  • Buyer role
  • Email profile
  • Company size and industry

Demo request /demo · three approved contexts

Example

Three approved buyer contexts for one Path, example
US · DesktopEU · DesktopEU · Mobile
Network regionUSEUEU
DeviceDesktopDesktopMobile
Buyer emailCorporateCorporateCorporate
The set stays small on purpose. We do not run every combination.

Nothing is submitted until you turn it on.

By default we look and do not submit. You turn on each deeper layer yourself. We never book a real meeting on anyone's calendar unless you approve booking and point us at a test calendar.

  1. Baseline

    What we check without submitting

    • CTA handoff
    • Form access and validation
    • Whether the booking page opens
    • Open slots, when the scheduler shows them
    • Replay and screenshots
    • Safe proof by default
  2. After submit

    After-submit proof

    • Confirmation
    • Invite
    • ICS
    • Sales or nurture follow-up
    • No response after waiting window
    • The report stops updating when the window ends
  3. Customer-enabled

    What you can switch on

    Booking a slot, running from a specific region or network, and routing test submissions somewhere safe. Phone, SMS, and WhatsApp are scoped separately, and so is confirming that an agreed test record arrived on your side. Every report says which mode it ran in.

Each finding points to a file you can open.

These are what a run leaves behind.

A bounded bit of AI helps read messy pages. It never decides what counts as proof.

View sample report

  • E01Replay
  • E02Screenshots
  • E03Form state
  • E04Scheduler / slot state
  • E05Email / invite / ICS evidence
  • E06Closed waiting window

Each report says what was and was not checked.

The buyer context, what was reached, what was checked after submit, and what is still open.

This says nothing about your CRM, who the lead was routed to, or where it came from. On Custom Coverage we can agree one test record to look for in your system, scoped separately.

What this run covered

One run · example

Regional network
EU configured
Device
Mobile
Buyer profile
Enterprise
Email identity
Corporate
Submit
Reached
Follow-up window
24h
Invite / ICS
Covered
Additional channels
Not covered unless you turn it on

The report can keep changing after the run.

The report updates when something reaches the buyer, then settles when the waiting window closes.

  1. Live runThe buyer-side run itself
  2. Waiting windowWindow open means the report may still update when something reaches the buyer.
  3. SettledThe window closed; the report stops updating

A report shows one of six follow-through states.

The first run tells us what happened. It does not define what should happen. If you tell us to expect a reply and it never arrives, the Path shows Inconclusive with that finding. If you have not, we report what arrived and what changed since earlier runs.

  • Buyer-visible response observed

    Confirmation, invite, or sales follow-up reached the buyer inbox.

  • Follow-through window open

    Still watching. The report may still update.

  • Nurture only

    Marketing nurture arrived. No sales or scheduling response.

  • No buyer-visible response observed

    The buyer inbox stayed empty in covered channels.

  • Response channel not covered

    The response would arrive on a channel outside this run.

  • Historical · not evaluated

    Window closed. Late signals appear as history.

Emails that do arrive can be checked for broken merge tokens, empty greetings, or missing links. We do not look inside your campaign setup or CRM routing.

What the report gives your team.

One report per run, with the next check named, that you can forward as is.

Prefer to talk first? Discuss your Paths. The fit and scoping conversation is free.

Buyer context
The region, device, buyer profile, and email identity the run used.
How far it got
Where the buyer reached, and what got in the way.
After-submit response
Confirmation, invite, follow-up, or silence once the window closed.
History and affected window
When it last worked, the first run that differed, and the window in between.
Evidence and rerun
Replay, screenshots, submit state, what reached the inbox, and the rerun that shows whether the change held.