The person booking your appointment is probably holding a phone. They are possibly walking, possibly on a patchy connection, and using one thumb. That is the environment your booking page has to work in, and it is not the environment it was designed in.
Mobile problems are also quiet problems. Somebody who cannot get your date picker to open does not send you an email about it. They close the tab, and the only trace is a slightly lower booking rate that you will blame on something else.
This article is about the specific things that break on a small screen and how to fix them. It sits alongside booking page best practices, which covers what the page should say, and accessible booking forms, which covers the overlapping ground of targets, contrast and errors.
Design For The Phone First, Not As A Fallback
Building the desktop page and then squeezing it produces a page that technically fits and practically does not. The compromises land in the wrong place: the calendar shrinks, the service list becomes an endless scroll, and the payment step ends up below three screens of small print.
Starting from the phone forces useful decisions. If a service name has to be short enough to read on a narrow screen, it will be clearer on desktop too. If only four fields fit comfortably above the keyboard, you will think harder about which four you need.
What Breaks First On A Small Screen
In rough order of how often it causes an abandoned booking:
- The date picker. Either it is too small to tap accurately, or it opens a desktop-style overlay that runs off the edge of the screen, or it fights with the browser and shows two calendars at once.
- A long list of services. Twelve options on desktop is a glance. On a phone it is four screens of scrolling before the person has decided anything.
- Tap targets that are too small or too close. Time slots are the usual victim, and a mis-tap that books the wrong time is worse than one that does nothing.
- The wrong keyboard. A phone number field that opens the alphabetic keyboard makes people switch layouts and type digits one at a time.
- Sideways scrolling. Usually caused by one fixed-width element, a table or an embedded frame, and it makes the whole page feel broken.
- The keyboard covering the button. The submit control sits under the on-screen keyboard, and the page will not scroll far enough to reach it.
- Autofill fighting the form. Fields without proper autocomplete attributes get filled with the wrong values, or not at all.
Date Pickers Are The Usual Culprit
The safest approach on a phone is to lean on the platform. A native date input gives the user the picker they already know, it works with their accessibility settings, and it costs you nothing to maintain. Custom calendars are worth building only when you need to show availability inside the grid, which is a real requirement for booking pages.
If you do build or embed a custom picker, check the following on a real phone:
- The month grid fits the screen width without horizontal scrolling at the default text size.
- Each day is a comfortable tap target, with spacing between them.
- Previous and next month controls are far enough apart that a thumb cannot hit both.
- Unavailable dates are visibly and clearly different, and not only by a pale colour.
- Selecting a date does not require the page to jump somewhere the user cannot see.
- The picker still works with the phone's text size turned up, which many people use.
Consider showing only the next two or three weeks by default with a "show more dates" control. Most bookings land in that window anyway, and a shorter grid is far easier to use with a thumb.
Correct Input Types And The Keyboard That Appears
This is the cheapest mobile improvement available and it is routinely missed. The keyboard a phone shows is determined by the field's type and inputmode attributes, and getting them right saves the user several taps per field.
| Field | Markup | What The User Gets |
|---|---|---|
| Email address | type="email" with autocomplete="email" | Keyboard with the at sign and a full stop, plus autofill |
| Phone number | type="tel" with autocomplete="tel" | Numeric keypad including plus and hash |
| Numbers such as party size | inputmode="numeric" | Digits only, no layout switching |
| Postcode | autocomplete="postal-code" | Autofill from the saved address |
| Full name | autocomplete="name" | One tap to fill from the keychain |
| Card number | inputmode="numeric" plus the payment provider's own field | Numeric keypad and card autofill |
| Free text notes | textarea, not a single-line input | Room to type and to see what was typed |
Two more details that matter on phones. Do not disable pinch zoom, since plenty of people rely on it. And do not force capitalisation or autocorrect on fields holding email addresses or reference codes, because the phone will helpfully corrupt them.
Tap Targets, Thumbs And Reach
A thumb is far less precise than a mouse pointer, and the top corners of a large phone are hard to reach one-handed. Practical consequences: primary actions belong at the bottom of the screen rather than the top right, adjacent options need visible separation, and a control that both looks small and sits near another small control will be mis-tapped.
Time slot grids deserve particular attention. Four columns of thirty-minute slots on a narrow screen produces targets that are too small to hit reliably. Two columns, or a single scrolling column grouped into morning and afternoon, is slower to skim and much faster to use successfully.
Nothing Should Ever Scroll Sideways
Horizontal scrolling on a booking page reads as broken, and it usually is. The cause is almost always one element wider than the viewport: a table, a fixed-width embed, a long unbroken string such as an email address, or an image without a maximum width.
Where you genuinely need a wide element, let that element scroll inside its own container rather than making the whole page move. Then test at a narrow width, with the text size increased, because that combination is what exposes the problem.
Test On A Real Device, Not A Resized Window
Browser developer tools are useful for layout and misleading for everything else. They do not reproduce the on-screen keyboard covering half the viewport, the real behaviour of the native date picker, autofill from the phone's saved details, a slow mobile connection, or how the page looks in sunlight.
A realistic test pass:
- Book a real appointment on your own phone, from the same starting point a client would use, for example a link in an email.
- Do it one-handed, standing up. Note anything you have to reposition your grip to reach.
- Do it again with the phone's text size increased by two steps.
- Do it on a second phone with a different operating system, since date pickers and autofill differ.
- Do it on mobile data rather than office wifi, and note anything that stalls.
- Watch someone else do it without helping them. This finds more than the previous five combined.
Repeat after every design change. Mobile regressions arrive silently, and the first sign is usually a drop in completed bookings, which is the subject of reducing booking abandonment.
The Add To Calendar Step Matters More On A Phone
On a desktop, a confirmation email sits in an inbox the person will see again. On a phone, that email disappears under thirty others by the afternoon. The appointment only becomes real when it is in the phone's calendar, where it will produce its own alert.
So the confirmation screen and the confirmation email both need a prominent way to add the appointment to a calendar, offered right at the moment the booking completes and the person still has their phone in their hand. That means a calendar file attached to or linked from the email, plus direct links for the common calendar services, and an event containing the location, the video call link and your contact details rather than just a title and a time. The formats and the quirks are covered in ics files explained.
One extra mobile detail: put the address in the event as text a maps application can open, and put the video link where it is tappable. Somebody standing outside your building at nine in the morning should not have to search their email.
Keep The Whole Thing Short
Every principle above reduces to one instruction: fewer steps. On a phone, each additional screen is a decision point where a notification, a train stop or a change of mind ends the booking.
Aim for pick a service, pick a time, enter three or four details, confirm. If your flow has more steps than that, look at what each one is for. Account creation, upsells, marketing consent screens and lengthy terms acknowledgements are all steps that can move after the confirmation without losing anything you need.
Getting A Mobile-Ready Page Without Building One
Booking pages from appntmnts.io are built for the phone first: the picker and the slot grid are sized for thumbs, fields carry the right input types so the correct keyboard appears, and the confirmation includes a calendar file and add-to-calendar links so the appointment lands in the device calendar immediately.
If you want it inside your own site rather than on a separate link, the embedded booking page guide covers the options and how each behaves on a narrow screen, and the pricing page shows what is included on the free plan.