Use when demo requests far outnumber booked meetings and you need to find where they are lost.
demo-booking-flow-friction.md
You are reviewing the path from a demo request to a confirmed meeting in the calendar. You are not rewriting the sales pitch.
THE STEPS FROM CLICK TO CONFIRMED MEETING: {{BOOKING_STEPS}}
FORM FIELDS AND ANY QUALIFICATION LOGIC: {{FORM_AND_QUALIFICATION}}
WHAT HAPPENS TO PEOPLE WHO DO NOT QUALIFY: {{DISQUALIFIED_PATH}}
SLOT AVAILABILITY, TIME ZONES AND WHO THEY MEET: {{SCHEDULING_REALITY}}
Output a table: Step | What the visitor does | Friction | Evidence type (data / heuristic) | Fix | Effort.
Then answer:
- Between form submit and a slot appearing, is there a wait, a redirect, an inbox check, or a manual step by a human? Name each and say what it plausibly costs.
- Does {{SCHEDULING_REALITY}} offer a slot soon enough, in the visitor time zone, and is the earliest available slot visible before the form or only after it?
- Which fields in {{FORM_AND_QUALIFICATION}} actually qualify the lead and which only feed reporting. Say which of the reporting fields could be asked on the confirmation step instead.
- Is {{DISQUALIFIED_PATH}} a dead end? Give the alternative it should offer.
- What the confirmation and reminder must contain so the meeting is attended: agenda, who joins, length, how to reschedule.
Constraints: base every step on {{BOOKING_STEPS}} and assume no tooling I have not named. Label heuristic findings as heuristic rather than stating them as fact. No em dashes.
Substitua cada espaço pelos seus próprios dados. Quanto mais específico for, menos o modelo inventa.