Your AI-built booking form looks finished. Can a customer fix a typo?
Imagine filling out a repair booking on your phone, tapping Submit and seeing ‘Something went wrong.’ Is the email address wrong, is the appointment gone, or did the booking actually arrive? I'd try that moment before sharing a form made with an AI website builder. Leave the @ out of a test email address and see whether you can finish without someone explaining the screen. W3C's existing forms tutorial recommends that an error list name the affected field, explain how to correct it and link to that field. It also describes feedback beside the input. ‘Email address: include an @’ gives someone a next move; ‘Invalid input’ leaves them searching. I'd also check that correcting the email doesn't erase the repair description they've already typed. That's my suggested test, not a failure I've observed in a particular builder. A tidy preview only shows the form before anyone makes a mistake. Can someone recover on a small screen and still tell whether their booking was sent?
Comments
I'd try submitting twice, too. A customer on a slow connection may tap again because nothing seems to have happened. Before launch, have the receptionist look at what arrives: can they tell whether it's one repair request sent twice or two separate jobs? Give the customer a reference they can quote if they call, and keep it with the request the receptionist sees. That's a test I'd add, not a fault I've observed in a builder. Otherwise uncertainty on a small screen becomes two callbacks and two provisional slots for the same repair.
Let me request the repair without joining the mailing list. If an AI builder adds a marketing checkbox, try submitting with it unticked: the request should still go through, and the confirmation should concern the repair. I'd make that a launch check, not assume a polished form kept the two choices separate. Count a customer who declines offers and successfully asks for help as a success, too. Otherwise ‘improving the form’ can quietly mean getting more email addresses rather than making the booking easier.
I'd check the successful submission, too: did the customer book an appointment, or just ask for one? For a repair shop that still needs to check parts and availability, I'd have the form say ‘Request received—we'll contact you to agree a time,’ rather than ‘You're booked.’ Try it with an address you control and read the confirmation email as well as the screen. They should make the same promise. That's a check I'd add before launch; otherwise a working form could leave someone turning up with a broken chair when nobody expects them.
I'd try booking for someone else, too. If I'm arranging a repair for my dad, the name on the job may be his while the callback number is mine. Label those separately, and ask who should receive the confirmation. Don't make someone put their own name in the customer field just to get updates they need to help. That's a case I'd include when reviewing an AI-built form, not a fault I've seen in a particular tool. A family member helping with one repair shouldn't have to untangle whose phone will ring after pressing Submit.