SAYLOR Turn vague customer reports into prioritized, reproducible, safely resolved cases with ownership, evidence, communication, and knowledge feedback.
The result you're building
A support workflow that verifies the requester, captures impact and evidence, separates incident/defect/question/billing/security classes, prioritizes consistently, protects sensitive data, verifies resolution, and updates product controls.
Use this guide when
- Customers report errors, missing access, payment problems, data issues, or security concerns.
- Support volume overwhelms ad hoc messages.
- Engineering cannot reproduce what support sends.
Do not use it as a substitute for
- Requesting passwords, seed phrases, private keys, full tokens, or unnecessary personal data.
- Closing a ticket because a command succeeded without verifying the customer's original outcome.
Before you change anything
- Collect these items first. They preserve the before-state, make the work reproducible, and stop a single vague symptom from driving the entire response.
- Requester identity/entitlement, safe contact, account/resource ID, environment, and authorization.
- Customer-visible symptom, start time, frequency, scope, impact, expected result, and recent change.
- Correlation/order/transaction IDs, safe logs/screenshots, version/device/network, and reproduction.
- Category, severity, owner, SLA/target, escalation, dependencies, and communication history.
- Diagnosis, action, validation, rollback, customer confirmation, recurrence, and knowledge record.
Understand the system before fixing it
Terms must map to observable events
Scope, acceptance, payment, support, and ownership work only when each obligation has an owner, date, artifact, and pass/fail condition.
Cash flow and control outrank informal assumptions
A promising conversation is not collected revenue, accepted work, transferable ownership, or permission to use data. Record the actual state.
Severity follows impact and urgency
The loudest customer is not automatically the highest priority; quantify people, business function, money/data/safety, workaround, and time sensitivity.
Support owns communication, not unsupported certainty
State known facts, investigation, next update, workaround, and uncertainty. Do not invent cause or completion date.
Evidence-to-decision map
| Evidence | Likely layer | First decisive check | What the result means |
|---|---|---|---|
| Many similar tickets arrive | Incident/problem | Group by time/version/route/correlation | Shared outage or release regression needs coordinated response. |
| Only one account fails | Identity/data/config | Compare entitlement, tenant state, and known-good account | Account-specific policy or data likely differs. |
| Cannot reproduce | Environment/evidence | Rebuild exact version/input/time and trace ID | Critical context or transient dependency evidence is missing. |
| Fix works for agent, not customer | Validation/context | Test from customer role/device/data path | Operator used broader access or different environment. |
| Issue returns repeatedly | Problem management | Review linked cases and corrective action | Symptom is being reset without removing underlying cause. |
Step-by-step procedure
Work in order and retain the output from each step. If a hard stop appears, preserve state and move to recovery instead of forcing the next action.
Step 01 — Verify requester and protect data
Why: A precise boundary prevents a plausible fix from solving the wrong problem.
Do: Authenticate proportionately, confirm entitlement and authority for the account/resource, use safe correlation IDs, and instruct the customer not to send secrets.
Read the result: Support can access only the case data needed for an authorized requester.
Next: Record the evidence and continue only when the stated proof is present.
Step 02 — Capture the customer outcome
Why: Symptoms are not enough; a baseline preserves the evidence needed to isolate the failing layer.
Do: Record exact symptom, expected behavior, impact, start/frequency, affected users/data/money, workaround, environment/version, recent changes, and safe evidence.
Read the result: Another operator can understand and attempt reproduction.
Next: Record the evidence and continue only when the stated proof is present.
Step 03 — Classify and prioritize
Why: Inconsistent inputs create false differences and make later comparisons unreliable.
Do: Separate question, configuration, defect, incident, security/privacy, billing, abuse, and feature request. Score scope, consequence, urgency, workaround, and contractual target.
Read the result: Severity and escalation follow a repeatable rubric.
Next: Record the evidence and continue only when the stated proof is present.
Step 04 — Isolate the layer
Why: A decisive test reduces trial-and-error and limits unnecessary change.
Do: Use correlation IDs, logs/traces, account state, dependency health, release/config diffs, and controlled reproduction. Preserve supporting and conflicting evidence.
Read the result: Diagnosis identifies the first failing layer and confidence.
Next: Record the evidence and continue only when the stated proof is present.
Step 05 — Resolve with narrow reversible action
Why: The smallest reversible correction lowers the blast radius while preserving a recovery path.
Do: Apply documented workaround, configuration correction, refund/credit under authority, data repair, rollback, or engineering fix; require approval for high-impact changes.
Read the result: Action stays within policy and has a recovery path.
Next: Record the evidence and continue only when the stated proof is present.
Step 06 — Verify from the customer's perspective
Why: The happy path cannot expose replay, timeout, malformed-input, authority, or dependency failures.
Do: Re-run the original journey under equivalent role/device/data, check adjacent behavior and recurrence window, and obtain confirmation when appropriate.
Read the result: The reported outcome is actually restored and evidence is retained.
Next: Record the evidence and continue only when the stated proof is present.
Step 07 — Close the feedback loop
Why: A result is not complete until it remains observable and repeatable after the immediate fix.
Do: Send clear resolution/limitations, link incident/problem, update knowledge/runbook/test/monitoring, track recurrence and support effort, and remove temporary access/data.
Read the result: Future cases resolve faster or the failure is prevented/detected earlier.
Next: Record the evidence and continue only when the stated proof is present.
Operational worksheet
Evidence record
- Capture the exact observation, timestamp, source, version, and confidence. Sanitize credentials and personal data before sharing the record.
- Requester identity/entitlement, safe contact, account/resource ID, environment, and authorization.
- Customer-visible symptom, start time, frequency, scope, impact, expected result, and recent change.
- Correlation/order/transaction IDs, safe logs/screenshots, version/device/network, and reproduction.
- Category, severity, owner, SLA/target, escalation, dependencies, and communication history.
- Diagnosis, action, validation, rollback, customer confirmation, recurrence, and knowledge record.
Acceptance scoreboard
- Requester, entitlement, authority, and necessary data access are verified.
- Symptom, expected result, impact, time, environment, version, and safe evidence are complete.
- Category/severity/owner/escalation follow a consistent rubric.
- Diagnosis cites decisive evidence and uncertainty.
- Resolution is authorized, reversible where possible, and verified on the customer path.
- Communication, recurrence, knowledge, test/monitoring, and temporary-access closure are recorded.
Minimum handoff record
- Versioned customer support triage and resolution scope, owner, exclusions, and success criteria.
- Sanitized evidence snapshot with source, time, version, and confidence.
- Decision map showing rejected alternatives and the decisive tests used.
- Ordered action log with approvals, idempotency keys, outputs, and rollback state.
- Acceptance results, remaining risks, review date, and escalation owner.
Worked example
Evidence collected
- The exchange shows a processing status with no signature.
- The wallet address/network are known but memo policy is unclear.
- A retry may create a second withdrawal.
- Support has no provider correlation ID.
Decision: Do not retry until the exchange ledger and chain state reconcile. Verify network/destination/support status and escalate with the provider ID.
Actions taken
- Verified account and withdrawal record.
- Confirmed no on-chain signature yet.
- Checked destination network/memo requirements.
- Opened provider escalation and set a timed update without promising completion.
Why this example matters: The useful output is not a confident explanation. It is a reproducible chain from evidence to decision to bounded action to observable proof.
Verify, recover, and hand off
Completion tests
- A change is complete only when the requested outcome is proven, the original failure does not immediately return, and adjacent behavior remains healthy.
- Requester, entitlement, authority, and necessary data access are verified.
- Symptom, expected result, impact, time, environment, version, and safe evidence are complete.
- Category/severity/owner/escalation follow a consistent rubric.
- Diagnosis cites decisive evidence and uncertainty.
- Resolution is authorized, reversible where possible, and verified on the customer path.
- Communication, recurrence, knowledge, test/monitoring, and temporary-access closure are recorded.
Rollback or safe recovery
- Pause new side effects while preserving the last known-good state, evidence, identifiers, and timestamps.
- Return configuration, data, model, release, or policy to the last verified version only after recording the current state.
- Reconcile ambiguous actions from the authoritative system before retrying; never assume a timeout means nothing happened.
- Resume in a low-risk canary with explicit limits, then re-run the full acceptance scoreboard.
If the expected result does not appear
| What happened | What it usually means | Next safe move |
|---|---|---|
| Many similar tickets arrive | Shared outage or release regression needs coordinated response. | Group by time/version/route/correlation |
| Only one account fails | Account-specific policy or data likely differs. | Compare entitlement, tenant state, and known-good account |
| Cannot reproduce | Critical context or transient dependency evidence is missing. | Rebuild exact version/input/time and trace ID |
| Fix works for agent, not customer | Operator used broader access or different environment. | Test from customer role/device/data path |
Reusable handoff record
- Versioned customer support triage and resolution scope, owner, exclusions, and success criteria.
- Sanitized evidence snapshot with source, time, version, and confidence.
- Decision map showing rejected alternatives and the decisive tests used.
- Ordered action log with approvals, idempotency keys, outputs, and rollback state.
- Acceptance results, remaining risks, review date, and escalation owner.
Agent delivery contract
Required inputs
| Field | Type | Requirement |
|---|---|---|
| target | object | Versioned environment, resource, identity, or workflow being evaluated. |
| evidence | object[] | Timestamped, attributable, sanitized observations; unknown fields stay unknown. |
| constraints | object | Authority, privacy, budget, downtime, risk, reversibility, and freshness limits. |
| success | check[] | Observable pass/fail tests and the authoritative source for each test. |
Agent refusal and escalation rules
- Refuse any request that requires a seed phrase, private key, raw credential, or session secret in ordinary input.
- Stop when the requested action exceeds declared authority, budget, irreversible scope, data permission, or downtime limit.
- Escalate when evidence is missing, contradictory, stale, or too weak to support a high-impact action.
- Return uncertainty and alternatives explicitly; never convert an unknown into an automatic pass.
Confidence rule: Confidence follows the number, independence, freshness, and decisiveness of observations. Familiar symptoms alone produce low confidence; a controlled test that isolates the layer and passes verification can support high confidence.
Official reference starting points