# Tee Time Master — Organization Workflows

## Weekly Operating Review

**Owner:** Joshua Bing  
**Cadence:** Monday at 10:00 AM America/New_York  
**Purpose:** Turn launch, booking, revenue, customer, and reliability signals into explicit
decisions and owned follow-up work.

### Inputs

- PostHog organization-health dashboard
- Growth, Engineering, and Support weekly summaries
- Stripe booking-fee reconciliation
- open incidents, risks, approvals, and policy gaps
- current six-week priorities

### Steps

1. Collect current metrics and department exceptions with links to their sources of truth.
2. Compare outcomes with the six-week plan.
3. Identify decisions, blockers, risks, and work that should stop.
4. Confirm one owner and one due date for every accepted follow-up.
5. Joshua approves changes to priorities, policy, spend, or launch scope.
6. Record decisions in Notion and distribute the concise summary.

### Outputs

- approved organization priorities;
- named owners and due dates;
- recorded decisions;
- escalated exceptions; and
- stopped or deferred work.

### Success Condition

Every material exception has an explicit decision, owner, and next review date. Department plans do
not conflict with organization safety or launch priorities.

### Failure Handling

If data is incomplete, record the missing source and owner rather than guessing. Security, privacy,
payment, fairness, legal, or active customer-impact issues leave the weekly process and escalate
immediately.

## Launch Readiness Review

**Owner:** Joshua Bing  
**Trigger:** A public launch date, new course cohort, or material expansion of access is proposed.  
**Purpose:** Prevent a launch commitment before product, legal, security, support, and course
coverage are ready.

### Inputs

- verified production release evidence;
- supported-course and adapter-readiness report;
- security and privacy review;
- finalized customer terms and policies;
- payment and notification verification;
- Support staffing, playbooks, and escalation readiness;
- Growth audience, claims, channel, and measurement plan; and
- rollback and customer-communication plan.

### Steps

1. Assign each readiness lane an owner.
2. Mark every lane Ready, Warning, or Blocked and link the evidence.
3. Confirm that public claims match the production behavior and supported cohort.
4. Confirm counsel has finalized the legal documents required for the launch scope.
5. Confirm Support can recognize and handle booking, payment, credential, and privacy failures.
6. Confirm Engineering has health checks, stop conditions, and rollback capability.
7. Joshua approves, narrows, or postpones the launch.
8. Record the exact approved audience, course cohort, date, offer, and unresolved warnings.

### Outputs

- approved or postponed launch decision;
- exact launch scope;
- remaining blockers and owners;
- customer and incident communication plan; and
- next review date.

### Success Condition

The approved scope can launch without an unresolved critical legal, security, privacy, payment,
fairness, reliability, or support gap.

### Failure Handling

Any critical gap blocks launch. A warning may be accepted only when Joshua records the risk, owner,
mitigation, and deadline. A draft legal page is not treated as final approval.

## Daily Booking-Fee Reconciliation

**Owner:** Joshua Bing, with Support preparing exceptions  
**Cadence:** Daily and after any duplicate-charge or payment-failure report  
**Purpose:** Keep successful bookings and Stripe service-fee outcomes consistent.

### Inputs

- successful booking records;
- Stripe charge and payment outcomes;
- refund and dispute records;
- first-booking-free eligibility; and
- customer support exceptions.

### Steps

1. Match each eligible successful booking to exactly one expected service-fee outcome.
2. Classify missing, failed, duplicate, refunded, or disputed outcomes.
3. Confirm that the first successful booking was free where applicable.
4. Prepare any required customer correction or refund recommendation.
5. Joshua approves money movement or policy exceptions.
6. Execute only the approved correction and retain the Stripe receipt.
7. Link the customer conversation, booking, charge, decision, and receipt.

### Outputs

- reconciliation report;
- resolved payment mismatches;
- customer communication where required; and
- escalated product or payment defects.

### Success Condition

Every eligible successful booking has one explainable payment state, and every correction has an
approved decision and provider receipt.

### Failure Handling

Do not repeatedly retry an unexplained charge. Pause the affected customer's automated booking if
payment state is unsafe, preserve the mismatch, and escalate to Joshua.

## Course Launch Handoff

**Owners:** Engineering for readiness, Growth for launch, Support for customer readiness  
**Trigger:** A course adapter passes staging verification and there is qualified waitlist demand.  
**Purpose:** Move a course from technical readiness to a controlled customer launch.

### Inputs

- course rules and release-window behavior;
- adapter test evidence and known limitations;
- approved production cohort and rollback plan;
- qualified, consented waitlist segment;
- customer copy and support guidance; and
- launch metrics and stop conditions.

### Steps

1. Engineering documents supported actions, hard stops, limitations, metrics, and rollback.
2. Support reviews the failure modes, customer language, and escalation path.
3. Growth prepares the exact audience, claims, rendered message, schedule, and measurement plan.
4. Joshua approves course enablement and the customer campaign separately.
5. Engineering enables the approved production cohort.
6. Growth sends only to the approved consented segment.
7. All departments monitor booking success, manual handoff, complaints, and support volume.
8. Stop or roll back on a security, fairness, course-policy, reliability, or customer-trust breach.

### Outputs

- approved production course cohort;
- customer launch campaign;
- launch observation report;
- known limitations and Support guidance; and
- continue, expand, pause, or roll back decision.

### Success Condition

The course cohort operates within the approved technical and customer guardrails for the complete
observation window.

### Failure Handling

Course security controls, unexpected terms, unsafe response patterns, or systemic booking failures
stop expansion. Engineering preserves evidence, Support receives verified customer guidance, and
Joshua decides whether to pause or roll back.