Wedding photographer booking form: why it stalls

Once an inquiry is answered, the next message says 'Sign your booking to hold the date.' The link leads to a signing service that sends a one-time code to a phone number. Some couples do not want to share a number with a vendor yet. Others use a number that will not take texts from unknown senders. Either way the step waits for a code that never arrives, and the couple cannot tell whether the date is held. The owner has the code on their own phone, so the wait never shows up from inside.

• After the inquiry, is there one next step that says in plain words whether the date is held?
• Does any step ask for a phone number and a one-time code? Write down the screen where it appears.
• Does the deposit step say when the date is held, and what happens if the couple stops before paying?
• Open the booking link on a phone in a private window. Does the contract load, and can you scroll to the signature?

After an inquiry, a couple's booking often runs through a questionnaire, a contract, a deposit and a signature. Each one can come from a different tool or page, so each asks for something different: a name and a wedding date first, then a venue address, then a card, then a code. The couple sees one booking. In practice it is several separate asks, and a failure at any of them sends the couple back to the start of that step, with the answers they already typed possibly gone.

Find the failing step by walking the same route from the inquiry email, on a phone, without the login you already have. Write down the first screen that asks for something a couple may not have ready, such as a card, a code or a second account. That screen is the cause. A simulated visitor follows the same steps, fills the questionnaire, reads the contract and reaches the deposit, then shows where it stopped.

A booking form often has its own date field, separate from the calendar the photographer uses. If the couple picks a date the calendar shows as free, and the form rejects it with a generic 'not available' message, the couple assumes the photographer is booked. The calendar may show a different free date, or the form may refuse a Saturday the calendar allows. The couple cannot tell which source is right, so they send another inquiry, or they stop.

Test with a date the calendar shows as free, and read the form's reply if it refuses. Then try a date the calendar shows as taken, and see whether the form agrees. A mismatch in either direction is the cause, and the fix is one source of dates. The run shows the date the simulated visitor typed, the message the form gave, and the step where it stopped.

A simulated visitor has a working email inbox, so it can follow a link that arrives by email and read the contract that comes with a booking. It cannot receive a text message, so a signing step that sends a one-time code to a phone stops there. The run shows the screen where it stopped. That is a real limit of the test, and it is the reason to check the code step by hand.

Give the code step its own check. Use a phone number you control, confirm the code arrives, then enter a wrong code and see whether the page clears the couple's answers. A wrong code that wipes the booking is a different fault from a code that never arrives. Run the emailed-link path separately, since that is the route a simulated visitor can finish.

A new season, a calendar sync or a change to the signing tool can make the form disagree with the calendar again, and the booking still looks complete on your side. Rerun the path from inquiry to deposit after each change, with a date the calendar shows free and one it shows taken. Check the signing step on a phone with a number you control, because a code problem shows up only there.