Academy › Build › Create your website
The button that doesn't just say 'Submit'
You'll know what text to put on the button based on what your form is asking for, and how to keep it from being clicked twice.
By Yodai · Published September 6, 2026 · Updated October 12, 2026
You get to the end of your form, all the fields filled in, and there's the button. And right there, without even thinking about it, almost everyone types "Submit."
That button is the last line the person reads before deciding. If it says "Submit," it says nothing: it doesn't confirm what's about to happen, it doesn't remind them what's being asked, and it works the same whether someone's booking a class, requesting a quote, or joining a waitlist. What the button says depends on what your form is asking for. And what happens the second after the click matters just as much as what's printed on it.
The button says what's about to happen, not what the person is doing
"Submit" describes the mechanics: a piece of data gets sent from one place to another. The person on the other side of the screen doesn't care about the mechanics, they care about the result.
That's why the button works better when it repeats the actual action behind the form, in its own words: book a slot, request a quote, sign up for an alert. That repetition does two jobs at once. First, it confirms: the person sees the same thing they just filled out spelled back to them, which tells them the form understood what they were asking for. Second, it nudges: a button that says "Book Thursday at 6:00 PM" gives a concrete reason to click now. "Submit" gives none.
The difference stands out more the bigger the commitment being asked for. On a plain contact form, it doesn't matter much: the person already knows they're writing something and waiting for a reply. But on a booking with a set time, or a quote that involves scheduling a visit, the button is the last moment for the person to confirm, with their own eyes, that they've understood what's about to happen.
The table shows a pattern: only the general contact form keeps a neutral verb, because it's the only case without a specific action to name. In the other three, naming the action isn't a stylistic whim, it's the difference between a button that confirms and one that says nothing.
- Doesn't say what happens after the click
- Doesn't remind you what's being asked
- Works the same for a booking as for a quote: it doesn't distinguish anything
- Repeats the action in a few words: "Book Thursday at 6:00 PM"
- Confirms that the info you just filled in will be used for that
- Changes with every form: it's not the same text on a booking as on a quote
- Gives a concrete reason to click now, not just to submit
Which one do I pick: Choose the specific wording whenever the form has one clear action behind it: booking, requesting a quote, joining a list. Save "Submit" for the generic contact form, where there's no single action to name and a longer phrase would feel forced.
What happens in the second after the click
The button's text is half the job. The other half is what happens the moment it's clicked. If the button stays exactly as it was while the form takes time to submit, something predictable happens: the person sees no change on the screen and clicks again.
If your form isn't protected against that, you end up with two bookings for the same slot or two identical quote requests, same name, same phone number, and you don't know which one to cancel. It happens most on a slow connection and on mobile: that's where the wait feels longest, and where a second tap out of pure doubt is easiest.
Duplicating a booking isn't just an awkward glitch. It means an extra phone call to figure out which of the two appointments is real, a slot on your calendar that looks double-booked when there's really only one person behind it, and a customer who starts wondering if your website works right. That one detail, a button that stays clickable, costs more time than it seems.
On a slow connection there's no visible change in the first few seconds, and anyone who doesn't see a response assumes the first click didn't work
- 1Turns off instantly
The moment it's tapped, the button can't be tapped again. That change stops duplicate submissions from a second tap before they start. - 2It changes its text while it's working
It goes from “Book Thursday at 6:00 PM” to something like “Booking…”. That's all it needs: just confirming the click registered and something's happening. - 3It doesn't suddenly go blank again
The form shouldn't reset to its original state, with the button available again, while the person still doesn't know whether their booking went through. - 4If the submission fails, it says so and releases the button
With no signal, or if the server drops for a moment, the button needs to reactivate and show a clear message: “Couldn't send, please try again.” Without that, the person is stuck with a button that's frozen forever, and closes the tab convinced they've lost their booking.
With this, your button says what's about to happen and can't be clicked twice. There's one last piece left, and it's the one that decides whether this whole chain is worth it: what the person sees right after their booking goes through, so they're not left wondering whether it worked.
- The button's text repeats the form's specific action: book, request a quote, sign up
- “Submit” is left only for generic contact forms, where there's no specific action to name
- The button disables on the first click so duplicate bookings don't come through
- While it's submitting, the button says so: “Booking…”, it doesn't stay the same or disappear
- If the submission fails, the button releases and explains what happened, it doesn't stay locked
Test yourself
Answer before opening each one. If one gives you trouble, go back to the section that explains it.
1. A form to join a workshop's waitlist has a button that says “Submit.” What gets decided, and why.
It changes to “Join the Waitlist.” There's just one specific action behind the form, and generic text doesn't add anything, while specific text confirms exactly what the person just asked for.
2. A customer with weak cell signal taps the booking button and sees no change for two seconds. What gets decided, and why.
The button should have already disabled on that first click and shown “Booking…”. If it doesn't, the customer taps again and two bookings come in for the same slot: the decision is to protect the click against a second tap, not to count on the person waiting without doing anything.
3. A website has a single contact form, with no booking or quote behind it, just for general inquiries. What text goes on the button, and why.
It stays “Send Message.” There's no specific action to name without forcing the phrase, and this is exactly the case where generic text doesn't hurt, since it's not competing with any more specific action.
Yodai builds the site from what you tell it, with a store, bookings or quote requests depending on what you do. See what the website for your business looks like.
NextThe screen that confirms, not the one that says goodbye