Define the evidence the business needs

A bug report is a record that something in the system does not behave as agreed. A fix request, by contrast, usually describes a change to how the system ought to work. The distinction sounds minor, but it determines who pays, how quickly the work happens and whether it falls inside or outside the existing contract.

During a build project, a defect is anything that fails to meet the acceptance criteria you agreed during discovery. If the specification stated that an invoice PDF must include the company registration number and it does not, that is a defect the supplier should correct at no extra charge. If you later decide the PDF should also show a purchase order number that was never mentioned in the requirements, that is a change request, not a bug.

After go-live, the same logic applies but the reference point shifts to the support agreement or SLA. A defect in a delivered feature is typically covered under warranty or support. A new workflow, an additional field or a different permission model is a future piece of work.

The practical challenge for business owners and operations managers is that users rarely frame their feedback in contract-friendly language. Someone will report that "the search is broken" when what they mean is that the search does not filter by date—a filter that was never specified. Without a clear process, these reports create friction, delay genuine fixes and blur the line between defects and enhancements.

The lifecycle of a bug report

A managed bug report moves through defined stages: logged, triaged, assigned, fixed, verified and closed. Each stage should have an owner. Logging can be done by anyone who spots the issue, but triage—deciding whether it is genuinely a defect, how severe it is and when it should be addressed—needs someone who understands both the business process and the technical build. That is usually a product owner, operations manager or a business analyst, not a developer working in isolation.

Verification is the step most often skipped. A developer may mark a bug as fixed, but the person who reported it—or someone acting in a user-acceptance role—should confirm the fix works in the live or staging environment before the ticket is closed. Without this, the same defect can reappear in later releases.

What a useful bug report must contain

Vague reports waste time. A report that says "the portal is slow" gives the development team nothing to investigate. A useful report includes:

  • What the user expected to happen
  • What actually happened, including the exact wording of any error message
  • Where in the system the issue occurred (specific page, screen or workflow step)
  • Who experienced it (user role, account type, permission level)
  • When it was first noticed and whether it is reproducible every time or intermittent
  • Steps to reproduce — a numbered sequence someone else can follow to see the same result

You do not need a complicated tool to collect this information. A shared form, a structured email template or a simple ticketing system all work. The requirement is consistency: every report should follow the same format so nothing critical is left out.

Triage: severity versus impact

Not every defect deserves immediate attention. Two dimensions help prioritise: severity (how badly the system is broken) and impact (how many users or processes are affected).

A data-loss bug that affects a single admin user is severe but low-impact. A cosmetic formatting issue on the customer-facing dashboard is low-severity but high-impact. A payment-processing failure is both severe and high-impact, and should trigger an immediate response.

Agreeing a simple priority matrix with your supplier before issues arise prevents arguments later. A typical four-level scale—critical, high, medium, low—paired with target response and resolution times gives both sides a shared reference point. Those times should be documented in your support SLA and reviewed periodically.

Contractual boundaries: defect or change?

The most common source of dispute is the report that sits on the boundary. A CRM allows filtering contacts by region, but a user wants to filter by region and date simultaneously. If the original acceptance criteria only mentioned region, adding date filtering is a change, even if the user considers it an obvious omission.

To handle these fairly, agree a process in the contract or statement of work:

  • The supplier reviews the report against the written acceptance criteria
  • If it clearly fails a criterion, it is treated as a defect
  • If it falls outside the criteria, the supplier flags it as a potential change request with a brief explanation
  • The business owner decides whether to raise a formal change request, defer it or accept the limitation

This keeps the conversation focused on the documented agreement rather than subjective opinions about what "should" have been included.

Communication during the fix cycle

Silence erodes trust faster than a slow fix. Even if a resolution will take days, acknowledging the report within the SLA response window and providing a realistic timeline keeps stakeholders informed. A simple status update—"under investigation", "fix in testing", "awaiting verification"—prevents users from submitting duplicate reports or escalating unnecessarily.

Treating all reports as equal priority

When every ticket is marked urgent, nothing is. If operations staff learn that flagging something as critical gets faster attention, the label loses its meaning. Enforce the priority matrix consistently and challenge reports that do not justify their assigned level.

Accepting reports without reproduction steps

A developer who cannot reproduce a bug will either close the ticket as "cannot reproduce" or spend hours guessing. Requiring clear steps to reproduce does not guarantee every issue will be easy to find—intermittent bugs are genuinely difficult—but it eliminates the avoidable waste caused by incomplete information.

Not linking bugs to acceptance criteria

Every defect should reference the specific requirement or criterion it violates. If no such reference exists, that is a signal the report may actually be a change request. This discipline also highlights gaps in the original specification, which is useful input for future projects.

Skipping verification

Closing a bug immediately after a developer says it is fixed is a frequent cause of regressions. The person verifying should test against the original report's steps to reproduce, not just check that the system appears to work in general. If the fix introduced a new issue, that should be logged as a separate defect.

Allowing the backlog to grow without review

An unmanaged bug backlog becomes a dumping ground. Low-priority items can sit for months, accumulating until nobody is sure whether they are still relevant. Schedule a regular backlog review—monthly is often sufficient—to close items that are no longer reproducible, have been superseded by other changes or are no longer a business priority.

Questions to put to a supplier

Before a project starts or a support period begins, clarify the following points in writing:

  • What tool or format will be used to log and track defects?
  • Who is responsible for triage and priority assignment?
  • What are the defined severity levels and their associated response and resolution targets?
  • How is a defect distinguished from a change request, and what happens when the classification is disputed?
  • Who verifies that a fix is complete before the ticket is closed?
  • How often is the defect backlog reviewed, and what happens to long-standing low-priority items?
  • Is there a warranty period after project completion, and if so, what exactly does it cover?

Keep the result reproducible

These questions do not guarantee a smooth process, but the absence of clear answers almost guarantees a difficult one. Managing bug reports and fix requests is not primarily a technical exercise—it is a matter of agreed process, clear communication and disciplined record-keeping.