Cal.com for coworking scheduling

This guide scopes Cal.com to one coworking tour event type and one host calendar. It does not prove that a plan, edition, calendar connection, notification, export, backup, or upgrade has been tested here.

Edition check, October 23, 2026: this pilot now covers hosted Cal.com. Its former public repository redirects to the separate MIT-licensed Cal.diy community edition, whose maintainers recommend personal, non-production use. Self-host recovery notes below are retained as evaluation questions for a separately contracted on-premises edition; they are not a recommendation to deploy Cal.diy for member-facing operations.

1. Coworking outcome

Reduce tour-scheduling email while retaining staff control over availability, qualification, accessibility requests, no-shows, and the actual visit. Scheduling augments coordination; it does not replace sales or community judgment.

2. Pilot scope

Create one Tour Booking event type, connect one sales calendar, collect minimum lead fields, and process five real or approved test bookings through a limited link. Exclude rooms, payments, access control, routing, and broad workflow automation.

3. Fit

Good fit: a team with a named scheduling owner, an authoritative calendar, stable tour hours, conflict/buffer rules, privacy wording, and a manual exception route.

4. Non-fit and alternatives

Poor fit: a membership CRM, contractual room-inventory ledger, door-access controller, or unowned calendar. Keep the existing enquiry/manual-booking route and compare the current calendar provider’s native booking feature before accepting another data processor or self-hosted service.

5. Coworking use cases

• Public tour booking with one host or approved host pool.
• Follow-up reminders and rescheduling within an approved workflow.
• Separate evaluation later for consultations, rooms, events, and day passes.

Do not reuse tour acceptance as proof for inventory or payment workflows.

6. Tasks reduced or augmented

Cal.com can reduce availability emails, standardize booking questions, and create calendar events. It cannot qualify a lead, promise room/access availability, handle every conflict, decide accessibility accommodations, or determine retention.

7. Human decisions and approvals

The scheduling owner approves event rules and cutover; the host approves calendar use; privacy approves fields/wording/retention; technical staff configure credentials; sales/community owns follow-up. A person handles exceptions, duplicates, no-shows, complaints, and cancellations affecting visitors.

8. Owners and RACI

Name scheduling owner and backup, pilot host, calendar administrator, privacy reviewer, technical/recovery owner, CRM handoff owner, and visitor-arrival owner. State who can publish/unpublish links and revoke credentials.

9. Prerequisites

Define authoritative calendar, business hours/time zone, minimum notice, buffers, conflict calendars, duration, location, capacity, cancellation/reschedule/no-show rules, lead fields, privacy notice, retention, notifications, CRM handoff, accessibility route, and manual fallback.

10. Skills and effort boundary

The pilot needs calendar administration, scheduling design, privacy review, DNS/TLS and database operations if self-hosted, and user-support skills. The catalog’s 1-3 days estimate is unverified and excludes calendar/vendor approval, self-host operations, recovery, and workflow review.

11. Deployment choice

The catalog covers hosted Cal.com. Its free individual plan and paid team plans have different entitlements; confirm shared availability and host assignment on the pricing page. Enterprise on-premises access requires a separate agreement. Cal.diy is research-only here because its official documentation recommends non-production use.

12. Architecture and dependencies

Map public booking page, Cal.com service/database if self-hosted, host account, connected calendar provider/token, mail delivery, video/location data if used, DNS/TLS, monitoring, backup/export, and CRM/manual handoff. Treat each app or webhook as an additional processor and failure path.

13. License and edition boundary

Hosted Cal.com is classified as freemium software with commercial service terms. MIT applies to the separate Cal.diy community code, not the hosted Cal.com application. Confirm the exact plan and feature entitlements before publishing a tour-booking link.

14. Total cost boundary

Record subscription/edition or self-host compute/database/storage, DNS/TLS/email, calendar/admin setup, privacy review, updates, backups, monitoring, support, workflow maintenance, failed-booking handling, and exit labor. No price, free-tier limit, or savings figure is asserted here.

15. Data map

Data	Source	Purpose	Handoff/exit
Host availability and event details	Host/calendar	Offer valid tour slots	Authoritative calendar and event register
Attendee name/contact and answers	Booking form	Confirm and prepare tour	Minimum approved CRM/manual record
Bookings, cancellation, reschedule	Cal.com	Scheduling state	Export/reconciliation if supported
Calendar credential/token	Calendar provider	Read/write calendar as configured	Revoke at provider
Notification/workflow logs	Service/connectors	Delivery and troubleshooting	Retention-limited evidence

Payment data is outside scope.

16. Privacy and retention

Collect only fields needed before a tour, explain use and follow-up, avoid sensitive free-text prompts, restrict staff access, and define deletion for abandoned/cancelled/completed bookings and logs. Verify provider/self-host residency, subprocessors, deletion, and data-subject processes separately.

17. Security baseline

Use TLS, individual admin/host accounts, MFA where available and approved, least-privilege calendar scopes, protected API/OAuth secrets, restricted administration, private calendar-detail controls, and prompt token revocation on exit. Official API docs warn that API keys are privileged and must not be exposed client-side or publicly.

18. Compliance and expert review

Booking forms and visitor records may trigger privacy, marketing-consent, accessibility, and local visitor-policy obligations. Obtain qualified privacy/legal review where required. Get facilities/access and contract review before adding rooms, capacity promises, payments, or access credentials.

19. Integration boundary

No calendar, CRM, email, video, payment, or webhook integration is catalog-verified. For each, record official docs, scopes, data fields, write behavior, duplicate/idempotency behavior, retry/error visibility, secret owner, revocation, and manual fallback.

20. Configuration baseline

Record exact plan/commit/version, event slug, owner, duration, time zone, availability, buffers, notice/window, conflict calendars, location wording, fields, confirmation/reminder/cancellation text, privacy link, credential scopes, notifications, retention, and manual handoff. Keep secrets out of version control.

21. Smallest useful experiment

Using official documentation, create one Tour Booking event type, connect one sales calendar, and process five bookings in one week. Limit link exposure and retain the previous enquiry route.

22. Implementation sequence

1. Approve owner, deployment/edition, event rules, data fields, and fallback.
2. Verify current calendar integration and required feature from official sources.
3. Configure staging/test mode or a tightly limited production pilot.
4. Connect one calendar with minimum scope and verify private detail behavior.
5. Test booking, conflict, time zone, notifications, reschedule, cancellation, and revocation.
6. Run five bookings and reconcile calendar, attendee, and staff outcomes.
7. Review export/recovery evidence before expansion.

23. Migration and rollout

Publish the pilot link only to a limited audience, avoid overlapping automated links for the same inventory unless conflicts are proven, and communicate a manual route. Reconcile every pilot booking with the host calendar and open follow-up before changing the website’s primary call to action.

24. Required test plan

Test valid booking, blocked conflict, simultaneous contention, business-hour boundary, daylight-saving/time-zone display, minimum notice/buffer, required-field validation, notification success/failure, cancellation, reschedule, duplicate attendee, private calendar detail, token revocation, admin/host roles, manual fallback, export/account recovery, and self-host restore if applicable.

25. Acceptance criteria

Five bookings appear correctly on the authoritative calendar; no tested conflict is double-booked; attendee/host messages are accurate; minimum PII is collected; cancellation/reschedule and manual fallback work; credentials can be revoked; open bookings can be reconciled/exported; owners approve measured support effort.

26. Success metrics

Track completed bookings, conflicts, duplicates, no-shows, reschedules/cancellations, notification failures, staff handling time, attendee corrections, manual-fallback use, retention actions, and unresolved handoffs. Do not claim revenue or staffing savings from five bookings.

27. Monitoring and alerting

Monitor booking-page availability, calendar connection/token errors, notification failures, webhook/workflow failures if enabled, database/storage/backups if self-hosted, and stale open handoffs. Route failures to a person able to contact affected attendees manually.

28. Operating cadence

Review upcoming tours and exceptions daily during the pilot, calendar scopes and host access on staff changes, event wording/hours regularly, retention on schedule, and version/backup health for self-hosting. Re-test after calendar, time-zone, workflow, form, edition, or host changes.

29. Failure modes and response

Plan for stale availability, revoked token, duplicate event, wrong time zone, missing notification, public leakage of calendar details, unavailable booking page, unowned no-show, and unsupported plan feature. Unpublish the link on unexplained conflicts or privacy leakage and resume manual scheduling.

30. Backup procedure

For self-hosting, identify database, uploaded/configuration state, secrets/references, and exact release from current official deployment guidance, then create protected consistent backups. For SaaS, verify supported export and account recovery; provider continuity is not the same as operator recovery. Keep the host calendar and open-booking register independently usable.

31. Restore drill

For self-hosting, restore into isolated staging and verify event type, availability, five representative bookings, roles, and calendar reconnection using test credentials. For SaaS, test export readability and an approved account-recovery scenario without disrupting production. Exact export/restore coverage remains unverified.

32. Upgrade, rollback, and exit

For self-hosting, pin releases, review upstream release/migration instructions, back up first, stage the target, and regression-test bookings, calendar sync, jobs, email, credentials, and exports; rollback requires a compatible pre-upgrade state. For SaaS, review release/plan changes and maintain manual fallback. Exit by unpublishing links, notifying/reconciling affected attendees, exporting approved records, revoking tokens/keys, removing webhooks, and returning to manual or replacement scheduling.

33. Sources, evidence, and unknowns

Reviewed 2026-07-17: homepage, repository, documentation, and pricing. Product claims are limited to the catalog and current official sources; version-specific self-host backup/upgrade pages were not established in this review.

Evidence is documentation review only. Untested: current plan limits/feature boundaries, deployment, calendar sync/scopes, conflict behavior, time zones, notifications, webhooks, exports, deletion, backup/restore, upgrade/rollback, account recovery, performance, support, residency, subprocessors, and compliance. Every item remains an implementation gate.