Set the right expectation in the greeting
Tell visitors that the chat can help them request a discussion or visit. If staff must confirm availability, state that before the person submits details. Avoid language such as booked or confirmed until your team has actually approved the request.
A clear request process is useful outside office hours because the visitor can leave the information needed for a later response. It does not mean a staff member is available immediately or that the chatbot knows every live calendar conflict.
Give the team the information needed to respond
Ask what the appointment is about, the preferred timing, and an appropriate contact method. Keep the request focused. Do not ask visitors to submit a medical history, payment card, or identity documents into a general website chat just to arrange a conversation.
Add verified opening hours, locations, and appointment policies to the knowledge. If a requested time is outside the published hours, the assistant should explain the limitation or offer team review rather than invent availability. When a policy is missing, update the knowledge before publishing the flow.
Sample request flow
Visitor: Can I arrange a consultation? Assistant: [Explain the verified consultation service.] What would you like to discuss? Visitor: A new website for our business. Assistant: What day or time would you prefer? This will be a request for the team to review. Visitor: Thursday afternoon. Assistant: Please share a preferred contact method if you want the team to confirm availability. Team: Review the request and communicate the confirmed arrangements.
Review requests in the workspace
Staff can review appointment information and manage its status through the business workflow. Decide who is responsible for that queue and what happens when more than one visitor requests the same time. A saved request should prompt a real review, not an assumption that a calendar reservation already exists.
Check the contact details and conversation context before responding. If you cannot offer the requested timing, explain alternatives through the appropriate contact route. Keep your published policies current so the visitor understands the next step.
Understand integration limits
The website appointment form is not a confirmed native Google Calendar or Outlook integration. Do not publish synchronised availability, automatic invitations, or reminders unless those capabilities have separately been implemented and tested for your workspace.
A developer-managed connection may use supported events and webhooks where appropriate, but it needs a receiving system and clear handling of duplicates and failures. Ask the provider about the exact workflow rather than treating a request form as a complete scheduling platform.
Test before a busy booking period
Submit a request using your own contact details, review the record, change its status through the staff workflow, and verify what the visitor would be told. Test a missing field, a preferred time outside normal hours, and a request you cannot accept.
On mobile, check that form controls and the send action remain accessible when the chat is open. Review how the widget sits alongside your website contact buttons. Keep another appointment contact route available if the service is unavailable or a visitor prefers a person.
Check the request lifecycle with staff
Use a synthetic request to verify every step: visitor submission, workspace record, staff review, status change, and communication of the confirmed arrangement. Write down who owns each step. If no one is responsible for confirmation, the form may create an expectation the team cannot meet.
Test two requests for the same preferred time. Your staff process should resolve the conflict; the website form should not imply both slots are automatically reserved. Repeat the check with a date outside normal availability and a request missing useful context.
If a visitor needs to reschedule, provide the approved business contact route and explain what the team needs to identify the request. Do not claim automatic calendar cancellation or rescheduling unless you have separately implemented and tested it. Keep the knowledge consistent with the process staff actually follow.
A controlled trial to adapt
Example to adapt: your supplied policy says that consultations need staff confirmation. A visitor requests two possible afternoons. The chat should collect the preference without turning either option into a reserved slot. Have staff review the request, choose a permitted next action, and communicate it through the tested workflow. Then ask whether the visitor can reschedule. The answer should follow your real policy or direct the request to the team, rather than invent a calendar action. This is a suggested test scenario, not an actual booking.