Customer support · Taskending editorial team
How to write a support request: bug report template
A useful support request lets another person reproduce the problem and understand its impact. Explaining which action failed, under what conditions and with what result is more useful than simply writing “not working.”
Updated: · 3 min read
Combine the action and symptom in the title
Use “September filter returns an empty monthly report” instead of “Urgent bug.” Describe the observed behavior without guessing the fix. If several independent problems exist, create separate requests and explain their relationship. Resolving one issue should not accidentally close another. Keep passwords, access keys and customer lists out of titles and descriptions.
Number the reproduction steps
Identify the starting screen, selected options and actions in order. Separate the expected result from the actual result. If the issue is intermittent, say roughly how many attempts failed and when the workflow last succeeded. When support cannot reproduce it, differences in environment or data are useful investigation leads. Include a date, time zone or browser version when those details are relevant to the behavior.
A completed example
Example request: “September filter returns an empty sales report.” Steps: open the monthly report, select the September range and click Apply. Expected result: the three rows in the example dataset appear. Actual result: an empty-state message appears. Impact: the weekly review is waiting; the temporary workaround is to remove the filter and separate rows manually. This is a fictional illustration, not a real customer record or an assertion about a Taskending defect.
Separate impact from urgency
Explain which workflow is affected, whether people can continue working and whether a real deadline exists. “High priority” alone gives support little evidence. A sign-in failure affecting every user differs from a report alignment issue. The support team applies its own prioritization rules; the requester should provide known impact and workarounds without exaggeration. Update the request when circumstances change rather than duplicating it to attract attention.
Share screenshots and logs carefully
Remove personal details, session cookies, access keys and unrelated customer records before attaching evidence. A cropped image of the relevant area is often more useful than a full desktop screenshot. Taskending limits each attachment to 2 MB. If a larger file is necessary, use a link restricted to the intended recipients and verify that they can open it. Do not make a private document public merely to simplify sharing.
Keep the investigation in one request
Answer follow-up questions in the same conversation. Record the result of a new attempt and any changed conditions. Opening a second request through another channel can split the history. Verify the proposed fix in your workflow and describe the remaining failing step if it persists. Keep internal assessment separate from customer-facing messages; Taskending distinguishes internal notes from public replies.
Support request template
| Field | Information to provide |
|---|---|
| Title | [Observed symptom] during [action] |
| Reproduction | 1. Starting state 2. Action 3. Result |
| Expected / actual | [Expected behavior] / [Actual behavior] |
| Impact and workaround | [Affected work] / [Available alternative] |
| Environment and evidence | [Relevant version, time and sanitized attachment] |
Do not include passwords, access keys, session cookies or unrelated customer records.
Download template (.md) ↓Free. No registration needed. Use it in a text editor or an issue description.
Try it in your own workflow.
Create a company workspace and your first issue. Taskending is currently free.
Start for free