Orders and support

One order has two customer issues that need separate closure

Split the order into obligations, not messages. For each concern, define the customer’s question, the record that would settle it, the authorized owner, the action taken, the evidence of completion, and the customer-facing answer. A solved documentation request does not close a missing parcel, and a refund action does not answer a product-record question. Zendesk can expose request identities and audit events such as comment and field-change records, but those schemas do not impose this worksheet or prove that a summary matches the source message. Close each issue only on its own evidence and keep the other visibly assigned.

For: Authorized support leads at a research-only merchant handling one order that contains two distinct customer concerns, such as a documentation question and a fulfillment problem.

Updated 2026-10-01

Get help with store operations

Separate the obligations before choosing a status

Read the customer’s original messages in the authorized support system and identify each distinct question or requested outcome. Common pairs include a record or invoice request plus a delayed shipment, a refund question plus a return-instruction question, or a website-copy concern plus a payment status concern. Do not merge them because they share an order number or because one reply can mention both.

Write the obligation for each issue as something that can be checked: provide a specific document, confirm a carrier event, correct a store record, obtain a policy decision, or explain a payment state. Avoid vague labels such as help or look into it. If the customer did not ask for a second outcome, do not invent one; if staff discovered a separate defect, record it as an internal follow-up rather than pretending the customer raised it.

Keep research-only boundaries in the wording. A documentation issue must not become product-suitability advice, human-use guidance, or dosing. A fulfillment issue must not become a promise of delivery, refund, legal eligibility, or carrier liability. The matrix tracks customer service obligations; it does not expand them.

Give every issue its own evidence and owner

For each obligation, name the authoritative record: store order and fulfillment entries, carrier tracking, payment or refund records, authorized policy text, document request log, or the retained outgoing customer message. Mark which facts are reports, which are system records, and which are verified outcomes. A customer’s statement, an agent note, and a provider result are not interchangeable.

Assign one accountable owner per issue even when several teams contribute. The owner is the person authorized to decide that the obligation is met or to escalate the unresolved gap. If one agent answered the documentation question and fulfillment owns the parcel investigation, the case is not closed until both rows have their own completion evidence or explicit unresolved state.

Preserve source messages and use limited summaries in shared worksheets. If you use Zendesk, request creation can return an identity and status, while ticket audit events can preserve comment identity, author, content, visibility, and field changes with previous and new values. Those records can support traceability; they do not prove your paraphrase is authoritative, authorize disclosure, or require any merchant to adopt this matrix.

Control the reply so one answer does not imply the other

Draft customer communication issue by issue. State what was resolved, what record supports it, what remains open, who owns the next step, and when the team will update again. Do not use a resolved first issue to soften an unresolved second issue, and do not say the order is complete when only one obligation is complete.

Be careful with partial remedies. Sending a document may settle a copy request while saying nothing about shipment. Creating a return label may settle an instruction request while receipt and refund remain open. A refund record may settle money movement while a documentation or correction request still needs an answer.

Check visibility before saving notes or replies. Internal deliberation, restricted records, and customer-facing explanations serve different audiences. Do not paste customer correspondence into public forms, do not expose another order’s details, and do not place credentials, card data, private payment links, or identity documents in the matrix.

Close by exception and review repeated pairings

Adopt a closure rule: an order-level support task can close only when every listed obligation is either closed with its own evidence or transferred to an accepting owner with visible follow-up. An obligation the team still holds but cannot yet resolve keeps the order-level task open, with customer-facing wording that says so; the task is never closed while one of its obligations is being described as open. If any row lacks evidence, the case remains open by exception even if the ticket tool allows a solved status.

Record the closure basis for each row: the document sent and request reference, the carrier or fulfillment evidence, the payment or refund record, the policy decision and approver, or the unresolved question and next update. Where the available system cannot produce the expected record, write that limitation instead of declaring success.

If the same pair recurs, treat it as a workflow signal rather than a one-off: unclear handoff between support and fulfillment, document requests handled inside parcel tickets, or statuses that let one answer close the whole order. A scoped Prism checkout-review consultation can examine the storefront and support handoff you describe; confirm scope, responsibilities, fees, and terms before work. The consultation does not decide legal duties or provider outcomes.

Issue-by-obligation closure matrix

Use one matrix per order and one row set per distinct customer obligation. Enter internal references and limited summaries only. An order is not closed when one row is closed; every obligation needs evidence or an accepted transfer with visible follow-up, and a retained unresolved obligation keeps the case open with an owner.

Worksheet entries are not submitted by Prism’s worksheet and are not saved by the site. Use record types, availability, anonymized observations, or match/mismatch results. Do not enter government identifiers, customer names or addresses, customer messages, receipt-access links, card or bank details, passwords, or keys. Send sensitive documents only through the provider’s verified secure channel.

Issue-by-obligation closure matrix. The last column is for temporary notes.
Record or checkDecision it supportsYour finding and internal reference
Customer’s distinct questions from the source messages, separated without adding issues the customer did not raise.Defines each obligation so one answer cannot silently absorb another concern.
Authoritative record for each obligation: order/fulfillment, carrier, payment/refund, policy, document log, or retained outgoing message.Prevents reports, notes, and provider results from being treated as the same fact.
Issue owner and escalation authority for documentation, fulfillment, payment, policy, or internal defect follow-up.Assigns who may close or escalate each row independently of the shared order number.
First issue completion: action taken and completion evidence, including sent-document or correction references.Closes only that obligation and leaves the second issue visibly untouched.
Second issue completion: action taken and completion evidence, or the precise missing record blocking closure.Keeps a parcel, refund, return, or record question open until its own evidence exists.
Customer-facing wording per issue: resolved facts, open facts, owner, and next team update without promises outside merchant control.Avoids implying order completion from a partial answer.
Support-system trace such as request identity/status and relevant comment or field-change audit references, where Zendesk is used.Supports traceability while keeping source messages authoritative over summaries.
Final closure rule result: each row closed with evidence or transferred with acceptance and visible follow-up; any retained unresolved row keeps the task open with customer wording recorded.Determines whether the order-level support task may close or must remain assigned.

These are temporary notes. Leaving or reloading this page may clear them. Worksheet entries are not sent automatically. If you copy notes into the consultation message and submit the form, Prism receives them as part of your request.

Limits

  • Zendesk API and audit references describe possible records in Zendesk; they do not impose this worksheet, prove a merchant’s custom workflow, or make summaries superior to source messages.
  • A solved request does not establish delivery, refund completion, legal entitlement, product suitability, or provider outcomes.
  • This guide does not provide medical, human-use, dosing, treatment, or product-suitability guidance.
  • Keep full customer correspondence, payment data, credentials, identity documents, private links, and bank details out of worksheets and public forms.

Related guides

Sources

  • Zendesk: Requests API — checked 2026-10-01. Successful request creation returns HTTP 201 with a request identity and status, and the end-user view constrains available updates; a browser banner alone is not the confirmed API response.
  • Zendesk: Ticket Audit events reference — checked 2026-10-01. Audit events can preserve comment identity, author, content, visibility, and field changes with previous and new values; they do not prove a particular customer statement or authorize disclosure.
  • Prism solutions — checked 2026-09-21. Consultation scope, responsibilities, fees, and terms are confirmed before work; no support-workflow implementation, legal conclusion, or provider approval is implied.

Get help with store operations

Need help with the order, email or fulfillment step itself?

Get help with store operationsAll resources