Test a lead form and the callback it promises

Failure modes in this flow

The confirmation has to be specific enough that the prospect believes a person will actually call.

• Validation fires - a five digit number is refused with the expected length named.
• The reference exists - PB-310442, which the prospect can quote.
• The number is echoed - so a typo is catchable while they still care.
• The window and the advisor - a named time slot and a named person, which is what makes the promise concrete.

Echoing the number back is the assertion worth copying. A lead captured against a mistyped number is worse than no lead: the business pays for it, calls nobody, and the prospect waits.

Writing the objective

The error names the expected length rather than saying the number is invalid, which is the difference between a prospect correcting it and abandoning.

---
mode: testing
url: https://my-testing-repo-main.vercel.app/policybazaar-clone-app/callback?reset=true
max_steps: 40
tags: [policybazaar, insurance, lead]
---

# Policybaazar 27.2: Lead form to callback

Catalog objective: submit interest and verify the callback is scheduled.
Key assertion: a confirmation appears with an advisor callback promise.

## Verify a bad number is refused
Type "Priya Nair" into "Name", type "98765" into "Mobile number", click "Request a callback", and verify a red banner reads "Enter a 10 digit mobile number."

## Submit a valid lead
Replace the mobile number with "9876543210", select "Term life insurance" in "I am interested in", select "Tomorrow 10:00 - 11:00" in "Call me", and click "Request a callback".

## Verify the confirmation
Verify a green card titled "Callback scheduled" shows "Reference" of "PB-310442", "We will call" of "9876543210", "Window" of "Tomorrow 10:00 - 11:00" and "Advisor" of "Rhea Menon".

## Verify the request is recorded
Verify the "Your requests" card shows "Callbacks requested" of 1 with a "Callback scheduled" badge on the "PB-310442" row.

The final step asserts the request count as well as the row, which proves exactly one lead was created rather than a duplicate pair from a double submit.

The assertions in detail

A refusal, a submission, a confirmation and the record.

A confirmation that appears without the lead being recorded is the worst outcome here, which is why the count is asserted separately from the banner.

Running it locally

kane-cli testmd run tests/policybazaar/lead-callback_test.md

Add a double submit, since duplicate leads are paid for twice and annoy the prospect once.

Lead forms are worth watching continuously rather than at release time. Kane CLI in a pipeline covers scheduled checks, and exact string assertions covers pinning each validation message.