Invite-only V1 beta guide

CallOps is currently a private, invite-only beta. The public website accepts applications for manual review, but an application does not create a workspace, grant access, reserve a phone number, place a call, contact anyone automatically, or charge anything.

What the selected V1 includes

Kia selected a focused operational release around these capability groups:

• local authentication, session revocation, workspace roles, tenant isolation, platform administration, owner-led onboarding, pilot revoke/restore, audit history, and a read-only client portal;
• configurable voice agents, reviewed templates, prompt/behavior editing, Retell provisioning and compensation, owned-number inventory and binding, inbound calls, a consent-checked single outbound call, lifecycle webhooks, recordings, transcripts, analysis, local Playground testing, scorecards, strict tool configuration, and concurrency controls;
• local knowledge and inventory lookup plus configured Cal.com availability, booking, and allow-listed cold transfer;
• contact management, CSV import, internal DNC, contact-local calling windows, campaign builder/scheduler/controls/wallboard, ambiguous-call recovery, and lead scoring;
• wallet ledger, usage statements, owner revenue reporting, tenant dashboard, call explorer, analytics, exports, notifications, responsive/productivity shell, Postgres recovery, and webhook-delivery history; and
• public beta marketing, scoped customer documentation, durable application capture, owner legal review, Kia's acceptance walkthrough, and one monitored internal real-call acceptance milestone.

What remains gated

“Selected” does not mean “accepted.” The current owner scope has selected capabilities that still require:

• exact agent use case, truthful business content, prompt, voice, analysis fields, calling-window policy, Cal.com configuration, transfer destination, and owned-number choice;
• a private Growth/Scale or explicitly comped pilot entitlement for the selected client portal, campaign wallboard, usage statements, advanced analytics, and CSV exports; otherwise those surfaces must move to later;
• final Retell agent/tool/number/webhook configuration and provider acceptance;
• a consenting monitored-call recipient, AI disclosure, recording/legal decision, time window, spend cap, verification plan, and rollback/stop conditions;
• personal owner walkthrough of the exact deployed build; and
• deployment of the new durable campaign lease, daily-cap, and provider circuit-breaker schema before the scheduler can be represented as live V1 acceptance.

A local test, mock call, saved flow, stored knowledge source, or green build is not evidence that Retell, a carrier, Cal.com, a transfer destination, a person, a payment provider, or counsel accepted the result.

The local candidate now forces a signed, call-bound record_opt_out tool into every published Retell LLM configuration and prevents later analysis from downgrading that result. This is an application safety contract only until the exact Retell version invokes it successfully during an approved real call.

What is saved for later

The public V1 does not promise:

• public web chat or two-way SMS;
• a public REST API or customer API keys;
• signed outbound webhooks, inbound lead hooks, or generic/custom webhook tools;
• native CRM or Google/Outlook shared-calendar synchronization;
• self-serve subscriptions, wallet top-ups, refunds/disputes, automatic recharge, included-plan buckets, welcome minutes, or public prices;
• automatic number purchasing or recipient-bound invitation delivery;
• Retell-native knowledge-base synchronization or runtime conversation-flow execution;
• an external DNC registry adapter, separate consent-evidence repository, or campaign-certification feature;
• Slack/Teams delivery, the activity feed, durable webhook retries, durable distributed rate limits, or automated retention/deletion.

Those items remain in the private roadmap and code inventory. Excluding them from V1 does not erase their prior implementation or evidence.

Applying and onboarding

1. Submit the public beta application with truthful contact and use-case information.
2. The request is stored for manual review with no response-time SLA.
3. If approved, Kia or the platform owner uses the selected owner-led onboarding path to create access. CallOps does not automatically send a recipient-bound invitation in this V1.
4. Begin with mock-first configuration and review. Use no fabricated contacts, consent, activity, billing, or provider acceptance.
5. Treat every provider mutation, real recipient, call, spend, and legal decision as a separate approved gate.

Billing during beta

Public prices and self-serve checkout are closed. If an accepted workspace receives a private commercial arrangement, the exact terms and in-workspace records are its source of truth. The selected wallet ledger, statements, and owner revenue views are recordkeeping capabilities; they are not a public price list or proof that live payment acceptance is enabled.

Support and follow-up

Applications and owner directives are reviewed manually. The beta has no public response-time SLA. Never send a secret, API key, consent record, private phone number, or regulated data through the public application form.