Before you add the calendar
Add booking to
your website.
Agree what
gets confirmed.
A booking button can open a service you already use, show its calendar inside your website, or start a much larger software project. First decide what the customer should be able to arrange and which system will manage it.
If someone needs your advice before choosing a service, a request or consultation may be the right starting point. A date field on its own does not reserve your time.
Download the booking handover sheetA free text file to edit and share with any website provider. No sign-up.
Two different commitments
What happens after
someone chooses a time?
Write the route from the customer’s point of view, including the step after they press the button. That helps you choose the right words and agree what needs to work behind the page.
Your team needs
to confirm it.
Useful when the work, suitability or timing needs a conversation first.
- 1
The customer explains what they need.
They can suggest a date, with a clear explanation that it is a preference.
- 2
The request reaches your team.
The message says the request was received and explains how the team will reply.
- 3
You check and agree the arrangement.
A person confirms the service and time through your agreed process.
At the end of the form: a request has been sent. The appointment still needs agreement.
The system can
reserve the place.
Useful when the service and available time can be chosen without that conversation.
- 1
The provider shows available choices.
The customer chooses the service and time, with any supported staff, location or resource choices.
- 2
The customer completes the required steps.
The provider handles the details and any agreed payment or approval requirements.
- 3
The provider confirms the reservation.
The customer receives the confirmation and can find the agreed way to change or cancel it.
At the end of the completed process: the provider confirms what has been booked. Check its actual rules.
Some providers accept requests for later approval. Check the real process before choosing “Book now”, “Request a time” or “Ask about an appointment”. Match the button and confirmation to what the customer actually receives.
Choose the connection
You may already have
the system you need.
If you have a working booking provider, start with its supported options. Moving the business website does not automatically mean replacing the diary, room inventory or reservation service.
- LinkA booking page
with your provider. A website button takes the customer to the provider’s booking page. Check the correct business and destination, and whether you can link directly to a service, person or location.
Agree: where the link goes, which choices remain, and what the provider confirms.
- EmbedThe provider’s tool
inside your page. A supported calendar or widget appears within the website or opens over it. The provider still controls its booking functions. Check account requirements, mobile and keyboard use, loading behaviour and any provider charges before agreeing the work.
Agree: the supported method, who maintains it and the contact route if it cannot load.
- Separate scopeA new system
or connected workflow. If the new website must manage scheduling, capacity, staff calendars, room inventory or payments, or connect separate systems, describe those requirements before ordering. They need a separate feasibility assessment and agreed scope.
Agree: which system owns each part of the booking and who will operate it after launch.
For examples of supported approaches, Google Calendar documents booking links, popup buttons and inline booking pages; Calendly explains its inline and popup embed options. Check your own provider’s current documentation and account features. These examples do not establish what your account or website package includes.
Work through the choices
A haircut and a consultation
can start differently.
For example, a salon could let a returning client choose a familiar service through its booking provider, while asking someone planning a significant colour change to arrange a consultation first.
Follow the service,
person and place.
The website explains what the service includes and who offers it. The booking link should carry the client to the relevant choice where the provider supports it. If they must choose again, make the next screen understandable.
For the consultation, explain how it is arranged and what happens afterwards. The salon supplies any preparation requirements and approves the wording.
See how we plan a hair salon website- Service
- Can this appointment be chosen now, or does the team need to advise first?
- Stylist
- Which people offer the service, and who keeps that information current?
- Location
- Does the next screen show the right salon and address?
- Confirmation
- Does the client have an appointment, a consultation booking or a request awaiting a reply?
The same questions apply differently elsewhere. A garage may book an inspection without promising a repair time. For a guest house linking to a reservation provider, check which system controls room availability. A restaurant may handle group requests separately from table bookings.
The handover
Put the working arrangements
beside the booking link.
The designer needs more than a calendar address. Agree these points with the person who runs bookings, then use the download to record the answers. Leave unknown details marked “To confirm”.
The customer’s promise
What can they arrange, what remains subject to approval, and when is a place reserved? Include the words the button and final message should use.
Availability and the destination
Record the provider and public booking link, then the services, staff, locations or resources it needs to handle. Identify which system controls availability and who updates it.
Payments and changes
Who takes any deposit or payment, who handles a refund question, and where can the customer change or cancel? Use approved policies and keep the website consistent with the provider.
People and ongoing updates
Who checks requests, who covers an absence and who changes the website when services or booking rules change? Agree any response commitment before publishing it.
Before launch
Follow one booking
all the way through.
Agree a test with the people receiving the booking and use the provider’s supported test method. Check the actual record and confirmation, as well as the screens. If testing could take payment or reserve real capacity, agree how that will be handled first.
The right place
Does each link open the correct service, team member and location, where the provider supports those choices?
A time that can be booked
Do closed days, unavailable times and required people or resources behave as agreed? Check the displayed time zone where it matters.
An accurate confirmation
Does the customer see whether they have sent a request or completed a booking? Can the responsible team find the corresponding record?
A change of plan
Can the customer find the agreed cancellation, rescheduling and payment information? Check what happens to the original booking when a change is made.
A phone and a keyboard
Can someone read the choices, operate the controls and reach the confirmation on a phone and using a keyboard? Keep a useful contact route available if booking fails.
Keep the date, page address, result and unresolved issue in the handover sheet. A working button is the beginning of this check. The website launch checklist covers the wider site.
When you are ready to talk
Bring the website
and booking plan together.
UpOnUp’s standard website project covers agreed pages and an enquiry route. Tell us about your existing booking provider and the connection you want before ordering. Embeds, new booking software, payments and complex integrations need their own assessment and agreed scope.
We can discuss the pages, words and handover around your business. The current website scope and pricing explain what the standard build includes.
Discuss the website and booking handover