How to use a Righthand with Cal.com

Quick answer

Use Righthand to prepare a Cal.com booking briefing for the coming week. Keep confirmed bookings distinct from proposed or canceled appointments.

Start with a reviewable deliverable, keeping Cal.com as the accepted home for its records. This guide uses an explicitly approved snapshot or browser read; it does not assume that every provider API action is exposed by your Righthand connection.

Evidence and access

Cal.com documents booking retrieval and separate booking-change operations. See the official Cal.com reference. Provider capabilities and Righthand's available tools are separate checks.

Use the owner's approved event-type and booking snapshot, availability rules, time zones, and actual booking IDs. Proposed options stay provisional. Verify the required tools and owner-approved scope through Righthand integrations; use the supplied packet when a native read is unavailable.

Define the objects and authority

Include these fields in the working input: booking UID, event type, host, attendee, start, timezone, status, location. These are the requested review columns, not a promise that every provider endpoint returns them under those exact names.

Reading a booking does not authorize rescheduling it. Keep host availability, external invites, and cancellations with the booking owner.

Illustrative first-run brief

Use the owner-provided Cal.com snapshot or approved read-only view. Review the supplied next-week bookings for one host. List confirmed sessions, missing preparation inputs, and uncertain statuses. Do not create, cancel, or reschedule. Run once for the agreed sample, using America/Los_Angeles for the review deadline and preserving source timestamps separately. Return the draft in this conversation by Friday at 3 PM Pacific for the calendar owner to review. Include source references and missing fields. Do not write records, spend money, change permissions, or send external messages. Stop and report an unavailable source rather than substituting another account.

Expected result and verification

A canceled slot is excluded from the confirmed agenda but retained in an exception section if follow-up is needed.

Compare a booking UID, status, and local start time with the original booking view. Record the source cutoff, applied filters, and items excluded from the sample. The reviewer should be able to follow each consequential finding back to an original object. A well-written summary is not evidence that a proposed action happened. If a later write is authorized, verify its specific result separately before changing the task's status.

Illustrative input and draft output

These synthetic entries show the requested review, not live account results or a provider field schema.

Common failure and recovery

Timezone conversion can shift the meeting date. Preserve original timestamps and check the attendee-facing time before preparing reminders.

If the snapshot lacks the current event type or availability, ask the scheduling owner for a fresh view before offering options.

FAQ

What should the reviewer verify first?

Check booking identity, event type, duration, staff, and timezone. A possible slot is not a held booking, and a requested move is not confirmed.

How should a repeat run be scoped?

Retain booking IDs and availability cutoff. Refresh the calendar before any authorized change and verify the resulting booking separately from the option-selection draft.

For connection and permission details, use Righthand Docs. Review Pricing alongside any separate provider charges before expanding the workflow.