start_booking
Build a prefilled TimePlex booking link (Book Now card) for a bookable=true shop. The customer opens it, enters contact details and pays; the shop then approves. Flow: search_shops → get_shop_services → search_availability → start_booking (link) → customer payment → shop approval → confirmed. WHAT THIS TOOL DOES NOT DO: it does not create, hold or confirm a booking — confirmed is always false. You cannot see whether the customer paid or the shop approved, so never say the booking is complete, confirmed, paid, secured or awaiting approval. Say a booking link was created: the slot is secured only once the customer pays, and the booking is final after the shop approves. Never invent a confirmation number or status. USE THIS TOOL WHEN: the user wants to book or continue a booking ("book it", "reserve it for two", "예약해줘", "결제해서 진행할게"), or has asked to check availability for a specific shop or service (the link accompanies the open times). Follow-ups such as "the 5 PM one" after shops or slots were shown are booking requests — reuse the shop, service, date, time and party size already in the conversation and never change them silently. When a time was requested, confirm it with search_availability first and put only a returned available time into the link. If the user wants to book but has not chosen a date or time, a shop-level link may be created. When a link is warranted, create it — do not ask "shall I create a link?" first. DO NOT USE IT FOR: finding or recommending shops, menu / price / duration / address / business-hours questions, a service set as unsupported_service, medical procedures, services returned as inquiry_only, or bookable=false shops (use request_booking — TimePlex concierge asks the shop). REPLY: put link_markdown into your reply as-is — never expose the raw URL — and pass on note (how the slot is secured and confirmed). Pass lang (ko|en|ja|zh), the language the user is writing in, so the booking card renders in it. Always reply in the language the user used.
Input Schema
| Name | Required | Description | Default |
|---|---|---|---|
| date | No | YYYY-MM-DD (Asia/Seoul). Optional — omit if the customer has not picked a date; they choose it on the booking page. | |
| lang | No | Customer language (optional): ko|en|ja|zh. Defaults to en. Pass the language the user is writing in so the booking card and its notes render in that language. | |
| slug | Yes | Shop slug returned by search_shops. | |
| time | No | HH:MM. Optional — omit if the customer has not picked a time. | |
| items | No | Optional — omit if no service is chosen yet. Follow the booking_model returned by get_shop_services: use resource_id for designated-staff shops and qty for capacity-based shops. designated: [{service_id, resource_id}] — **exactly one** (these shops book one service at a time). capacity: [{service_id, qty}] — multiple allowed (several services and several people at once). |
Output Schema
| Name | Required | Description | Default |
|---|---|---|---|
| lang | No | Language the card content is rendered in (echo of input lang; en fallback). The widget uses it to localize its own labels. | |
| note | No | How the slot is secured and finally confirmed — mention this to the customer | |
| summary | No | What is preselected on the booking page. | |
| guidance | No | Customer-facing summary of the remaining steps — keep it light and pass it on | |
| confirmed | Yes | Always false — nothing is booked by this tool | |
| link_label | No | ||
| next_steps | No | What the customer does after opening the link (contact info, payment, shop-owner approval) | |
| booking_url | Yes | Prefilled booking page (customer completes contact info + payment there) | |
| reply_header | No | ||
| link_markdown | Yes | Put this into the reply as-is (never expose the raw URL) | |
| reply_header_usage | No |