Convenience store customer service - complaint ticket handling and filing SOP: the intake form forces an "already promised" field, "the store says it handled it" is not a closable state, attribution categories share the five-class caliber used by review analysis, and every field the monthly review needs is captured once

You are a process consultant for convenience
store customer service. I am the service desk
supervisor; I need a filing-grade, auditable
"Complaint Ticket Handling and Filing SOP"
for phone agents and store managers. Output
the complete document on the frame below,
written for the people who execute it:
actions and fields only, no attitude pledges.

Document structure (output in this order):

1. Intake (required fields; a ticket missing
   any of them is not dispatched):
- Source channel: phone / platform-review
  conversion / store report / company channel
- Store, order ID or receipt number
- Customer's stated demand, verbatim: no
  rewriting, no summarizing
- Already promised: anything anyone promised
  the customer before intake (cashier, store
  manager, a previous call) - verbal promises
  count. This field sets the starting point:
  if a refund was promised, the work is how
  and when; with no promise, the work starts
  at verification. A promise must be honored,
  and honoring starts with being seen
- End the section with a form-field checklist

2. Completion (requesting missing items from
   the customer):
- Request what is missing: photos of the
  foreign object or damage, order number,
  receipt
- Request script: state the purpose - "for
  verification and the handling record" -
  never "we cannot process this without it";
  that line reads as a threat
- One request fails: log "customer did not
  provide," dispatch anyway; the ticket does
  not hang on it
- End with a completion-actions and wording
  table

3. Dispatch (the action ticket sent to the
   store):
- The action ticket states: deadline [store
  return deadline] and three mandatory
  returns - scene photos, outcome, record of
  contact with the customer
- Incomplete returns = action ticket not
  done; the ticket cannot move to closure
- What the agent can settle on the spot
  (refunds within [compensation authority])
  is not dispatched; it goes straight to
  section 4
- End with an action-ticket field table

4. Processing record (three parts; missing
   any one means not done):
- What was done: concrete actions and times
- Outcome: refund amount and destination
  (original payment route / cash /
  redelivery), replacement, or the wording
  of the reply sent
- Customer accepted: yes / no / unreachable
- End with a processing-record field table

5. Closure (enumerated states; no invented
   ones):
- Resolved - customer confirmed: only with a
  customer acceptance record
- Resolved - closed after two failed contact
  attempts: two contact records (time +
  method, spaced per [second-contact
  interval]) and a result notice sent to the
  customer's channel on file before closing
- Escalated - in progress: routed to the
  company desk; an in-flight state that does
  not count as closed or as a monthly
  resolution
- Returned for more information
- "The store says it handled it" is not a
  closable state: a store-reported outcome
  without customer acceptance or two
  unreachable records goes back for contact
  first, closure later
- End with a closure-state enumeration table

6. Filing fields (raw material for the
   monthly review):
- Attribution category: fixed enumeration
  sharing the five classes used by review
  analysis - picker error / handoff time /
  delivery / packaging and temperature /
  conduct - plus "other." Reviews are the
  complaints that never called; only a shared
  caliber lets the two tables be read
  together
- Where a refund is involved: amount and
  destination (original route / cash /
  redelivery)
- Three elapsed-time fields: intake to
  dispatch, dispatch to store return, return
  to closure
- End with a filing-field checklist

Document format: version / effective date /
scope / blanks for the deadline and authority
parameters; every action in the body carries
the three-part set "role + deadline + proof."

Prohibitions:
- No invented statutory or company deadlines -
  every time value stays in [brackets] for
  company policy to fill; the SOP prints no
  number of its own
- No "be warm and patient" or "service
  mindset" attitude language - actions and
  fields only
- No closure states outside the enumeration -
  "basically resolved" and "deemed closed"
  never appear
- No platform names or chain brand names
- No polite preamble - start with section 1

Why it is written this way

The "already promised" field sits in intake rather than in the processing section because unrecorded verbal promises are the first source of ticket rot: a cashier says "we'll refund you tomorrow," the customer calls the next day, the agent has no idea any promise exists, answers "we need to verify first," and the customer escalates on the spot - from where they stand, the company is now dodging its own word. The field sets the starting point: a ticket already promised a refund is worked as how and when; an unpromised ticket starts at verification. A promise must be honored, and honoring begins with being seen - this field is what makes the promise visible to the next person on the phone.

Closure is written as an enumerated set of states with "the store says it handled it" excluded, because that phrase is the largest single source of second complaints: the store says handled, the agent closes, nothing actually happened on the customer's side, and the next call arrives hotter than the first. Both "resolved" states demand objective proof - a customer acceptance record, or two unreachable attempts plus a result notice already sent - which turns closure from trusting the store's retelling into closing on evidence in hand. "Escalated - in progress" is an in-flight state that counts neither as closed nor as a monthly resolution, so month-end statistics cannot launder forwarded trouble into finished work.

Dispatch demands three returns from the store - photos, outcome, customer-contact record - because the store's cheapest reply is a one-line "handled." With the returns fixed and incomplete returns blocking closure, the filing fields in section 6 stop coming up empty every month. The attribution categories deliberately share the five classes used by review analysis so the two tables can be read as one: reviews are the complaints that never picked up the phone, and a shared caliber is what reveals the full distribution - picker error at four tenths of tickets and four tenths of reviews is a process problem; high in reviews while nobody calls means customers have stopped bothering to tell you, which is more dangerous than any complaint volume.

Every deadline stays bracketed for company policy to fill because self-invented numbers are the quietest way an SOP fails: the document prints a "7 days," staff remember only the SOP number, and when company policy actually says 3, the person in the wrong stays confident - "that's what the SOP says." The same logic bans "warm and patient": attitude requirements have no acceptance test, and in an SOP they only dilute the action clauses. The SOP governs actions and fields; attitude belongs to scripts and training.

Variables