Special Request Intake and Closeout

SOP: Special Request Intake and Closeout

Last Updated: 2026-05-18
Version: 1.0
Owner: CSM
Primary tool: TaskTracker Special Request Intake form

Purpose

Special requests must be captured, routed, fulfilled, and closed out through Client Success so requesters are never left guessing.

This SOP covers one-off requests from a client, a client employee, a third-party vendor working for the client, or an internal Tekton team member acting on behalf of the client.

Golden Rule

The assignee owns fulfillment. The CSM owns requester confidence.

A special request is not complete when the production work is done. It is complete when the requester has been updated or the CSM explicitly waives requester notification.

What Counts as a Special Request

Use this flow for any request that:

• Falls outside the normal recurring delivery checklist.
• Requires a specific one-off action.
• Comes from a client-side employee or third-party vendor.
• Changes a website, CRM, GBP, SEO page, ad, tracking setup, report, billing detail, or client-facing asset.
• Needs the requester to be told when the work is finished.

Do not use side-channel fulfillment for these requests. If it needs production work, it needs a TaskTracker task.

Roles and Ownership

CSM

The CSM owns the request lifecycle:

• Intake
• Scope clarification
• Task creation
• Routing to the correct fulfillment owner
• Client/requester expectations
• Final requester notification
• Completion closeout

Fulfillment Owner

The assigned specialist owns the work inside their lane:

• Website Specialist: website edits, QA, previews, live page notes
• SEO Specialist: content, technical SEO, AI/search platform work
• GoHighLevel Specialist: forms, automations, SMS/email, CRM pipeline work
• GBP Specialist: Google Business Profile and citation requests
• LSA Specialist: Local Services Ads requests
• Operations: billing, access, contract, scope, or escalation requests

The specialist moves the task to in_review when fulfillment is ready. The specialist does not mark a special request complete unless the CSM has waived closeout.

Intake Flow

1. Request comes in from client, client employee, third-party, or internal source.
2. CSM reviews for scope, urgency, and ownership.
3. CSM opens TaskTracker and uses Special Request Intake.
4. CSM fills in the required production details.
5. TaskTracker creates a normal task with special-request tags and closeout instructions.
6. Fulfillment owner completes the work and adds completion notes.
7. Fulfillment owner moves the task to in_review.
8. CSM reviews the completion notes, notifies the requester, logs the closeout, and marks the task complete.

TaskTracker Form Location

Use the internal TaskTracker form:

/special-requests/new

The form is for internal CSM use. Do not expose it directly to clients yet. Client-facing requests still come through normal communication channels, then the CSM converts the request into a production task.

Required Form Fields

Client and Requester

• Client
• Project
• Requester name
• Requester email
• Requester type
  • Client owner
  • Client employee
  • Third-party vendor
  • Internal Tekton team member
• Request source
  • Email
  • Phone call
  • Zoom
  • Text/SMS
  • Slack/other
  • Client portal
  • In-person
  • Other

Request Details

• Task title
• Original request, pasted in the requester’s wording
• CSM production summary
• Requested outcome
• Relevant URLs, files, or asset notes

Routing

• Workstream
• Assigned specialist
• Priority
• Due date
• Approval before work starts
• Approval before publish/live change
• Live-impact notes

Closeout

• Requester notification required
• Suggested requester update

Auto-Created Task Requirements

The task title should use:

[Special Request] [Client]: [Short request title]

The task must include these tags:

• special-request
• needs-csm-closeout
• from:csm
• workstream:[lane]
• requester:[type]

The task description must include:

• Original request
• CSM production summary
• Requested outcome
• Links/assets
• Approval requirements
• Closeout requirement
• Specialist completion-note checklist

Status Flow

Todo

The request has been created and assigned, but production work has not started.

In Progress

The assigned specialist is actively fulfilling the request.

In Review

Fulfillment is complete or ready for CSM review. The CSM must review the work and notify the requester if required.

Completed

The requester has been notified, or the CSM has explicitly waived notification.

Specialist Completion Notes

When fulfillment is ready, the specialist must add a comment like this before moving the task to in_review:

@Kyle fulfillment is complete and ready for requester update.

Client: [Client]
Request: [Request]
Completed work:
- [What changed]
- [Where it changed]
- [QA performed]

URL/evidence:
[URL or note]

Requester-facing summary:
"[Plain-English summary Kyle can send]"

Known caveats:
[None or list]

CSM Closeout Message Template

Hey [Name], quick update: we completed the [request type] request for [Client].

What changed:
- [Change 1]
- [Change 2]
- [QA or verification note]

You can review it here:
[URL]

Let me know if anything looks off on your end.

Website Request Example

Request: Client employee asks for a website service page update.

• CSM: Kyle
• Fulfillment owner: Jakob
• Workstream: Website
• Status path: todo to in_progress to in_review to completed
• Jakob completes the work, adds QA notes and the URL, then moves the task to in_review.
• Kyle notifies the requester and marks the task complete.

Escalation Rules

Escalate to Operations or Nick before assigning if the request:

• Changes scope or pricing.
• Requires rush handling that will interrupt scheduled production.
• Touches billing, contracts, DNS, analytics ownership, ads budget, or legal/compliance language.
• Comes from a third party who appears to be directing strategy instead of providing input.
• Conflicts with an approved SEO, website, GBP, GHL, or ads strategy.

What Not To Do

• Do not let specialists fulfill side-channel requests without a TaskTracker task.
• Do not mark the task complete just because the work is done.
• Do not let the requester go unnotified unless the CSM explicitly waives notification.
• Do not auto-send requester updates without CSM review.
• Do not accept third-party direction that changes strategy without CSM or Nick approval.

Phase 1 TaskTracker Behavior

Phase 1 uses a simple internal intake form that creates a normal TaskTracker task with the right description, assignee, due date, priority, and tags.

Phase 1 does not require new database fields. The process is enforced through task structure, tags, comments, and the in_review closeout step.

Future Automation

Later TaskTracker versions should add:

• Real requester fields on the task record.
• CSM owner field.
• Closeout status and timestamp.
• CSM notification when a special request enters in_review.
• A “mark requester notified” action.
• A completion guard that blocks special-request completion until requester notification is logged or waived.