The Chatoner Meetings Operations Guide helps teams define how a customer conversation may move into a meeting without losing ownership, consent state, or the next action. It separates demonstrated Chatoner behavior from host, provider, guest, policy, and booking responsibilities so leaders can review the operating model before any production decision.
Start with a defined meeting type and purpose
Describe the customer need that justifies a meeting, the intended outcome, expected duration, eligible host role, approved method, and information the guest needs. A discovery conversation, demonstration, consultation, onboarding review, and support escalation can require different owners and controls.
Meeting types, booking pages, reminders, rescheduling, cancellation, and CRM writeback remain part of the booking team’s approved production contract. This guide does not create those capabilities.
- Customer purpose and meeting type
- Named conversation owner
- Eligible host role
- Approved method category
- Guest expectations and fallback
Define availability and routing without inventing capacity
Document whether an approved implementation uses individual availability, team or group availability, or parallel slots when more than one qualified host can take the meeting. Record how round-robin, collective, priority, language, region, specialty, or another approved routing rule would choose a host.
Buffers, minimum and maximum notice, daily capacity, booking windows, calendar conflict checks, and host authorization must come from the production scheduler. Marketing demonstrations must not imply that a slot is real or bookable.
- Availability source
- Eligible host pool
- Routing rule and owner
- Conflict-check source
- Capacity, buffer, and notice rules
Handle time zones, languages, exceptions, and public holidays
Show the guest’s local time and the host’s operating time zone clearly. Confirm the requested meeting language separately from captions, translation, or interpretation, because those capabilities can vary by method and configuration.
Date and time exceptions, leave, regional public holidays, daylight-saving changes, and temporary capacity changes need an authoritative owner. A fallback route should be visible when no approved host or method is available.
Separate Chatoner Meet from connected methods
Chatoner Meet is the proposed native experience inside Chatoner Meetings. The public interface remains a demonstration until a public endpoint and production capability contract are approved.
For every method, distinguish what Chatoner controls, what the provider or host controls, what the guest receives, which AI functions are approved, and what evidence can return. Phone calls require direction, policy, and fallback details; physical meetings require venue, address, room, arrival, contact, parking, and accessibility information where relevant.
- Method owner
- Guest joining or arrival information
- Host controls
- Method-specific AI boundary
- Evidence-return boundary
Keep consent and recording state visible
Recording or transcription must never be assumed. Provider capability does not replace lawful purpose, attendee notice, required consent, client policy, host and attendee controls, or a clear recording-off state.
Document access, redaction, correction, export, retention, deletion, provider responsibility, and audit expectations before permitting capture. Silence must not be treated as affirmative consent where affirmative consent is required.
Prepare only from permitted context
An AI preparation brief should use the smallest approved set of customer and calendar context, identify its sources, distinguish customer statements from inference, and remain reviewable by the host.
Useful preparation may organize the meeting purpose, known questions, agreed attendees, language and time-zone context, and unresolved decisions. It must not invent customer intent, expose unrelated history, or make commitments for the host.
Review follow-through before it becomes a record
Summaries, decisions, notes, actions, owners, due dates, and follow-up suggestions are advisory drafts until an authorized person checks them. Only permitted and reviewed information should return to the original customer timeline.
A connected CRM, appointment, order, payment, or support outcome may be used only through its approved owner and contract. A completed meeting is progression evidence; it does not by itself prove conversion, revenue, or resolution.
Operate with governance and an evidence trail
Keep the meeting request, availability source, routing decision, method, guest-local time, language support, consent state, attendance event, recording or transcript state, review decision, follow-up, and connected outcome visibly separated.
Assign owners for configuration, provider health, access, incident response, retention, review, and customer support. Record limitations and distinguish observed, inferred, reviewed, connected, modeled, and demonstration states.
- Configuration owner
- Provider and incident owner
- Consent and retention rule
- Human reviewer
- Evidence state and limitation
- Safe disconnected fallback
Review the capability and its release boundaries.
No public Meetings endpoint, workspace entitlement, production provider list, or plan entitlement is confirmed in this repository.
