Booking Intake → Calendar

Booking channels with no dedicated UpServe integration — Naver Smart Place and the like — can still be handled. The agent opens a real browser, reads the booking list, and adds only the new ones to Google Calendar.

The hard part of this recipe isn’t copying bookings across. It’s not copying the same booking twice.

What you get

• On a fixed interval, the agent checks the booking screen.
• Only newly arrived bookings are added to Google Calendar.
• Every booking it adds gets recorded, so the next run won’t duplicate it.
• Cancellations and changes are reported to you.

What to turn on

In the agent’s Settings tab:

Connect Google Calendar with a single sign-in from the Integrations  sub-tab under Skills.

Step 1: Signing in to the booking screen

Channels like Smart Place require a login. Never give the agent your password. Instead, have it hand the screen back to you.

Put this in the system prompt:

When reaching the booking screen requires a login,
do not ask for the password — hand the screen over to the user
and ask them to sign in themselves. Continue once they're done.

When the agent hits a login screen it temporarily hands control back to you. You sign in, press “done,” and the agent picks up where it left off. It never touches the password.

The session usually holds for a while, but when it expires the agent asks again. If the session expires while you’re away, that run is skipped — that’s expected behavior, and it retries on the next run.

Step 2: Write the system prompt

Role: booking intake.

Watch:
- The Naver Smart Place booking management screen

Every run:
1. Open the booking screen and read bookings from today onward.
2. Read bookings/registered.md for the list of booking numbers already handled.
   - If the file doesn't exist, start with an empty list.
3. Add only the bookings not in that list to Google Calendar.
   - Title: "[Booking] name / party size"
   - Start/end: the booking time
   - Description: contact, requests, booking number
4. Append each successfully added booking number to bookings/registered.md.
5. If a previously added booking was cancelled or changed, fix the calendar
   event to match and tell the user about that one only.
6. If there are no new bookings and no changes, send no message at all.

Note: the booking number is the only key for duplicate detection.
If a number can't be recorded, do not add the booking — tell the user instead.

Three things matter here.

• Match on booking number — matching on name or time creates duplicates the moment two guests share a name or a booking gets rescheduled.
• Don’t add if you can’t record — “added but not recorded” is the dangerous state; the next run adds it again.
• Silence when nothing changed — “no new bookings” every run makes the notification worthless.

Step 3: Pick an interval

Ask in the chat:

Check the booking screen every 30 minutes and add new bookings to the calendar.

The agent registers its own schedule. Tap the approval card once when it appears.

Match the interval to how often bookings actually arrive. A few a day? One to two hours is plenty. SU scale directly with how often it runs.

An agent can hold at most 5 active schedules at once.

Step 4: Try a first run

Don’t wait for the next interval:

Check the booking screen once now.

The first run may push every existing booking into the calendar at once. If you’d rather avoid that, set a baseline first:

Don't add the current bookings — just record their numbers as a baseline.

Tuning

• Add ad management — tell the same agent “every Monday, review the ad report and list keywords with low conversion” and it reuses the same signed-in session for the ads screen. Just instruct it to get approval before actually changing any bids.
• Separate calendars — “only put bookings on the ‘Store Bookings’ calendar.”
• Notification tone — “tell me right away about same-day bookings; add the rest quietly.”

Next steps

• Connections — Google Calendar connection and permission scope
• Scheduling — intervals and time windows
• Partner Order Intake → ERP — a different way to receive requests from outside

Advanced

Where duplicates actually come from

Almost all duplicates happen in the gap between “the calendar event was created” and “writing the record file failed.” You can’t eliminate it, but you can shrink it.

1. Have the agent add one booking, then record it immediately, in a loop. Batching all the writes to the end means a mid-run failure duplicates everything.
2. Add “search the calendar for that booking number before adding” to the prompt. If the booking number lives in the event description, the calendar itself becomes a second line of defense when the record file is lost.

Where the record file lives

A file saved at a relative path like bookings/registered.md lands in that agent’s private memory area and is readable at the same path on the next run. Other agents on the same team can’t see it.

The file grows over time. Adding “keep the last 30 days and drop anything older” to the prompt keeps it tidy.

Channels with no dedicated integration, generally

This recipe applies to any admin screen that’s only visible after signing in, not just Smart Place. One rule decides the approach:

• Visible without a login → HTTP request (light and cheap)
• Needs a login, clicks, or scrolling → Web Browser + hand-off sign-in

Services in the Integrations hub  (Google, Notion, GitHub, Slack, Linear, and more) skip all of this with a single sign-in. Only services outside that list need the approach above.

Cost notes

• Web Browser costs more per call than HTTP request. A short interval adds up fast.
• Instructing it to stay silent when nothing changed cuts the per-run response cost.
• Checking a booking screen is fairly mechanical — the default Standard tier is enough. There is rarely a reason to move this one to Ultra.