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
- CTA and destinationScreenshot, replay
- FormFields shown, validation, form state
- Scheduler, if the Path has oneOpen slots, when it shows them
- SubmitOnly where you approve it
- Buyer inbox, 24hConfirmation, invite, ICS, follow-up
- Where our view stopsCRM, routing, ownerNot claimed
Applied on this run EU network · Mobile · Corporate email
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.
-
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.
-
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
- FormEnglish
- 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.
-
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.
-
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
- Submitobserved
- On-page confirmationobserved
- Acknowledgement emailnot observed
- Invite or ICSnot observed
- Sales follow-upnot observed
- 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.
-
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.
-
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
- Jun 9Last run that worked
- Up to 7 daysThe window your team has to explain
- Jun 16First affected run
- 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.
-
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.
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
| US · Desktop | EU · Desktop | EU · Mobile | |
|---|---|---|---|
| Network region | US | EU | EU |
| Device | Desktop | Desktop | Mobile |
| Buyer email | Corporate | Corporate | Corporate |
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.
-
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
-
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
-
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.
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
- 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.
- Live runThe buyer-side run itself
- Waiting windowWindow open means the report may still update when something reaches the buyer.
- 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.