A bug report handoff template should let another person see the same problem and recognise when it has been fixed. “Rescheduling does not work” gives them neither a starting point nor a testable outcome. Below is our completed fictional example of a form whose Save button remains disabled after a new appointment is selected. You can use it in any task board, while keeping the customer’s report, your own test results and an unconfirmed explanation clearly separate.
Describe what happened before naming a cause
Start with what the customer was trying to do and the exact point where progress stopped. “After selecting tomorrow at 10:00, Save remains disabled” describes behaviour; “date validation is broken” already assigns a cause. Unless someone has examined the implementation, put the second statement under hypotheses. This gives the person investigating room to examine slot availability, form state or rescheduling rules instead of trying to confirm the first guess.
Label where each fact came from. One customer reported the problem, and the support operator made three separate attempts that all failed under the stated conditions. That does not establish that every customer or device is affected. The decision about whether to create a task belongs in turning a support ticket into a project task; this guide focuses on the report once that decision has been made.
Copy the completed ten-field bug report
The details below concern an invented form and demonstrate a reporting method, rather than describing a Meetlead incident. Replace “tomorrow” with an actual date and add the measured operating system and browser versions in your real task. Their numbers are deliberately unknown in this example: a missing fact should remain visible until it is checked.
Scroll the table sideways to see all columns.
| Field | Completed example | Why the recipient needs it |
|---|---|---|
| Title | Rescheduling: Save stays disabled after selecting tomorrow at 10:00. | Names the screen, action and visible symptom rather than a broad “booking problem”. |
| Customer goal | Move an existing appointment to tomorrow at 10:00 without creating a second booking. | The same record must change; a new booking would not be an equivalent outcome. |
| Starting conditions | A test booking exists, rescheduling is permitted and the target slot is available under the test rules. | If a condition is false, explain the actual restriction before treating it as a fault. |
| Environment | Android, Chrome, English page language, portrait screen, WiFi; version numbers still to collect. | Defines the verified observation, rather than every configuration that might be affected. |
| Steps | Open rescheduling → select tomorrow → select 10:00 → inspect Save. | Restore the same test booking before each attempt and record the actual calendar date. |
| Expected result | A valid change enables Save; one confirmation changes the appointment exactly once and shows the outcome. | Check the persisted booking, not just whether the button changes colour or becomes available. |
| Actual result | Save remains disabled; the change cannot be submitted and no message explains the block. | The mechanism stopping the submission has not yet been identified. |
| Frequency and impact | Three operator attempts, three failures; one known customer, impact on others unknown. | The customer cannot reschedule independently; data loss and a wider outage are not established. |
| Evidence and workaround | Masked screenshot after selecting the time; an authorised operator may reschedule manually after checking availability and customer agreement. | Verify the workaround exists and is permitted before offering it. |
| Acceptance and contact | Valid changes save once; prohibited changes explain why; name the task owner and support contact. | Support follows up after verification, without promising an unconfirmed release date. |
When information is missing, name what has not been checked: the Chrome version, desktop behaviour or a second account. Avoid “standard settings”, because the next person may interpret that phrase differently. The report does not need the entire conversation history; it needs the facts that change how this particular action is reproduced and accepted.
The Atlassian bug report template includes environment, reproduction steps, and expected versus actual results. The completed example and acceptance rules here are our proposal.
Ask someone else to reproduce the steps
Give the description to someone who was not part of the conversation and ask them to try it without spoken hints. They should begin from the stated initial conditions and note what they see after each step. If they need to ask how to open rescheduling or prepare the test booking, improve that exact part of the description. You are testing whether the instructions can be followed, rather than whether a colleague can guess what you intended.
Add the second result as a separate observation with its device, test date and success or failure. If saving works on a desktop, keep the original report and narrow the confirmed scope to the configurations tested. If the person cannot find the rescheduling option, investigate navigation separately through website usability testing. Difficulty finding an action and a valid action failing to save can call for different changes.
Attach the evidence needed for verification
A screenshot should show the selected appointment, button state and any message without the customer name, address, phone number or private service details. Remove those details permanently before attaching the image, rather than placing a decorative overlay in a preview. Name the file for the test stage and observation time. Its recipient should understand what it proves without opening the entire customer conversation.
If a short recording is needed, capture only the relevant sequence and use a test booking. Do not ask for the customer password, a full account recording or a network export merely because it might become useful. An authorised specialist should select additional logs to investigate a particular hypothesis. Keep a reference to the original evidence and arrange appropriate access instead of sending copies to people with no role in the task.
When requesting an image of a technical issue, use the guide: A screenshot for technical support: show the issue, hide private data.
Agree acceptance criteria before the fix starts
“The button works” is too narrow an acceptance criterion. For a valid change, check that saving is available, confirming changes the existing appointment exactly once, and reopening shows the new value. For a prohibited change, the form should explain the reason and leave the original appointment unchanged. Agree both scenarios before implementation so enabling a button alone cannot be mistaken for a complete fix.
Run acceptance in the reported environment and an additional variant selected by the implementer. A repeated press or page refresh should not create another record; inspect the persisted result instead of relying only on a success message. Separate the conditions necessary to accept this fix from ideas for redesigning the entire form. Set urgency using impact and the available workaround, with the approach in prioritising the support queue. Rate the technical impact and the urgency of the fix separately, following our guide to bug severity vs priority.
Before classifying a request as a bug, use the guide: Bug or feature request: classify what the customer needs.
Connect the task, owner and customer follow-up
Name the delivery owner in the task and the person responsible for the customer response in the ticket. Add links in both directions so a task status change does not break the connection to the original reporter. When another team must make a decision, include the specific question and required response instead of forwarding only a link. The wider process for transferring responsibility is covered in support ticket escalation.
With the report prepared, you can manually create a task in Meetlead Projects and link it to a ticket, conversation or relevant recording. An owner and status help track delivery, but the product does not automatically reproduce the bug or send it to Jira. You need an account, an active Projects app, and access under your plan and permissions. Once the fix is verified, support tells the customer the outcome and asks them to confirm it when their conditions differed.
Questions about handing over bugs
Can I close a task when I cannot reproduce the bug? That result does not establish that the problem is absent. Record the conditions of your attempt and compare them with the customer report. If access or an environment version is missing, name the gap and how you will investigate it rather than marking the report as false.
Do I need to identify the cause immediately? No: the report first needs to convey behaviour that someone can verify. Add a hypothesis separately with the observation supporting it, rather than putting it under actual results. A cause discovered later should not replace the original reproduction steps needed to accept the fix.
Does a workaround mean the issue is resolved? A manual change can unblock this customer while the form still needs a fix. Distinguish resolving the immediate support request from accepting the technical task. Before ending the conversation, agree who will watch for new cases and who will return with news of a lasting correction.
