Mock Operating Playbook

Customer Service Playbook & SOPs

See how customer signals become owned actions.
Explore the routines, decision rules and completion checks behind a service operating model.

Open the Complete Playbook PDF ↗

Version 1.1 · October 5, 2026 · 9 procedures

Fictional demonstration. All accounts, service targets, roles and examples are invented. These procedures are a mock operating model; they do not enable new agents, customer messages or service-level timers.

Case study context. The $100K to $1M pipeline example is illustrative and separate from the live 12-account ARR and retention metrics. Growth depends on market, product fit, adoption, pricing, resources and execution. Pipeline is potential opportunity, not booked revenue or a guaranteed result.

Use the dashboard to decide

Review freshness, open the supporting account data, choose up to three priorities, assign an owner and deadline, then verify the outcome. Keep missing evidence visible.

Run a consistent operating rhythm

Daily triage and handoffs. Weekly quality and renewal reviews. Monthly revenue reconciliation. The complete PDF includes mock service targets, working templates and metric definitions.

SOP 01Daily dashboard review

Turn the dashboard into a short, owned action list for the day.

Owner
Customer Operations Lead
Trigger
Start of each mock service day and after the midday refresh.
Inputs
Account health, renewal dates, open escalations, missing evidence, journey tasks and sync timestamps.

Procedure

  1. Verify freshness. Read both the task timestamp and account timestamp. If the feed is a snapshot, or older than 24 hours, mark the review provisional and use SOP 08 before making a new performance claim.
  2. Review exposure. Inspect At Risk and Missing Health Score accounts. Check overdue and next 30 day renewals, blocked journey work and tasks with missing due dates or next actions.
  3. Open the evidence. Open each priority account. Compare health, adoption, open escalations, renewal timing and next action. Check the underlying task data before describing a blocker as resolved.
  4. Assign the decision. Select no more than three priorities. Record the accountable role, specific next action, due time in America/New_York, and business impact. Link or identify the existing DEMO task rather than creating a duplicate.
  5. Review budget and capacity. Use only matched budget and spend records for utilization. Flag missing amounts for investigation. Decide who can take the work; the current dashboard does not calculate staffing capacity.
  6. Close the review. Confirm that each priority has an owner and deadline. Carry unresolved items to the next review with the same task reference and a factual progress note.

Exceptions and escalation

An unscored account is unknown, not healthy. If evidence conflicts, retain the open action and route it to the Data Steward; do not resolve the conflict by averaging unrelated values.

Completion evidence

A dated review identifies up to three priorities, one accountable owner per priority, a deadline, the evidence checked and the next review time.

Dashboard connection

Affected dashboard views: account risk, renewal exposure, missing data and journey progress. The review itself does not automatically change a health score.

SOP 02Service request intake and triage

Create a complete, consistently classified service record without losing ownership during a handoff.

Owner
Service Analyst with Customer Success Manager oversight
Trigger
A new fictional request, complaint or service follow-up is introduced into the exercise.
Inputs
Account name, reported issue, observed impact, affected journey stage and relevant task history.

Procedure

  1. Check for an existing record. Search the demo account and task names for the same issue. Continue an existing case when appropriate. New records must begin DEMO | and stay within the isolated demo workspace.
  2. Classify impact. Apply the mock P1–P4 criteria on page 2. Choose severity from the customer impact, not the customer’s revenue or the loudness of the complaint. Record the reason for the decision.
  3. Capture the working record. Use the intake template on page 13. Record owner, severity, received time and expected next response in the task update or operating log. Use Next Action for the immediate action and owner; use Due for the next committed date.
  4. Set the journey stage. Use Onboarding, Adoption, Value Realization, Renewal or Expansion according to the affected outcome. Set status to Working on it. Use Stuck only when a named dependency prevents progress.
  5. Prepare acknowledgment. Draft a short acknowledgment with the understood impact, owner and next update time. In this demonstration, retain it as a mock draft; do not contact real people.
  6. Confirm the handoff. The receiving role explicitly accepts the case and next deadline. If acceptance is missing, the original owner remains accountable and alerts the Customer Operations Lead.

Exceptions and escalation

The current dashboard has no dedicated case severity or response-time fields. These are mock operating-log entries, not live SLA measurements. Never present the task due date as a measured first-response time.

Completion evidence

One unique request has an accountable owner, severity rationale, journey stage, working status, next action, due date and acknowledgment draft.

Dashboard connection

Supports journey progress and data completeness. Request volume and response SLA reporting require additional structured timestamps before they can be calculated.

SOP 03Escalation and service recovery

Contain the impact, establish a decision owner and keep the recovery plan visible.

Owner
Customer Operations Lead
Trigger
A P1 or P2 issue, unresolved high-impact complaint, missed update commitment or material renewal concern.
Inputs
Case record, customer impact, current owner, previous actions and verified account exposure.

Procedure

  1. Validate the escalation. Confirm the affected account, impact and current evidence. For P1, immediately notify the mock escalation lead in the exercise; follow the illustrative response cadence on page 2.
  2. Assign recovery roles. Name one incident lead and the specialist needed to resolve the issue. Define who owns customer communication and who can approve concessions. Do not assume those authorities are the same.
  3. Record containment. Document a reversible workaround where one exists, its limitations and the next decision point. Keep the case open if the workaround has not restored the agreed service outcome.
  4. Maintain the update rhythm. Use the service update template on page 13. State what is confirmed, what remains unknown, the next action and the next update time. Avoid unsupported resolution promises.
  5. Reconcile the account. Update the open escalation count once per unique case. Record a health review request when warranted; do not force a new health score merely because an escalation was created.
  6. Validate recovery. Check the resolution against the original impact and obtain a mock acceptance record. Close the escalation only after this evidence is recorded, then reconcile the account count and schedule a lessons review.

Exceptions and escalation

Commercial credits, contractual changes and sensitive complaints require the designated approval role. The demo may record a proposed decision but must never issue a real refund, promise or customer message.

Completion evidence

The recovery evidence, owner, communication history, residual risks and follow-up action are recorded. Open escalation counts agree with the operating log.

Dashboard connection

Connects open escalations to account health and renewal risk. A count is a number of open cases, not the number of comments or automated refreshes.

SOP 04Onboarding and first value

Move an account toward a demonstrable customer outcome with evidence for the time-to-value measure.

Owner
Customer Success Manager and Enablement Lead
Trigger
An active fictional account is in Onboarding or has no verified first-value outcome.
Inputs
Agreed use case, purchased capabilities, implementation milestones, training plan and success criteria.

Procedure

  1. Define first value. Write a concrete acceptance criterion for the account, such as a successful first operational report used in a mock review. Specify the simulated onboarding start date and evidence required.
  2. Plan milestones. Create or reuse journey tasks for configuration, data readiness, user training and acceptance. Assign owners and dates. Record fictional budgets and spend only when supported by the exercise.
  3. Deliver targeted enablement. Map training to the account’s roles and purchased capabilities. Track completion using the agreed assignment count; distinguish a completed video from demonstrated competence.
  4. Check adoption. Validate the reported adoption percentage against the exercise’s account-level definition. Keep the denominator consistent over time and document any change in eligible users or capabilities.
  5. Verify the first-value event. Record the acceptance evidence and completion date. Calculate calendar days from onboarding start to the accepted first-value date. Leave First Value blank while it has not been achieved.
  6. Transition the account. Review advancement to Adoption after first-value acceptance and the owner handoff are documented. An observed time-to-value result does not automatically change the stage; keep unresolved follow-ups open.

Exceptions and escalation

Do not replace a missing first-value result with zero days. If the original start date is unknown, preserve the gap and request evidence. The dashboard stores observed days but does not currently retain both event timestamps.

Completion evidence

First-value definition, start and acceptance dates, evidence, reported days, training status and the next-stage owner are recorded.

Dashboard connection

Time to value is the median of measured active accounts. The ≤30-day goal is illustrative. Adoption and training are separate reported percentages.

SOP 05Account health and adoption recovery

Explain the account risk and create a measurable recovery plan.

Owner
Customer Success Manager
Trigger
Health below 60, a watch score of 60–79, missing health evidence or a material adoption concern.
Inputs
Health score, adoption, training completion, open escalations, renewal date and latest next action.

Procedure

  1. Confirm the classification. Use the stored score: below 60 is At Risk; 60–79 is Watch; 80 or above is Healthy. Blank health remains Unscored. These are demonstration rules, not a predictive model.
  2. Investigate the reason. Review usage evidence, training gaps, unresolved service cases, sponsor engagement and upcoming renewal. Separate an observed issue from a hypothesis and name missing evidence.
  3. Set the recovery outcome. Choose a small, specific outcome and review date. For example, close two verified escalations and complete a role-based training milestone. Do not guarantee a renewal outcome.
  4. Assign the work. Reuse the linked Adoption or Value Realization task. Put the accountable role and next action in the working record. Escalate to SOP 03 if impact or timing requires leadership involvement.
  5. Review evidence. At the review date, compare completed work with the intended customer outcome. Update adoption, training or escalation counts only when their own evidence changes.
  6. Reassess health. The mock Customer Success Manager records a score rationale and review date. Close recovery work only after acceptance; record residual risk even if the account improves to Watch.

Exceptions and escalation

Do not automatically raise health because a task was completed. If health is missing, create an evidence-gathering action first. Unscored recurring revenue remains separate from known at-risk revenue.

Completion evidence

The account has a documented risk reason, accountable owner, recovery objective, review date, supporting task and evidence-based follow-up.

Dashboard connection

Supports the health/adoption chart, at-risk ARR and the priority account list. Training and adoption comparisons do not establish causation.

SOP 06Renewal and expansion review

Protect renewal readiness and qualify relevant expansion without confusing pipeline with committed revenue.

Owner
Customer Success Manager with Revenue Operations approval
Trigger
An account enters a renewal window, becomes overdue, lacks a renewal date or meets expansion-readiness criteria.
Inputs
Current ARR, renewal date, health, adoption, training, escalations, identified pipeline and customer outcome evidence.

Procedure

  1. Check timing. Review overdue, next 30, 31–60 and 61–90 day windows relative to the dashboard snapshot. Resolve missing dates before reporting full renewal coverage.
  2. Prepare the value review. Summarize agreed outcomes, adoption, service history, open objections and the responsible decision-maker role. Assign an action to each unresolved issue.
  3. Separate renewal and expansion. Protect the existing relationship while evaluating relevant additional capabilities. Identified pipeline remains an opportunity estimate until an explicit simulated commercial event is recorded.
  4. Apply readiness rules. For this demo, readiness requires health ≥80, adoption ≥75%, enablement ≥80% and no more than one measured escalation. A qualifying result is a review cue, not a forecast or automatic approval.
  5. Record the approved event. Revenue Operations checks the simulated event, effective date and amount. Update cumulative churn, contraction or expansion consistently with the fixed opening cohort; retain the event rationale and prior values.
  6. Reconcile the result. Confirm current ARR equals opening ARR minus churn minus contraction plus expansion. Recheck GRR and NRR, retain churned history, and update the renewal date only when supported by the event.

Exceptions and escalation

No new logos enter this Jan 1, 2026 cohort. Do not reset opening ARR or add the same expansion twice on retry. Missing financial inputs remain missing and reduce the reported calculation coverage.

Completion evidence

Each reviewed account has a renewal decision or next step, accountable owner, due date and supporting value evidence. Any financial change has one approved mock event and a reconciled value.

Dashboard connection

GRR excludes expansion; NRR includes it. Current ARR is annual recurring revenue, not cash collected, recognized revenue or pipeline.

SOP 07Data quality and metric reconciliation

Keep unknowns visible and ensure that the dashboard’s calculations can be traced to valid inputs.

Owner
Data Steward with Customer Operations Lead review
Trigger
Missing evidence, invalid values, conflicting inputs or a scheduled weekly quality review.
Inputs
Source data rows, field definitions, account detail, task gaps and the latest successful snapshot.

Procedure

  1. Find the gap. Open Source data and the task missing-data filter. Inspect account details for missing health, renewal, first value, training or survey evidence. Treat task completeness and account coverage separately.
  2. Validate definitions. Check that percentages remain 0–100, counts are nonnegative and positive survey responses do not exceed total responses. Verify renewal dates and the documented measurement period.
  3. Trace the evidence. Match values to the fictional working record. Correct a value only when the intended synthetic source is known. Preserve the previous value and correction reason in a task update or operating log.
  4. Check financial coverage. Use complete opening/churn/contraction/expansion sets for retention. Use paired budget and spend records for comparable utilization. Do not combine unrelated denominators.
  5. Preserve controlled gaps. Keep 2–4 deliberate gap tasks per board. Label each demonstration example in its next action or, when that field is intentionally blank, its name or mock operating log. Keep one active account with missing health, renewal or survey evidence. Never replace missing amounts with zero.
  6. Read back and reconcile. Verify the corrected Monday record, then use the approved sync. Confirm the public account detail and the affected metric agree with the corrected source.

Exceptions and escalation

If a source cannot be reconciled, leave the value missing and label the affected decision provisional. If the sync rejects invalid data, retain the last successful snapshot and use SOP 08.

Completion evidence

Every correction records the field, prior value, revised value, reason and reviewer role. Remaining gaps have owners. The relevant aggregate matches the underlying records.

Dashboard connection

CSAT uses total positive responses divided by total valid responses. Churned accounts stay in revenue retention but are excluded from active-account experience metrics.

SOP 08Demo automation and sync recovery

Keep the fictional dashboard active without duplicates, silent failures or changes to actual work.

Owner
Automation Operator
Trigger
A scheduled demo cycle or a failed, delayed or stale dashboard update.
Inputs
Current demo records, cycle markers, approved workflow execution result and task/account timestamps.

Procedure

  1. Verify the boundary. Use only the seven approved task boards and the private account board in the isolated GCom Pro AI Operations Demo Lab. Inspect schemas and current rows first. Writable names begin DEMO |; actual work is excluded.
  2. Check idempotency. Use America/New_York date and the morning, midday or afternoon slot in each changed Next Action: DEMO CYCLE YYYY-MM-DD slot. Inspect existing markers and recent activity. Retry failed syncs without repeating successful Monday writes.
  3. Advance task work. Advance 2–3 eligible tasks per board; keep 20–30 unarchived and at least six open. Resolve one missing field while retaining 2–4 labeled gap tasks. Create at most one unique task per board per local day; at 30, archive an older completed DEMO task first. Never reopen Done tasks.
  4. Update account evidence. Update 2–3 active accounts with small fictional changes. Preserve all 12 opening-cohort records, opening ARR and churned history; do not reactivate churned accounts. Retain one active account with missing evidence. Record an explicit simulated event for any financial movement.
  5. Verify the writes. Read back all changed fields, including creation defaults. Keep scores within 0–100, counts and amounts nonnegative, positive survey responses no greater than responses, and unknowns blank. Complete tasks only with required fields and mock acceptance evidence.
  6. Run the approved sync. Run the existing on-demand publication workflow once after all changes. If it is pending, inspect the same execution. Do not create a second run while the first outcome is unknown.
  7. Confirm publication. Verify both task and account sources report synced with recent timestamps. Confirm the expected Customer Success tasks and all 12 accounts in the readback. A successful run alone is insufficient. Retry only a failed sync; report unresolved failures accurately.

Exceptions and escalation

The existing schedule is weekdays at 9:10 a.m., 12:10 p.m. and 4:10 p.m. America/New_York. The browser polls every 60 seconds, so the demo is scheduled activity rather than a continuous stream of business events. Credentials remain server-held.

Completion evidence

One cycle is recorded once, changes are read back, and the public feed is verified or the exact failure remains visible. Routine data refreshes require no site deployment.

Dashboard connection

Shows actual sync freshness and recent record changes. This playbook does not enable new agents, customer notifications or SLA timers.

SOP 09Resolution quality and knowledge improvement

Close work consistently and convert repeat issues into useful training and operating improvements.

Owner
Service Analyst with Quality Reviewer approval
Trigger
An issue appears resolved, a first-value milestone is accepted or a recurring service problem is identified.
Inputs
Original impact, accepted success criterion, resolution evidence, customer draft history and linked tasks.

Procedure

  1. Verify the outcome. Test the resolution against the original need, not just the last technical action. Record mock customer acceptance or objective acceptance evidence. A workaround alone is not proof of full resolution.
  2. Complete the record. Confirm status, journey stage, due date, next action, budget and spend. Use a completed-action summary or dated follow-up as Next Action; leave unfinished work open.
  3. Review quality. Check accuracy, clarity, ownership, evidence and documentation. Any unresolved critical defect blocks closure and is returned to the owner with a specific correction.
  4. Close and reconcile. Mark the task Done only when the acceptance and required fields are present. Reconcile any associated open escalation once. Do not reopen completed demo tasks simply to generate activity.
  5. Capture learning. For a repeat issue, draft a knowledge article or training change with the symptom, audience, tested steps, limitations, owner and review date. Keep it as a mock draft until the reviewer role accepts it.
  6. Check improvement. At the weekly review, assess whether the change addressed the observed problem. Record the limitation when historical case data is unavailable; do not claim a measured reduction that the source cannot support.

Exceptions and escalation

A new recurrence gets a linked follow-up record while preserving completed history. A missing budget or spend value cannot be converted to zero solely to satisfy the closeout checklist.

Completion evidence

Accepted resolution evidence and the quality check are recorded. The task status and account escalation count agree. Any knowledge or training follow-up has an owner and review date.

Dashboard connection

Supports completion, escalation counts and enablement. Case-level SLA, quality scores and repeat-issue trends are proposed measures, not currently live dashboard metrics.

Follow a fictional account example

Meridian · Adoption recovery

A health score of 48, adoption of 42% and six escalations call for a documented recovery plan and service escalation review.

Explore SOP 05 →

Harbor · Renewal readiness

A health score of 57 and an October 30 renewal call for an owned value review and a dated action on unresolved objections.

Explore SOP 06 →

Orion · Missing evidence

Missing health and renewal information call for data-quality work. The account stays unscored until evidence is supplied.

Explore SOP 07 →

Examples use the October 4, 2026 seed. The live demo may show later updates.