7. The Booking Form Behind the Button

The offer page for Ledgerlane is written, fixed and checked on a phone. Its last section is a button that says "Book a diagnostic call", and right now that button goes nowhere. This chapter gives it somewhere to go. You will build the form a contractor fills in, the message they see straight after, and the first email they get. Then you will check all three on a small screen and for people who use a keyboard or a screen reader.

All of this is still the customer path, the part of the course where a promise on a page turns into what a customer actually experiences. One rule from the start of the course still holds. A claim only counts when you can name its source. The form, the confirmation and the email are full of small promises too, so every field label, every line of the confirmation and every sentence of the email has to come from a row in the facts register or from the brand guide. If no source exists, the space stays blank.

Building the booking form and its first messages

Start with the form itself, before any tool. A lead capture form is the box of questions that turns a visitor into a named contact. Here the visitor is called a lead. The question to ask about each field is simple: what decision does this answer feed? If nobody will ever use the answer, the field should not be on the form.

Every extra field costs you people. Each one is another thing to type on a phone keyboard, another reason to stop halfway, and another moment where someone thinks, why do they want that? A contractor who has just opened a penalty letter is reading on a phone, maybe in the van. Three or four quick fields feel like booking a call. Ten feel like filling in a tax return, and that is exactly the job they are trying to hand off.

So trace each field to a need in the brief.

Name comes first, because the founder has to know who they are calling.

Email is the next field, because the follow-up email has to reach someone. It is also where the record of the lead will be keyed later.

Phone number is there because this is a call. Without a number the call cannot happen.

Van count is the field that qualifies the lead. The offer has two prices, one van at a hundred and eighty pounds a month and two vans at two hundred and sixty. A choice of "one van" or "two vans" maps each lead straight onto a price row, so the founder knows which offer to talk about before dialling. A third choice, "three or more", is worth thinking about. The register has no row for it, so Ledgerlane has nothing to sell that person. Leave it off for now and let the qualifying note below handle it.

What made you get in touch is the next field. The brief's trigger is a penalty letter or a big year-end bill, so offer those two choices plus "something else". This tells the founder what the call is really about. It also shows whether the page is reaching the people it was written for.

The last field is an optional box for anything else, in the person's own words. It is optional because some people will have nothing to add, and a required empty box is a reason to leave.

Look at what is missing. There is no question about yearly income, even though Making Tax Digital thresholds depend on it. Asking for income on a first form feels intrusive, and the call can cover it. There is no business name, no postcode and no "how did you hear about us". The postcode would be useful for nothing Ledgerlane does. "How did you hear about us" belongs to measurement, which gets proper tracking rather than a guess typed by the lead.

Above the fields goes a short qualifying note, so that someone the offer cannot help finds out before they submit. Here is a version built only from register rows. Ledgerlane handles monthly bookkeeping for one- and two-van contractors: receipt capture, monthly bank reconciliation, quarterly VAT prep and tax-ready year-end accounts. It does not do payroll, invoice chasing or incorporation advice, and penalty appeals are not among its inclusions. A contractor who needs only a penalty appeal should not book a call. That person is better off finding out now than on the phone, and the founder is better off not spending a slot on a call that cannot become a sale.

Now pick the tool to build the form in. There are two broad kinds. A scheduler such as Calendly lets someone pick a time slot and answer a few questions in one go. A form builder such as Tally, Typeform, Google Forms or HubSpot's free forms collects answers first and then sends the person on, perhaps to a booking link.

Calendly looks like the obvious choice for something called "book a call", and it does take the back-and-forth out of finding a time. On its free plan, though, its intake questions are fixed. The logic that would treat a lead differently depending on an answer needs a paid plan. Sending someone on to another web address after booking needs a paid plan too.

Tally is the better fit here. On its free plan you get unlimited forms and submissions under fair-use limits, with branching logic, which means the form can show or skip a question depending on an earlier answer. It can also send a person to a different page depending on what they chose. It sends you an email when a new submission arrives, and it stores answers in its own dashboard, which you can export to a spreadsheet such as Google Sheets. Tally is hosted in the European Union, in Belgium, which keeps things simpler for a business in the United Kingdom handling personal details. Typeform's free plan stops taking answers after ten submissions a month, which rules it out for a form meant to run all year. Google Forms is free but cannot send a person to another page based on their answer, and its logic only works section by section.

Choose Tally and build the six fields in the order above, with the qualifying note at the top. Then go back to the offer page and point the "Book a diagnostic call" button at the form's share link. The button now leads somewhere.

Make one test entry yourself and see what the tool produces. Two things appear. The first is a stored submission record in the Tally dashboard: one row with the name, email, phone, van count, trigger and free text, and the time it arrived. The second is a notification email sent to the account owner saying a new response has come in, with the answers inside. That email is how the founder learns a lead exists. Right now the record lives only in Tally. Where it should live later is the CRM's job, and that comes in a later part of the course.

Calendly can still play a part. Tally can send the person on to a free Calendly booking page after they submit, so someone who qualifies picks a time straight away. That only works if the founder has decided how long a call lasts, and the founder has not decided yet. More on that shortly.

The words on the form come next, and here the assistant helps. Open a new chat in the Claude Project called "Ledgerlane Marketing". The project already holds the facts register, the brand guide, the evidence file, the offer page and the situation adaptation instruction, and its standing instructions already tell Claude to take facts only from those files, flag missing facts and list the rows used with their checked dates. Your request can be short because the project carries the rules. Something like this: "Draft the field labels, help text and error messages for the Ledgerlane diagnostic call form, with these six fields. Then draft the confirmation message shown after submitting and the first follow-up email. Tag every sentence to a register row, a brand guide rule or 'no source'. List the rows used with their checked dates, and list any owner questions you hit."

What comes back is mostly plain. Labels such as "Your name", "Email", "Phone number" and "How many vans do you run?" need no source beyond the form itself. Help text under the phone field might read "We'll use this to call you about your books." Error messages should say what went wrong and how to fix it, such as "Enter an email address, like name at example dot com", rather than a bare "Invalid input". The brand guide's rule about short sentences with a next step applies here as much as in an email.

Next, inspect the drafts. The danger sits in the confirmation and the email, because those are where helpful-sounding promises creep in. Two facts are still open owner questions with no register rows: how long the diagnostic call lasts, and how quickly Ledgerlane replies after a booking. Nothing written to a lead can state either one.

Here is an illustrative case of the fault to look for. A first draft of the confirmation might read: "Thanks, we've got your details. We'll call you within 24 hours for a quick 15-minute chat." Both numbers sound reasonable, and both are invented. Claude, if the project instructions are working, will tag that sentence "no source". But read the tags every time rather than trusting them. A sentence like "We'll be in touch soon" can slip past a tagging pass while still implying a speed nobody has promised.

The fix is not to guess a softer number. Replace the sentence with a marked placeholder routed to the founder: "We'll call you on the number you gave. [OWNER: reply time after booking, no row yet.]" Add it to the owner questions list next to call length. The placeholder must be filled or removed before the form goes live. Until then the confirmation says only what is true. It thanks the person, says what they told you, says a call will follow, and restates in one line what Ledgerlane covers and does not.

The first follow-up email has a slightly bigger job. It goes to someone who has just shown interest, so it should help them decide before the call. It restates the price for the van count they chose. It names the four inclusions and the three exclusions: payroll, invoice chasing and incorporation advice. It also says plainly that penalty appeals are not part of the service, because no inclusion row covers them. It gives the setup time as about two weeks from signing, because the onboarding row says exactly that. Then it asks only for facts they have not already given. They already gave their name, phone, van count and trigger, so do not ask again. A useful question is whether they are VAT-registered, since quarterly VAT prep is one of the inclusions and the answer changes the call. The open VAT row about Ledgerlane's own fees stays out of the email entirely.

Check the email against the brand guide's accepted examples. It should have no compliments, no "don't worry", short sentences, and a clear next step. A line such as "We know a penalty letter is stressful" fails the rule against reassurance in place of information. Something that states what happens next passes.

Save everything in the project before moving on: the request, the revised labels, help text and errors, the confirmation, the email with its sentence tags and row list, and a fault note. The fault note records the invented reply time and call length, why they were removed, and that the placeholder is waiting on the founder.

With the words settled, look at the form the way real people will meet it. Some will be on a small phone, some will use a keyboard rather than a mouse or finger, and some will listen to the page through a screen reader. The standard most checks point to is the Web Content Accessibility Guidelines, version two point two, usually shortened to WCAG.

Start with labels. Every field needs a visible label sitting outside the box, not just grey placeholder text inside it. Placeholder text vanishes the moment someone starts typing, so they lose track of what the field was asking. It is also often too faint to read. The label must also be tied to its field in the page's code, so a screen reader says "Phone number" when the field gets focus. The two van choices should be grouped under one question, so a screen reader announces "How many vans do you run?" before the options.

Then errors. Leave the email blank and press submit. The message should appear as words next to the field, not just a red border, because someone who cannot tell red from other colours would see no difference. The error should be linked to its field so a screen reader reads it out, and focus should move to the first problem or to a summary of problems at the top.

Next is keyboard order. Click into the page and press Tab over and over. Focus should move name, email, phone, vans, trigger, free text, submit, in the same order as the screen. Each step should show a visible outline. Watch for the offer page's sticky button. If it floats over a field so that the field is completely hidden while it has focus, the person cannot see where they are, and WCAG two point two counts that as a failure.

Contrast comes after that. Label text, help text and error text need a contrast ratio of at least four and a half to one against the background. Field borders and the focus outline need at least three to one, so people can see where the boxes are.

Then input types, which matter most on a phone. The email field should be set as an email type, so the phone shows a keyboard with the at sign close at hand. The phone field should be set as a telephone type, so a number pad appears instead of letters. Each should also carry an autocomplete hint for name, email or telephone, so the phone can fill them in from saved details. In Tally, choosing its email field and phone field blocks rather than plain text blocks gives you this. Check it rather than assume it.

The last check is tap size. Open Chrome DevTools, switch on the device toolbar, and set the width between three hundred and twenty and three hundred and ninety pixels, the same range you used for the offer page. Every field, option and button must be at least twenty-four by twenty-four pixels, the WCAG two point two minimum. Apple's and Google's own design guidance aims for about forty-four to forty-eight, which suits thick thumbs in work gloves far better. Look at the van choices especially. Small round option buttons squeezed close together are a classic mis-tap.

Then add one quick automated check. Lighthouse is built into Chrome DevTools: open its panel, tick accessibility and run it on the page with the form. You could also use the free axe DevTools extension from Deque, or WAVE from WebAIM. These tools catch missing labels, broken code attributes and many contrast failures in seconds.

Be clear about what that check cannot tell you. Automated tools cover somewhere between about a third and a bit over half of the problems that matter. They can confirm a label exists but not whether it makes sense; a field labelled "Field 3" passes. They cannot submit the form, so they never see whether errors are announced or whether focus moves to them. They cannot judge whether the tab order follows the task, or whether a sticky button covers a focused field. They also cannot show you the real keyboard on a real phone. A clean Lighthouse score means only that the easy mistakes are gone. The manual checks above are the actual inspection.

When the checks pass, or you have fixed what failed, save a second fault note in the project. Record each check, what it found, what you changed, and the Lighthouse result with the reminder of what it does not cover. The form, its words and its checks now sit beside the offer page in the same workspace, and the open owner questions list has grown by one placeholder waiting to be filled.

Native forms versus a separate form builder

Tally works for this form, but it is worth knowing the other road. HubSpot, Klaviyo and Mailchimp all offer forms built into the platform where your contacts live. The real difference is where the lead lands.

With a native form in HubSpot, a submission becomes a contact record in the CRM straight away. HubSpot checks the email against contacts it already has, so the same contractor filling in the form twice updates one record rather than creating two. It also ties the submission to that contact's history, and the founder can be notified inside the same system they would use to follow up. HubSpot has been adding to this in twenty twenty-six. In July, salespeople gained the ability to book meetings for contacts without leaving the CRM. In September came account-wide spam controls for native forms, which matters once a public form starts attracting junk. Klaviyo launched hosted landing pages with multi-step forms in February. Mailchimp updated its form builder to pull in brand assets.

With a separate builder like Tally, the record lands in Tally's dashboard and the notification goes to your inbox. Nothing is in a CRM yet. When you add one later, you have to connect the two. Unless that connection checks for an existing email first, the same person can turn up as two contacts. Consent checkboxes in a separate builder also arrive as plain answers rather than as a properly stored permission record, so they need care when you connect them.

That is the trade for this form. Tally gives free branching, European hosting and a quick build today. A native form gives a cleaner record later. For a business with no CRM yet, the smallest useful step is to write down, in the fault note, that the Tally record will need a connection with duplicate checking when a CRM arrives. Then you will not be surprised by it later.