Draft a support response with grounded next steps

A support draft should acknowledge the reported issue and offer steps supported by the product documentation. Keep diagnosis tentative until evidence establishes it.

Set the editorial constraints

Give the writing teammate a clear audience, purpose and approved facts. Include a short voice sample when tone matters, and state what the draft must not promise. Save a draft file for review rather than treating a generated message as published copy. A final human edit should verify names, dates, claims and links against the source material.

Inputs for this workflow: Sanitized customer question, known product version and approved troubleshooting notes.

Work through the task

1. Separate observed symptoms from possible causes.
2. Choose the smallest useful diagnostic step.

A brief you can adapt

Draft a reply with a short acknowledgement, two relevant checks and the exact information needed next. Do not promise a fix date or send the message.

The filenames above are examples. Replace them with your actual inputs and destination before submitting the task.

Review the deliverable

Check that the steps match the customer’s platform and avoid asking for tokens or private files unnecessarily.

Where this approach can fail

A plausible explanation is not a confirmed root cause.

For the related desktop setup, see company playbook.