4 GUIDESCalendars
Primary job: Read free/busy across every google calendar you actually attend, then write the confirmed meeting to one chosen destination calendar.
Typical use: Keeping a work and a personal google calendar from colliding.
Proof to keep: Tick each calendar that must block time, then separately choose the one destination calendar.
Boundary: A calendar connection should expose availability, not private appointment content. Account permissions and administrator policy can also restrict what is available.
5 GUIDESVideo conferencing
Primary job: Attach a google meet room to each confirmed booking using the connected workspace account's permissions.
Typical use: Giving external guests a join link that needs no software install.
Proof to keep: Confirm tenant policy for external and anonymous join, including lobby admission.
Boundary: Room creation depends on the connected provider's account, licensing, and API policy. A safe fallback location should be visible if creation fails.
2 GUIDESMessaging
Primary job: Send scheduling activity to the channel where a team coordinates without exposing private guest information.
Typical use: Alerting a team when a high-priority meeting is booked.
Proof to keep: Decide which events deserve a notification and suppress the rest.
Boundary: Chat notifications should be a signal, not the system of record. Sensitive answers and private management links require stricter handling than ordinary alerts.
1 GUIDEEmail messaging
Primary job: Place proposed times and scheduling links inside an existing email workflow while preserving the conversation's context.
Typical use: Offering several concrete times in a reply.
Proof to keep: Verify that expired proposed times fail gracefully.
Boundary: Email clients render interactive content differently. Every proposed-time experience needs a normal, accessible link as a fallback.
5 GUIDESSales and CRM
Primary job: Associate a meeting with the right person, company, owner, and revenue record so follow-up begins with clean context.
Typical use: Routing an account to its existing owner.
Proof to keep: Test duplicates, missing owners, and an ineligible routing answer.
Boundary: CRM automation is only as reliable as ownership and matching data. Define a visible fallback for ambiguous or missing records.
1 GUIDECustomer success
Primary job: Offer an appropriate customer session from the support conversation and return the booking state to the relationship record.
Typical use: Escalating a conversation to a live session.
Proof to keep: Route test accounts with and without an assigned owner.
Boundary: A meeting should not replace an answer that can be delivered asynchronously. Use eligibility rules to protect both customer and specialist time.
2 GUIDESPayments
Primary job: Authorize the required charge before a paid appointment becomes a confirmed reservation.
Typical use: Reducing unpaid reservations for professional time.
Proof to keep: Publish cancellation, tax, and refund terms before checkout.
Boundary: Payment, tax, refund, and dispute obligations vary by business and location. Meetin.gs should not confirm the time until payment state is authoritative.
3 GUIDESRecruiting and ATS
Primary job: Let a candidate choose an appropriate interview time while keeping stage, interviewer, and scheduling state aligned.
Typical use: Sending self-scheduling from a candidate record.
Proof to keep: Verify panel availability and interviewer substitutions.
Boundary: Hiring data can be sensitive and subject to retention rules. Limit fields, permissions, and calendar exposure to what the interview needs.
2 GUIDESForms and routing
Primary job: Use a small number of meaningful answers to select the correct host, event type, or non-booking destination.
Typical use: Qualifying by region, need, or company profile.
Proof to keep: Remove questions whose answer never changes the route.
Boundary: Long forms reduce completion and collect unnecessary data. Ask only what changes routing, preparation, or eligibility.
4 GUIDESAutomation
Primary job: Trigger downstream actions from scheduling events without engineering work, at the cost of per-task pricing.
Typical use: Proving a workflow quickly before committing to a direct integration.
Proof to keep: Enable failure alerting and name an owner who receives it.
Boundary: Automation can amplify bad data and duplicate actions. Idempotency, retry policy, and a visible failure queue are essential.
3 GUIDESAnalytics
Primary job: Measure the funnel from booking-page view to confirmed meeting, subject to consent.
Typical use: Finding where visitors abandon between viewing times and confirming.
Proof to keep: Load tags only after consent, and accept the resulting measurement gap.
Boundary: Attribution is directional, especially across devices and privacy controls. Never send personal or sensitive scheduling answers as analytics dimensions.
3 GUIDESMarketing
Primary job: Record that a meeting happened without treating the booking as marketing consent.
Typical use: Tagging contacts who met with the team for later segmentation.
Proof to keep: Use a tag that records the meeting without changing subscription status.
Boundary: A booking is not blanket permission for marketing. Consent, purpose limitation, and suppression rules still apply.
1 GUIDESocial and prospecting
Primary job: Move a relevant professional conversation to a scheduling page without losing the personal reason for meeting.
Typical use: Sharing the correct event type in outreach.
Proof to keep: Test the transition on mobile.
Boundary: Scheduling convenience does not justify unsolicited automation. Follow platform rules and keep outreach relevant, personal, and easy to decline.
4 GUIDESExtensions
Primary job: Insert availability into an email or message without leaving the current chrome tab.
Typical use: Adding times to a reply without switching to a browser tab.
Proof to keep: Confirm behavior when the user is signed out of Meetin.gs.
Boundary: Browser extensions have broad potential access. Permissions should be narrow, explained, and reviewed whenever the extension changes.
2 GUIDESAPI and connectors
Primary job: Let product teams create, read, and react to scheduling state through stable authenticated interfaces.
Typical use: Building scheduling inside another product.
Proof to keep: Store delivery IDs and make consumers safe to retry.
Boundary: API and webhook availability is contract-specific. Consumers must handle rate limits, version changes, retries, and deleted records safely.
