A customer says the export is broken because it lacks a contract number. That field might already be expected, or the customer might need an extension to an otherwise working export. Establish the expectation and actual result before choosing a category.
This guide provides a decision record and example replies. It is a method for qualifying a need rather than automatically detecting defects. Customers describe a problem in their own words; the team is responsible for checking how the product behaves.
Establish the basis of the expected behaviour
Ask what the customer wanted to achieve, then inspect the function description, confirmed agreement or earlier result. These are different sources.
Documentation may describe another plan, and an earlier file may have come from another tool. Compare the same function and conditions rather than relying on a familiar button name. Identify which source actually applies to this account.
Missing wording in an instruction does not prove the behaviour is correct. If saving data fails to preserve the change, check the expected result of the complete step.
Equally, familiarity with another product does not establish a capability in this tool. Record the customer’s need separately from the basis used to assess current behaviour, so the comparison remains understandable.
For the export example, find its field description and confirm the selected file variant. Do not immediately promise to add the contract number. If documentation conflicts with configuration, retain both observations.
Explaining the discrepancy is part of verification rather than a reason to blame the customer. The response needs a checked interpretation of that particular function, not a guess about intent.
Distinguish a defect, configuration and additional capability
The following table organises an initial decision without replacing verification. “Needs checking” is an honest result when conditions are unknown.
Do not relabel it as a feature request merely to reduce the defect queue. The customer still needs an answer to the problem even if the initial category later changes. Keep the reason visible to the next person.
Scroll the table sideways to see all columns.
| Finding | Next verification |
|---|---|
| Described behaviour does not produce the expected result | Check a possible defect under the same conditions. |
| The function requires another setting or access | Verify the condition and explain the existing route. |
| The desired result exceeds current scope | Record the need as a proposed change. |
| Expectation or actual result is unclear | Keep qualification open until relevant facts are available. |
A plan restriction, missing permission and execution failure need different replies. Do not label them all as defects or recommend a higher plan without checking. If an existing function does solve the task, describe the applicable route.
A workaround should meet the actual need without creating another unsupported promise. Merely finding a button in another account does not establish availability here.
Collect only the facts needed for classification
Avoid immediately requesting a complete recording, every log and more screenshots. For an export, begin with the variant name, expected field and description of the received file.
If an earlier agreement matters, ask for the relevant passage. Do not collect a whole contract to verify one statement about a function. Use information already available in the conversation before asking again.
- Name the customer’s outcome.Record what should be possible after the step without imposing a particular solution.
- Check the expectation’s basis.Find the description or agreement for this function and the applicable conditions.
- Compare the result.Establish what happened after the same action and which facts remain unknown.
- Record a category and reason.Identify a defect, existing usage route, proposed change or further verification.
After confirming a defect, use the customer bug task template rather than expanding a complete report here. The qualification itself should remain concise. Another person needs to understand why this route was chosen and which information supported it. That short explanation makes a later category change assessable instead of appearing arbitrary.
Example after the first conversation: “Need: connect the export with a contract register. Observation: the selected file lacks the number; its field description has not yet been checked. Qualification: open, awaiting comparison with the scope of this variant.” This identifies the next verification without pretending to diagnose the cause. When another person confirms the description, add the basis and result of that check. Do not replace the earlier observation with a generic “resolved” label while the customer’s underlying need remains open. Record which uncertainty was answered rather than implying every part of the request was delivered.
Separate a regression and a new need in one message
In this fictional example, the export previously contained an agreed date column and now omits it. The customer also asks for a new contract-number column.
Investigate the first difference as a possible regression and the second as additional scope. One customer message does not require one category for every need it contains. Keep each requested outcome identifiable.
“It worked before” is relevant evidence but still calls for comparison. Check whether the file came from the same function and whether account conditions and settings match.
A previous unintended result also needs explanation. Do not promise to restore it before deciding the product’s intended behaviour. Describe what changed without treating every historical output as an accepted requirement.
When similar cases recur, consult the guide to repeat customer tickets. A contact count does not prove every request concerns the same defect.
Identical wording can describe different conditions. Keep useful connections without losing separate needs, and avoid treating a familiar complaint as already understood before checking the relevant result. Once the defect is confirmed, the number of different customers who hit it helps set the order of fixes, as explained in our guide to bug severity vs priority.
Explain the finding without promising delivery
Possible defect: “The description includes this field in the selected export, but the received file lacks it. We are passing that difference for investigation. We do not yet have a confirmed cause or correction date.” This reply requires an applicable source and an actual handover. Do not use it merely to imply action has occurred.
Existing capability: “This field is available in another export variant. Under the checked conditions, select that variant and compare the result.” Provide exact steps after confirming them. Avoid presenting instructions for another plan as a solution available in the customer’s account. If a condition still needs checking, name it rather than quietly omitting it.
New need: “The current export does not include a contract number. We recorded your need to connect the file with your own list and its use case. Receiving the proposal does not establish a decision to implement it.” If no further review takes place, do not imply the request is already scheduled. The wording should reflect the real process. If you want to set up such a review once many similar needs pile up, see our guide on turning customer requests into roadmap decisions.
Keep the classification reason beside the Meetlead task
In Meetlead Projects, keep a description, task type, comments and ticket link. Record the need, compared behaviour and classification reason. The team selects the type; it is not an automatic diagnosis.
Working in Projects requires an account, an installed application and appropriate permissions. Explain a proposed scope in the description rather than inventing an unsupported task category.
Moving from a support ticket to a task should preserve customer context. Changing the type after new findings should not lose it.
Avoid adding a delivery date nobody agreed. A queued task is not a confirmed product commitment. Keep an open verification question visible so the next person does not read a tentative classification as settled fact.
- The customer’s need is separate from the proposed solution.
- The expectation’s basis applies to the relevant conditions.
- Classification contains a concise reason or open question.
- Mixed needs were not reduced to one label.
- The reply does not turn receipt of a report into a delivery promise.
Completed work needs separate evidence of task completion. Initial classification does not establish a corrected result. Preserve a way for another person to verify the outcome before telling the customer it is resolved. The category helps route the work; the checked result is what supports a statement about success.
Questions about ambiguous reports
Does the customer calling it a bug decide the category? No. Record the problem and check the expected result.
Do not focus on correcting vocabulary at the expense of understanding the need. Qualification should follow facts rather than the strength of the customer’s wording.
Does missing documentation mean a feature request? Not automatically. Establish intended behaviour with the appropriate person and inspect available agreements.
A missing description is an information gap rather than a ready decision about scope. Keep the question open while the relevant basis is being checked.
Can the category change later? Yes, when new facts change the assessment. Keep a short reason and connected context.
Do not present a label change as completed work or confirmation of a deadline. Inform the next owner about the finding that explains the change.
Atlassian describes a feature request as a proposal for new capabilities or improvements. It does not establish automatic implementation: what a feature request means.
