In “Vapi Voice Assistant Guide: Book Appointments with Cal.com and Make.com – [Part 2]” you’ll follow a hands-on demo and clear walkthrough of the Make.com setup so you can automate booking flows with a voice assistant. You’ll see how the assistant asks for times, how responses are transformed into API calls, and what to expect from the video by Henryk Brzozowski.
The guide outlines the ChatGPT completion system prompt and strict JSON rules (startTime fixed at 05:00, endTime at 23:00, always choose the next available date), plus the required API headers/parameters and tips for extracting busy slots from calendar DATA. Practical notes—like hourly slots between 7am and 11pm, ignoring the +02:00 offset, and sample available/busy outputs—help you plug the flow into Make.com quickly.
Part 2 Objectives and Scope
Goals of this guide: booking appointments via Vapi Voice Assistant
In this part, you will learn how to use the Vapi Voice Assistant to book appointments by connecting natural language decisions to Cal.com via Make.com. The goal is to give you a practical, reproducible pattern: how the assistant decides on a date, how ChatGPT is used to produce machine-readable times, how Make.com orchestrates the flow, and how you call Cal.com to create a slot. You’ll end up with clear rules and payload examples you can drop into your own automation.
What is covered in Part 2 versus Part 1
Part 1 likely introduced the Vapi Voice Assistant concept, basic conversation flows, and initial Cal.com exploration. Part 2 focuses on the end-to-end booking flow: the exact ChatGPT completion system prompt used in the second Make.com setup, the Make.com scenario structure, HTTP request details (headers and payloads), time-handling patterns, and the logic for extracting busy versus available slots from DATA. In short, Part 1 is conceptual and Part 2 is practical and implementation-focused.
Target audience and prerequisites
This guide is for you if you are implementing voice-based or chat-based scheduling using Cal.com and Make.com and you are comfortable with basic API concepts. You should know how to create a Make.com scenario, use HTTP modules, and configure a ChatGPT completion step. Familiarity with timezones, ISO datetime formats, and JSON will make following the examples much easier.
Expected outcomes after following this guide
After following this guide, you will be able to: craft the ChatGPT system prompt to return valid booking date ranges, assemble the HTTP request body expected by the demo Cal.com integration, place and version Make.com modules correctly, and reliably convert available slot lists into the payload format Cal.com needs. You’ll also be able to extract busy slots from a given DATA list and produce the three available slots required by the demo.
Video Reference and Credits
Video by Henryk Brzozowski and key timestamps to follow
The demo referenced throughout this guide was presented by Henryk Brzozowski. The video demonstrates the Vapi Voice Assistant making scheduling decisions, the Make.com scenario that performs orchestration, and the differences between the first and second setups. When you watch the video, follow the portions where Henryk explains the ChatGPT completion system prompt, the HTTP request data, and the Make.com scenario flow for the clearest mapping to this document.
LinkedIn reference and author contact: /henryk-lunaris
If you want to reach out with follow-up questions or feedback about the demo, Henryk’s LinkedIn handle is provided in the video context as /henryk-lunaris. He is the author of the walkthrough and the source of the prompts and scenario choices used in the demo.
How the demo maps to the written guide
Every section in this guide mirrors a segment of Henryk’s demo: the ChatGPT system prompt used in Make.com is reproduced here; the HTTP request payloads and headers match the examples used in the second version of the Make.com setup; the DATA extraction logic is the same process Henryk demonstrates to identify busy and available slots. Use this text as a written checklist and recipe to re-create the demo steps you see in the video.
Noting version differences demonstrated in the video
Henryk shows two versions of the Make.com setup. The first version used a simpler flow with a different placement of the HTTP module, while the second version introduces a dedicated ChatGPT completion system prompt and moves the HTTP request to a slightly different spot in the scenario to accommodate the new JSON output shape. This guide highlights those differences and recommends you adopt the second version pattern for more predictable scheduling decisions.
High-Level Architecture and Components
Vapi Voice Assistant role and responsibilities
You use Vapi as the conversational layer: it captures the user’s intent and preferred time, then hands that raw input to the automation chain. The assistant’s responsibilities are to ask clarifying questions if necessary, accept user responses, and format the result so the downstream automation can act on it. Vapi’s job ends when it provides the scheduling parameters to Make.com.
Cal.com as the booking engine and available endpoints
Cal.com is the booking engine that actually creates events or reserves slots. In the demo you interact with Cal.com via HTTP requests that either reserve a slot directly or create an event of a given type. Cal.com exposes endpoints for creating events, retrieving availability, and managing users and event types. In the demo, you use a Create Booking-type endpoint, supplying startTime, endTime, and identification parameters so Cal.com can confirm the reservation.
Make.com used as automation/orchestration layer
Make.com is the glue. You build a scenario that receives the Vapi/ChatGPT output, formats the dates, composes the HTTP payload, calls Cal.com, and handles responses or failures. Make.com also hosts the ChatGPT completion module in the flow (in the second version), helping you transform natural language into strictly formatted JSON that the HTTP module can consume.
ChatGPT prompt usage and role in scheduling decisions
ChatGPT is used as a transformation and decision engine: given the current date and the user’s requested booking time, it must output a strict JSON object containing startTime and endTime in a prescribed datetime format. It follows hard rules (e.g., start 5am, end 11pm, choose date ahead of now). You use a system prompt to ensure ChatGPT always returns correctly formatted output that Make.com can pass directly into the HTTP request.
Cal.com Integration Details
Required Cal.com API parameters and authentication patterns
In the demo the HTTP request includes these key parameters: apiKey, userId, startTime, endTime, and timeZone. Although some implementations put the API key in a request header (Authorization: Bearer
Event types vs. direct slot reservation: when to use eventTypeId
You can either create an event of a specific event type (eventTypeId) or directly reserve a slot. Use eventTypeId when you want Cal.com to apply a predefined event template (length, location, metadata, etc.). If your booking is a simple slot reservation without the need for Cal.com’s template behaviors, omit eventTypeId and create the booking directly with start and end times. The demo notes that eventTypeId is not needed but is optional if you want to enforce specific event rules.
Time zone handling and recommended default (e.g., Europe/Warsaw)
Time zones matter. The demo uses Europe/Warsaw as an example default, and you should choose the timezone that matches your user base or calendar configuration. Ensure both ChatGPT output and your Cal.com request include the same time zone reference so times align. If you send naive datetimes without timezone offsets, document that the timeZone parameter (e.g., “Europe/Warsaw”) defines interpretation.
Examples of Cal.com request payloads and responses
An example request body used in the demo looks like this:
{ “apiKey”: “aoiwdjoawijdwaoji”, “userId”: 123456789, “startTime”: “2024-04-19T05:00:00.000”, “endTime”: “2024-04-19T23:00:00.000”, “timeZone”: “Europe/Warsaw” }
A likely minimal successful response from Cal.com might return confirmation details:
{ “status”: “success”, “bookingId”: “bk_abcdef123456”, “startTime”: “2024-04-19T05:00:00.000”, “endTime”: “2024-04-19T23:00:00.000”, “userId”: 123456789 }
Adjust fields to match the exact Cal.com API you call; this example follows the structure used in the demo.
Make.com Setup: Versions and Differences
Overview of Make.com scenario flow used in the video
The scenario in the demo typically follows this flow: receive input (Vapi or webhook) → call ChatGPT completion module (system prompt) to produce start/end JSON → use formatDate or set variables to format the date → perform the HTTP request to Cal.com → handle response and notify the user. The second version places the ChatGPT completion earlier to guarantee a predictable JSON payload for the HTTP step.
Differences between first and second Make.com setups
The first Make.com setup used a lighter ChatGPT step and performed more transformation inside Make.com before the HTTP call. The second setup moves more of the decision-making into ChatGPT using a stricter system prompt and then pushes a near-final JSON into the HTTP module. The second approach reduces Make.com complexity and makes the HTTP step simpler and more deterministic.
Where to place the HTTP request module in the scenario
Place the HTTP request module right after the formatting/variable set steps that ensure startTime and endTime are in the exact string format Cal.com expects. In the second version, you place the HTTP module after the ChatGPT completion step and any minor date formatting helpers so the HTTP payload is assembled from validated variables.
Best practices for versioning Make.com scenarios
Versioning is important. Duplicate scenarios before major changes, add descriptive scenario names and comments, and use modules labeled with purpose (e.g., “ChatGPT — compute times”, “FormatDate — YYYY-MM-DD”, “HTTP — Cal.com Create Booking”). Keep credentials in scoped connections or encrypted variables, and document the change log inside scenario notes.
HTTP Request Details and API Slots
Headers to include: Content-Type: application/json and others
The HTTP request must include at least Content-Type: application/json. If you use header-based auth, include Authorization: Bearer
Required parameters: apiKey, userId, startTime, endTime, timeZone
The demo requires these parameters in the request body: apiKey (demo value “aoiwdjoawijdwaoji”), userId (a number from the first video), startTime, endTime, and timeZone (e.g., “Europe/Warsaw”). Make sure startTime and endTime comply with the ChatGPT prompt output rules.
Optional parameters: eventTypeId and when to include it
eventTypeId is optional in the demo. Include it when you want Cal.com to create an event using a predefined template (duration, invitee form, etc.). If you don’t need those behaviors, you can omit eventTypeId and send only start and end times.
Exact structure of the request body used in the demo
The exact structure used in the demo is a JSON object like this:
{ “apiKey”: “aoiwdjoawijdwaoji”, “userId”: 123456789, “startTime”: “2024-04-19T05:00:00.000”, “endTime”: “2024-04-19T23:00:00.000”, “eventTypeId”: null, “timeZone”: “Europe/Warsaw” }
If you include eventTypeId replace null with the proper identifier. Send this payload with Content-Type: application/json in the HTTP request.
ChatGPT Completion System Prompt: Rules and Output
Context and intended role of the system prompt in Make.com flow
The system prompt is the guardrail that forces ChatGPT to return machine-readable, deterministic output that your Make.com HTTP module can consume. It frames ChatGPT as a scheduler assistant: you provide the current date/time and the user’s requested time and ChatGPT must output JSON with startTime and endTime following precise rules.
Hard rules: start time must always be 5am and end time 11pm
A central hard rule in the demo is that startTime must always be 05:00:00.000 and endTime must always be 23:00:00.000 on the chosen date, irrespective of what the user says. ChatGPT must always set those hours exactly, and only vary the date portion.
Date selection rule: choose a date after current time, usually the closest day
ChatGPT must choose a date that is after the provided current time. Usually you pick the closest qualifying day (tomorrow or the next available day that satisfies the user’s intent). This prevents booking in the past. The system prompt includes the current timestamp and the user-provided desired times, and instructs ChatGPT to return a date strictly ahead of the now field.
Expected JSON output format for startTime and endTime
The expected output is strict JSON. Example from the demo:
{“startTime”: “2024-04-19T05:00:00.000”, “endTime”: “2024-04-19T23:00:00.000”}
No extra text should be returned—only JSON—so the HTTP module can parse it directly.
Time Handling, Formatting, and Utilities
Standard datetime format used in example: YYYY-MM-DDTHH:mm:ss.SSS
The demo uses the format YYYY-MM-DDTHH:mm:ss.SSS for datetimes (e.g., 2024-04-19T05:00:00.000). Keep subsecond precision (.000) to match the examples and avoid rounding issues. Always pair the datetime with an explicit timeZone parameter if your service interprets naive timestamps.
Using set multiple variables tool and formatDate helper
Make.com’s set multiple variables tool and formatDate helper are used to transform ChatGPT output and to build request body fields. For example, use formatDate(31.startTime; “YYYY-MM-DD”) to extract the date portion and then append the constant time portion (T05:00:00.000) to form the final startTime.
How to ensure times are ahead of now and timezone considerations
When generating dates, compare the candidate date to the now value (which will include current timezone context). If the candidate date/time would be in the past, increment to the next day. Always use the same timezone logic across ChatGPT, Make.com formatters, and the Cal.com request. If you rely on user locale, convert times to the server/calendar timezone using helpers or by specifying the timeZone field.
Examples: converting available slots into required payload format
If you have an available slot date such as “2024-04-20” from ChatGPT or from slot extraction, build the payload like:
{ “startTime”: “2024-04-20T05:00:00.000”, “endTime”: “2024-04-20T23:00:00.000”, “timeZone”: “Europe/Warsaw” }
You can also use format helpers to build the string dynamically: formatDate(selectedDate; “YYYY-MM-DD”) + “T05:00:00.000”.
Extracting Busy Slots from DATA with ChatGPT
Understanding DATA input: each ‘time’ line is an available hourly slot
In the DATA block used in the demo, each line containing “time” represents an available hourly slot (typically between 7am and 11pm). The list should be contiguous if fully available; gaps indicate busy slots.
Step-by-step: identify missing slots as busy slots
Step 1: Enumerate the expected hourly slots (7am, 8am, …, 11pm). Step 2: Parse DATA and mark which of those expected hours appear. Step 3: Any expected hour that is missing in DATA is a busy slot. Step 4: From the remaining available slots, pick any three to return along with any busy slots you detected.
Output requirements: list any busy slots and three available slots
Your output must include any busy slots found and exactly three available slots (if at least three are available). Format the output in a concise human-readable line as demonstrated in the demo, for example: Available: 7am, 11am and 5pm Busy: 8am and 6pm. Ignore timezone offsets like +02:00 as the demo instructs.
Example input and output to validate the extraction logic
Example DATA (simplified):
DATA: time: 07:00+02:00 time: 09:00+02:00 time: 11:00+02:00 time: 17:00+02:00
Expected interpretation: expected sequence 7am..23pm shows 8am and 10am missing (and others if missing). For this minimal example you might produce:
Available: 7am, 9am and 11am Busy: 8am
If there are multiple missing slots, list them all under Busy. Ensure you list three available slots (choose any three that exist).
Conclusion
Recap of Part 2 key takeaways and operational rules
In Part 2 you learned the complete flow to go from Vapi’s user input to a Cal.com booking: use a strict ChatGPT system prompt that always outputs JSON with startTime at 05:00 and endTime at 23:00 on a date after now, use Make.com to orchestrate and format dates, and call Cal.com with the specified body and headers. You also learned to extract busy slots by detecting missing hourly entries in DATA.
Next steps to implement the demo in your environment
Start by copying the ChatGPT system prompt into your Make.com ChatGPT completion module, secure your Cal.com credentials in Make.com variables, build the scenario flow described (input → ChatGPT → formatDate/set variables → HTTP), and test with DATA samples to validate busy/available extraction. Iterate on prompt phrasing if ChatGPT sometimes returns extra text; enforce “output only JSON” in the system prompt.
Where to find resources and the referenced video for visual guidance
Refer to the video demo by Henryk for the visual walkthrough and step-by-step screen recording of the Make.com setup. Use that alongside this guide to map each example to the corresponding module placement and parameter value in your scenario. The video clarifies module ordering and shows the difference between the first and second configurations.
Encouragement to iterate on prompts and automation flows
Be ready to iterate. Small changes in prompt wording or variable formatting can make your flow more robust. Test edge cases (past dates, timezone mismatches, partially-filled DATA lists) and refine the system prompt rules if the assistant returns unexpected content. With a few iterations you’ll have a predictable, user-friendly appointment booking assistant that integrates Vapi, ChatGPT, Make.com, and Cal.com reliably.
If you want to implement Chat and Voice Agents into your business to reduce missed calls, book more appointments, save time, and make more revenue, book a discovery call here: https://brand.eliteaienterprises.com/widget/bookings/elite-ai-30-min-demo-call