OpenGTM

Practical GTM capability, made portable.

Desktop destination

Sales scheduling and routing capability reference

A public-source reference for availability, qualification, deterministic routing, booking lifecycle, and privacy-aware scheduling design. It is a clean-room architecture reference, not a deployed scheduler or Cal.com parity claim.

Conventional access

Lifecycle: publication-blocked.

Lifecycle
publication-blocked
Editor
Oliver Longhurst (required)
Reviewed
Review by

Agent-readable: Markdown · JSON

Capabilities in scope

  • Availability and scheduling concepts grounded in public Cal.com documentation
  • Qualification and deterministic routing as original OpenGTM design requirements
  • Booking lifecycle, timezone, concurrency, and idempotency considerations
  • Opaque-session handling that keeps routing answers out of URLs, logs, and referrers

Claims

  • Cal.com's public materials expose scheduling, availability, routing, booking-lifecycle, and API categories that can inform a clean-room reference.
  • The pinned public source revision provides a bounded point-in-time source for narrow static observations; it does not grant blanket reuse rights across the repository.
  • Qualification, deterministic routing, timezone handling, concurrency, idempotency, and traceability in this reference are original design requirements, not claims about Cal.com implementation parity.

Caveats and limitations

  • Publication is blocked pending named editorial approval, prototype disposition, stable versioning, and external validation of the acceptance oracles.
  • This is not a public scheduling product, a live integration, or a claim of feature parity with Cal.com.
  • Repository-wide source copying is excluded because licence metadata, dependencies, assets, notices, fonts, and trademarks require file-level rights review.
  • Provider choices and production rewrite work remain unresolved. No production route or provider connection is implied.
  • Legal, privacy, and security sources require an immediate refresh before the lifecycle can change.

Privacy boundary

Tier-zero design uses synthetic data only. Real leads, representatives, accounts, CRM records, and calendar data are prohibited. Routing answers must use POST and opaque sessions and must not enter query parameters, URLs, logs, or referrers; hidden fields are not secure storage.

Public citations

  1. Pinned Cal.diy source revision - Cal.com
  2. Licence at the pinned source revision - Cal.com
  3. API v2 introduction - Cal.com
  4. Documentation index - Cal.com
  5. Smart routing - Cal.com
  6. Terms - Cal.com
  7. Privacy - Cal.com
  8. Security - Cal.com

Freshness

Core public URLs were checked anonymously. Legal, privacy, security, and other volatile sources must be refreshed immediately before approval.