Skip to main content

Client Support Process - Standard Operating Procedure

Document Type: Standard Operating Procedure (SOP) Version: 2.1 (Phase 1 — Gmail-first manual workflow) Last Updated: 2026-06-04 Workflow Owner: Support Process Owner (role) Review Schedule: Quarterly

Executive Summary​

Symphony Core handles inbound client support requests as a manual, Gmail-first process. Authorized clients email support@symphonycore.com; an operator acknowledges within one business day, triages, resolves (or hands off), and closes — all without dependence on platform features whose reliability is unverified.

This SOP is the keystone for the entire support process. It describes the state machine, the decisions at each transition, and which tool, template, and sub-SOP applies. Procedure-level "how do I do X" lives in linked modular SOPs so this document stays focused on flow and decisions.

The process is role-agnostic: every step describes what happens and which tool is used, not who runs it. Assignment of operators to shifts is a separate staffing decision and does not affect the SOP.

Purpose & Scope​

Purpose​

Provide a single, authoritative description of how a Symphony Core support request moves from inbound email to closure, using the canonical resources (Google Workspace, GHL, ClickUp, 1Password, Slack) without depending on platform features whose reliability is unverified. The SOP is written to be runnable by any operator with the access listed in § Prerequisites and the Support Operator Onboarding SOP.

Scope​

Includes

  • Inbound email intake at support@symphonycore.com
  • Sender authorization against the client registry
  • Acknowledgment, triage, in-progress work, handoff between operators, resolution, closure
  • Lightweight feedback loop (weekly review → KB / SOP / template updates)

Excludes

  • Phone, chat, or portal intake (not in scope at Phase 1)
  • Automation of any step — all checks and responses are manual
  • Per-tier SLA enforcement (single SLA for all Phase 1 clients per requirements plan D1)
  • 24/7 coverage beyond the emergency exception in § FR-17 Emergency Exception
  • GHL Conversations as the operational surface — deferred to Phase 2 (see GHL Support Email Binding SOP, marked deferred)

When to Use This SOP​

  • A new email arrives at support@symphonycore.com
  • An operator needs to decide what to do next on an in-flight request
  • A handoff is needed between operators
  • The weekly review is being run
  • A new operator is being onboarded

Process Overview​

State machine​

State table​

StateTriggerActionToolTemplateTime boundNext state
INBOUNDEmail arrives at support@Visible in support@ Gmail mailboxGmail (delegation)——AUTHORIZATION
AUTHORIZATIONNew inboundSender checked against client registryGHL Contacts—Within 4 business hoursREDIRECT or ACKNOWLEDGED
REDIRECTSender unauthorizedTemplated redirect sent; thread labeled support/redirectedGmailunauthorized-redirect-templateWithin 1 business dayCLOSED
ACKNOWLEDGEDSender authorizedTemplated acknowledgment sent, naming the request and setting expectationGmailacknowledgment-templateWithin 1 business day (client TZ)TRIAGE
TRIAGEAcknowledgedClassify request type; tag coverage + control; determine same-day-closable, multi-day, or route (Change Request / handoff)Gmail + GHL Contact context—Same business day as acknowledgmentIN-PROGRESS
IN-PROGRESSTriagedInvestigation, response, follow-up. ClickUp task opened if multi-day.Gmail thread + ClickUp task (multi-day only)—Per outcomeRESOLVED or HANDOFF
HANDOFFTrigger condition met (see Handoff SOP)Reassign in ClickUp; comment trigger + context; notify new operator (Slack); notify clientClickUp + Slack + Gmail(escalation-template — deferred)Within 1 business day of triggerIN-PROGRESS (new operator)
RESOLVEDSolution deliveredInternal status flipped to Resolved on ClickUp task (if any)ClickUp——CLOSURE-SENT
CLOSURE-SENTResolvedClosure email to client confirming completionGmailclosure-templateSame business day as resolutionCLOSED
CLOSEDClient confirms or 5 business days elapse without replyThread labeled support/closed; ClickUp task archivedGmail + ClickUp——(terminal)

Key information​

AttributeDetails
FrequencyPer inbound — typically 1–5 requests/week
DurationSame-business-day closure for ~70% of requests; multi-day for the rest
TriggerEmail arrival at support@symphonycore.com
OutputClosed request with documented resolution
DependenciesAll items in § Prerequisites

Roles & Responsibilities​

Roles in this SOP are functional positions, not specific humans. Any operator with the access listed in § Prerequisites can fill any role. Staffing is a separate, owner-driven decision and does not require revising this SOP.

Functional roles​

Support Operator

  • Monitors the support@ mailbox during their assigned shift
  • Performs the authorization check, sends acknowledgment, triages, investigates, sends responses, sends closure
  • Opens a ClickUp task when a request crosses into multi-day
  • Initiates handoff when a trigger condition is met

Escalation Owner

  • Receives handoffs that meet a trigger in § Handoff SOP (billing dispute, scope dispute, complaint, technical complexity beyond 2 hours of focused work)
  • Becomes the new Support Operator for that request

Support Process Owner

  • Maintains this SOP, the templates, and the modular SOPs it references
  • Runs the weekly review (see Weekly Review SOP)
  • Decides when a Phase 2 automation trigger has fired

RACI matrix (by state)​

State / ActivitySupport OperatorEscalation OwnerSupport Process Owner
Authorization checkR/AII
Acknowledgment sendR/AII
Triage decisionR/ACI
In-progress workR/ACI
Handoff initiationR/ACI
Handoff receiptIR/AI
Resolution + closureR/AC (if handed off)I
Weekly reviewCCR/A
Template / SOP updatesCCR/A

Legend: R = Responsible, A = Accountable, C = Consulted, I = Informed. Same person can hold R and A on a step.

Prerequisites​

Before performing this process, an operator must have:

  • Access & permissions

    • Gmail delegate access to support@symphonycore.com mailbox — set up per Gmail Delegation Setup SOP
    • Gmail "Send mail as" alias configured on the delegated account — set up per Gmail Send-as Alias Setup SOP
    • Read access to the GHL agency dashboard (for the authorization check)
    • Member of the SC Operations ClickUp space (for multi-day request tracking)
    • Member of the SC Slack workspace (for handoff notifications)

  • Required information

    • List of active clients (in GHL as Contact Type = Customer AND Customer Type = Current)
    • Knowledge of the canonical redirect phrase (§ Canonical phrases)
    • The five outbound email templates (see § Templates)

  • Onboarding completed

Process Steps​

Phase 1 — Intake & authorization​

Objective: Determine whether to engage with the inbound or send a templated redirect. Duration: Within 4 business hours of inbound arrival.

Step 1.1 — Triage the inbox​

Tool: Gmail (via delegate access to support@symphonycore.com)

Actions

  1. Check the support@ inbox at least twice per business day (morning + afternoon).
  2. For each unread thread, open and read in full before acting.
  3. If the thread is a reply to an existing in-flight request, route to its existing tracking record (see § Phase 3 — In-progress work).

Expected output: A clear sense of which threads are new requests vs. continuations.

Step 1.2 — Run the authorization check​

Tool: GHL Contacts Detailed procedure: Support Authorization Check SOP

Actions

  1. Take the sender's email address from the inbound thread.
  2. Search the GHL agency dashboard for a contact matching that email.
  3. Confirm the contact is Contact Type = Customer AND Customer Type = Current.

Decision point

  • If matched: proceed to Step 1.3 (Acknowledge).
  • If not matched: proceed to Step 1.4 (Redirect).
  • If ambiguous (e.g., personal address claiming to be a client employee): redirect anyway, AND apply Gmail label support/needs-verification so the Process Owner can resolve with the account representative.

Expected output: Clear authorize/redirect decision.

Step 1.3 — Send the acknowledgment​

Tool: Gmail (with "Send mail as" alias) Template: Support Acknowledgment Email Template

Actions

  1. Reply in the thread.
  2. Use the template; fill in the merge fields (first name, request summary phrase if helpful, expected response time).
  3. Apply Gmail label support/new → support/triaging.
  4. Sign as Symphony Core Support — never an individual name (substitutability rule per NFR-6).

Tip

Reply in thread — Gmail's auto-Re: prefix is correct. Don't start a new thread unless the inbound came via a different channel (call, Slack) and you're starting an email thread for it.

Common mistake

Sending from your own delegate address without the "Send mail as" alias. The client then sees From: operator@symphonycore.com on behalf of support@ and starts replying directly to your inbox. Always send as Symphony Core Support <support@symphonycore.com>.

Expected output: Acknowledgment in the client's inbox; thread state advanced to TRIAGE.

Step 1.4 — Send the unauthorized redirect​

Tool: Gmail (with "Send mail as" alias) Template: Support Unauthorized Redirect Email Template

Actions

  1. Reply in the thread using the template.
  2. Apply Gmail label support/redirected.
  3. Set up a Gmail filter so future emails from this sender skip the inbox and auto-label support/redirected (one-shot policy — don't keep responding).
  4. Sign as Symphony Core Team (generic, not "Support" — see template usage notes).

Edge case

If the sender claims to be an existing client but isn't in the registry (e.g., new employee at a client company), redirect anyway and apply support/needs-verification. The account representative will reconcile in GHL.

Expected output: Redirect sent; thread state advanced to CLOSED.

Phase 2 — Triage​

Objective: Decide whether the request closes today or becomes a multi-day track. Duration: Same business day as acknowledgment.

Step 2.1 — Assess request​

Tool: Gmail thread + GHL Contact context

Actions

  1. Read the full request; consult linked context (GHL contact notes, prior tickets if visible).
  2. Classify the request type — what the client is asking for:
    • Incident — something that worked is now broken, erroring, or down. Restore-first; check the FR-17 emergency exception.
    • Request — do a defined thing (a change, configuration, publish, or access grant). Access/provisioning requests require an identity check per the Support Authorization Check SOP before acting.
    • Question — information, guidance, or how-to; no system change.
    • Billing & Account — invoices, subscription, payment method, or plan changes.
  3. Tag the request on the two axes that decide how it's handled:
    • Coverage — in-scope (covered by the engagement) · billable (out-of-scope work) · warranty/rework (correcting an SC defect, no charge). A Request tagged billable is a Change Request — route it through the Change Request Intake SOP, don't resolve it here.
    • Control — SC-controlled · client-controlled · third-party-controlled. When the affected system is not SC-controlled, SC diagnoses and coordinates rather than fixing directly (see Step 3.1).
  4. Sort by predicted resolution effort:
    • Same-day closable (< 2 hours focused work, no third-party dependency)
    • Multi-day (requires investigation, vendor input, or > 2 hours of work)

Decision point

  • Billable Request (Change Request) → route to the Change Request Intake SOP; don't start work until scoped, approved, and prepaid.
  • Billing dispute, scope dispute, or complaint → handoff (see Handoff SOP).
  • Same-day closable → proceed to Phase 3 with the Gmail thread as the record.
  • Multi-day → open a ClickUp task (Step 2.2) before proceeding to Phase 3.

Step 2.2 — (Multi-day only) Open the ClickUp task​

Tool: ClickUp (SC Operations space → support list — see Rollout doc § #18)

Actions

  1. Title: support-<short-summary> (lowercase-hyphenated, ≤ 50 chars).
  2. Description: link to the Gmail thread URL; brief context (one paragraph); the resolution criteria.
  3. Status: IN PROGRESS.
  4. Assignee: yourself (the current Support Operator).
  5. Verbosity budget: keep description under 1,200 characters; link to SOPs/templates instead of inlining their content (per SC Contractor Task Quality Pre-work Standard).

Expected output: ClickUp task created; Gmail thread now mirrors its tracking record.

Phase 3 — In-progress work​

Objective: Investigate and resolve the request, or hand off if a trigger fires. Duration: Per the expected-response time set in the acknowledgment.

Step 3.1 — Investigate​

Tool: Gmail thread, GHL sub-account access, KB, prior closed threads (search Gmail for similar issues).

Actions

  1. Reproduce the issue or gather the missing information.
  2. If client clarification is needed, reply in thread and apply label support/waiting-client.
  3. If a third-party (vendor, DNS provider, etc.) is needed, contact them and record the inquiry in the Gmail thread or ClickUp comment.

Third-party-controlled systems

When the affected system is controlled by a party other than SC (a client's prior host, domain registrar, DNS provider, or another vendor), SC cannot resolve it directly. Run the diagnosis, hand the controlling party clear, forwardable findings (what's confirmed, what to check next), and coordinate to resolution. Tell the client plainly what SC can and cannot do here, so the expectation is "we'll diagnose and drive the fix," not "we'll fix it ourselves."

Decision point during investigation

  • If any Handoff trigger fires → execute the Handoff SOP. Skip the rest of this phase.
  • If the request resolves → proceed to Phase 4.

Step 3.2 — Respond / follow up​

Tool: Gmail thread (and ClickUp comments if multi-day)

Actions

  1. Send substantive responses as they're ready — don't batch silently.
  2. If response is delayed beyond the acknowledgment's expected-response time, send a status update before the deadline expires.
  3. Sign all client-facing messages as Symphony Core Support.

Common mistake

Going silent past the expected-response time. The client expectation is responsiveness, not perfect speed. A "we're still investigating, expect an answer by EOD tomorrow" message preserves trust; silence destroys it.

Phase 4 — Resolution & closure​

Objective: Confirm the fix, notify the client, close the loop. Duration: Same business day as resolution.

Step 4.1 — Verify resolution internally​

Tool: Whichever system the fix touches (GHL, WordPress, DNS, etc.)

Actions

  1. Confirm the fix is live and the root cause is addressed (not papered over).
  2. If a ClickUp task is open, set status to RESOLVED.

Step 4.2 — Send the closure email​

Tool: Gmail (with "Send mail as" alias) Template: Support Closure Email Template

Actions

  1. Reply in the thread using the closure template.
  2. Fill in the resolution summary (1–2 sentences; lead with what's now true).
  3. Include the optional {{VERIFICATION_URL}} block only if the resolution is verifiable via a URL.
  4. Apply label support/closed.

Expected output: Closure email sent; thread state CLOSURE-SENT.

Step 4.3 — Confirm or auto-close​

Tool: Gmail (passive monitoring)

Decision point

  • Client replies confirming: Close immediately. Archive the Gmail thread; archive the ClickUp task (if any) to the SC Operations archive list.
  • Client replies asking for revisions (within 5 business days): Re-open. Treat as a continuation of Phase 3.
  • 5 business days pass with no reply: Auto-close. Archive as above.

Quality Checkpoints​

Checkpoint 1 — After Phase 1 (intake & authorization)​

Verify

  • Authorization check ran for every new inbound (no thread sits in support/new for > 4 business hours).
  • Every authorized inbound has an acknowledgment in thread.
  • Every unauthorized inbound has a redirect + Gmail filter.

If criteria not met: clear the backlog before any new work; surface the lag at the next weekly review.

Checkpoint 2 — After Phase 3 (in-progress)​

Verify

  • Every multi-day request has a ClickUp task and the Gmail thread links to it.
  • No thread sits in support/waiting-client for > 5 business days without a nudge or auto-close.
  • All handoffs have a documented trigger + context per Handoff SOP.

If criteria not met: address the specific drift; this is a process problem, not a request-level problem.

Final Checkpoint — Before marking CLOSED​

Verify

  • Closure email sent.
  • Resolution summary captured in the closure email AND in the ClickUp task (if any).
  • Gmail thread labeled support/closed.
  • ClickUp task moved to COMPLETE status; will auto-archive per the SC Operations space maintenance cycle.

Troubleshooting​

Issue — Email arrives at support@ but doesn't show in the delegated mailbox​

Symptoms: A client confirms they sent to support@symphonycore.com, but the message isn't in the delegate's view of the mailbox.

Likely causes

Resolution

  1. Sign in to support@ directly (with the 1Password credentials) and check Inbox and Spam.
  2. If present in support@ but not visible to the delegate, re-run the delegation setup.

Issue — Outbound reply shows on behalf of support@​

Symptoms: Client receives reply with From: <operator>@symphonycore.com on behalf of support@symphonycore.com.

Root cause: "Send mail as" alias not configured on the delegate's account, so Gmail is using its default sender-on-behalf format.

Resolution: Run Gmail Send-as Alias Setup SOP on the delegate's account. This is the primary outbound mechanic, not an optional polish.

Issue — Client keeps emailing the old address​

Symptoms: A client who used to email a non-canonical address (team@sc.symphonycore.com, the old Google Group, or an individual operator) keeps doing so even after the migration.

Resolution: On the next reply touchpoint, append the canonical redirect phrase verbatim. Do not paraphrase — consistency matters when the same client emails twice.

Issue — Sender claims to be a client but isn't in GHL​

Symptoms: Email from a personal address asking for help, sender says they're at a client company.

Resolution:

  1. Send the redirect anyway (boundary).
  2. Apply Gmail label support/needs-verification.
  3. Flag in the next weekly review so the Process Owner can confirm with the account representative whether to add the sender to the GHL registry.

When to escalate​

Escalate to the Support Process Owner immediately if:

  • The inbox is backed up > 1 business day
  • A client expresses dissatisfaction in writing (not "I have a problem" — actual dissatisfaction with SC)
  • Process is blocked because a tool isn't working as documented
  • A request type doesn't fit any state in this SOP

Success Metrics​

KPIs​

MetricTargetMeasurementReview
Acknowledgment SLA100% within 1 business day (client TZ)Audit last 20 closed requestsMonthly
Closure rate≥ 95% of inbound reach CLOSED (rest are still IN-PROGRESS or HANDOFF)Audit all open threads weeklyWeekly
Mean time to resolution (same-day)≤ 4 business hoursGmail thread timestampsWeekly review
Mean time to resolution (multi-day)≤ 5 business daysClickUp created-to-completedMonthly
Recurring-issue conversionRecurring issues (≥ 2 same root in 30d) trigger a KB / template update within 30 days of the second occurrenceWeekly review logMonthly

Quality standards​

  • Accuracy: Resolutions address root cause, not symptom. If a workaround is shipped, the followup is in the closure email.
  • Completeness: Every closed thread has a resolution summary in the closure email AND (if multi-day) in the ClickUp task.
  • Timeliness: Acknowledgment SLA is non-negotiable; resolution SLA is best-effort with proactive status updates if delayed.
  • Brand consistency: No GHL / GoHighLevel in client-facing emails. Use "your account", "app.symphonycore.com", "the platform" per the white-label rules.

SLA summary​

  • Standard acknowledgment: Within 1 business day in client TZ.
  • Maximum response time: Within 2 business days for typical investigation; status update required if exceeded.
  • Emergency exception (FR-17): Same-day acknowledgment regardless of business hours when a client's live customer-facing surface is broken. See § FR-17 — Emergency Exception.

FR-17 — Emergency exception​

If an inbound describes the client's live customer-facing surface as broken (site down, payment broken, lead form not receiving, booking page failing), the request is treated as emergency:

  • Acknowledged same-day regardless of business hours, weekend, or holiday
  • Triage starts immediately upon acknowledgment
  • If the on-call operator cannot resolve within 2 hours, hand off per Handoff SOP (trigger: "emergency, can't resolve solo")
  • If the broken surface sits on a third-party-controlled system, follow the third-party path in Step 3.1: diagnose, hand findings to the controlling party, and coordinate — SC drives the fix rather than performing it

The client-facing definition of "emergency" is documented in how-to-get-support.md so clients know what qualifies.

Tools & Resources​

Required tools​

ToolPurposeAccess
Gmail (support@symphonycore.com)Canonical inbound + outboundDelegation — see Gmail Delegation Setup SOP
Gmail "Send mail as" aliasOutbound From: headerGmail Send-as Alias Setup SOP
GHL ContactsAuthorization checkRead access to the agency dashboard
ClickUp — SC Operations spaceMulti-day request trackingSpace member — see ClickUp SC Operations Space Setup SOP
SlackOut-of-band handoff notificationsSC Slack workspace member
1Passwordsupport@ credentialsShared infrastructure vault

Templates​

TemplateWhen
Support Acknowledgment Email TemplateEvery authorized inbound (Step 1.3)
Support Unauthorized Redirect Email TemplateEvery unauthorized inbound (Step 1.4)
Support Closure Email TemplateEvery resolved request (Step 4.2)
Support Escalation Email Template (deferred)Handoffs — until the template exists, write the message inline per Handoff SOP § Client-facing message
Change Confirmation Email TemplateWhen a support request escalates into a paid Change Request
Change Request Closure Email TemplateClosing a paid CR — instead of the generic closure

Canonical phrases​

Use these verbatim. Consistency matters when the same client encounters the same situation twice.

Redirect from non-canonical address (append at the end of the next reply):

For future requests, please write to support@symphonycore.com — that's our monitored support inbox and the fastest way to reach the team.

Modular procedure SOPs (the "how" for steps in this SOP)​

Reference docs​

Supporting standards​

Phase 2 / future state (deferred)​

Document History​

VersionDateAuthorChanges
2.22026-06-09Symphony Core Systems TeamReplaced the worked-example From-header address with a generic placeholder (operator@symphonycore.com) per the SOP Standard "Reference roles, not individuals" rule (issue #60).
2.12026-06-04Symphony Core Systems TeamAdded request-type taxonomy (Incident / Request / Question / Billing & Account) plus coverage and control tags to the Triage step; added third-party-controlled diagnose-and-coordinate guidance to Step 3.1 and FR-17.
2.02026-05-18Symphony Core Systems TeamFull rewrite for Phase 1: Gmail-first manual workflow, role-agnostic, state machine, modular sub-SOPs. Replaces Google Group / L1-L2 model.
1.22026-05-06Symphony Core Systems TeamAdded Known Configuration Issues (now resolved by Phase 1 design)
1.12026-02-24Symphony Core Systems TeamAdded Account Manager to RACI
1.02025-12-22Symphony Core Systems TeamInitial version

Next review​

Scheduled: 2026-08-18 (quarterly) Owner: Support Process Owner