Treat every request as a conversation waiting for an owner
An appointment request is not a confirmed booking just because it appears on a website. A customer may be asking for a service outside the business’s area, a time that cannot be supported, or a visit that needs more detail before it can be accepted. The first job is simple: make sure one named person can see the request and knows what a useful next response looks like. Without that owner, a polished booking button can quietly turn into an unanswered inbox.
For example, an illustrative home-repair business may receive a request for an evening visit. Before promising a slot, the person handling it may need to check the locality, the type of repair, travel time, and who is available. A consultant may instead need to confirm the client’s topic and whether the meeting is online. The website should collect only the information needed to begin that decision; the business should not ask visitors to expose private background details merely to request a call.
Set up the PaperChai handoff before sharing the booking link
In the relevant PaperChai site dashboard, open Online booking and first decide whether bookings are enabled. Set the notification email to an inbox that a responsible person actively monitors, not an account that belonged to a former staff member or outside helper. Choose a short button label that matches the promise, such as ‘Request an appointment’ when a person still confirms availability. If customers can select a service, use clear current service names or reuse the services already listed on the site rather than creating a second, inconsistent menu.
PaperChai can also offer built-in scheduling, an optional external calendar link, and a WhatsApp number on the booking form. Pick the route the business can actually support. Built-in slots help when the weekly hours and blackout dates are current; an external calendar may fit an existing process; WhatsApp can be a useful fallback when it reaches a monitored business account. Do not enable several routes just to look responsive. If two channels give different answers, the customer has to solve the business’s internal process.
Use a small daily triage sequence
At the start and end of the working day, open Recent requests in the site dashboard and work from oldest unanswered request first. Read the visitor’s preferred contact details, selected service, requested slot when present, and any notes. Check the live booking settings before replying if the request looks surprising: a stale service title, incorrect weekly window, or missed blackout date is a site problem to fix, not a reason to blame the visitor. Keep customer messages and any sensitive context in the normal business system rather than copying them into a public note or a social post.
Then give the customer a real outcome. Confirm a suitable time, ask one focused question needed to offer one, explain that the proposed time is unavailable and offer an alternative, or politely say the work is outside scope. Send the response through the contact route the business normally uses and update the request status in PaperChai so another team member does not repeat or miss the follow-up. A status is a handoff signal, not proof that a customer has read a message, so use it honestly.
Make availability and public links agree
When native scheduling is on, test a normal slot and a date the business cannot take appointments before promoting the link. Weekly hours, slot length, and blackout dates should describe the appointment window—not merely the hours a phone might be answered. If the business uses an external calendar, open it as a visitor would and check that it still loads, identifies the business, and does not reveal another customer’s details. A calendar link that fails or opens the wrong account is worse than a simple request form with a timely reply.
If the business places the booking link on its Google Business Profile, Google’s current guidance says that a business can add booking links where eligible and that Google reviews business links. Keep the PaperChai page accessible without a special login, and do not promise a particular Google approval time or position in Maps. The owned website comes first: test its button, confirmation, notification email, and WhatsApp fallback on a phone and in a private browser before sending more visitors there.
Review the handoff each week, not only after a missed lead
Once a week, scan recent requests for practical patterns: a service people select but the business no longer offers, a common locality outside the service area, a time that repeatedly cannot be accepted, or a status that stays unchanged. Do not infer demand or revenue from a handful of requests. Instead, use the pattern to ask a narrow operating question: should the service wording change, should a day be closed to bookings, does the enquiry form need one clarifying field, or does the responsible person need cover during leave? Make one justified adjustment, then test the public journey again.
A concise private handover note is enough for a small team: who owns the notification inbox, normal response hours, who can approve an exception, and where the live booking settings are changed. Do not put login credentials, customer notes, or payment details in that note. If the business cannot reliably monitor bookings for a period, turn off the relevant public route or state the response delay honestly. It is better to receive fewer workable requests than to collect enquiries that nobody can responsibly answer.
Next step: make the booking promise match the real workflow
Open your PaperChai site dashboard, review Online booking, and send one harmless test request through the live site if the normal process permits it. Confirm that the right inbox receives it, the customer-facing message is truthful about whether the request is pending or confirmed, and the request can be given a clear status after a real response. Also test the flow with a keyboard and on a phone, where many local customers will meet it first.
PaperChai gives a local business one place to maintain the public booking route and review incoming requests; it does not decide availability, send a human reply, or guarantee a Google listing’s review outcome. Start a new PaperChai site or improve an existing one, publish only the contact and booking details the business can support, and keep the same working route in the public places customers use to enquire.
Ready to make your own page clearer?
Create a site with PaperChai