How Should Website Bug Reports Be Prioritised? An Impact, Frequency and Urgency Matrix

Short answer: The priority of a website defect should not be decided simply because the person reporting it describes it as “urgent”. The record should first show which function is affected, how many users or transactions are involved, how often the issue recurs, why it is time-sensitive and whether a workable temporary solution exists. Reports that share the same root cause should be consolidated under one parent record, and priority should be reassessed when the impact grows.

At Kumsal Ajans, we distinguish critical reports that completely stop the system, sales or a core function; high-priority reports that cause a significant loss of functionality; and normal reports that do not stop the system. This classification is not necessarily permanent. An issue that initially appears to affect one user may prove to have a much wider operational impact as new information is added.

By the end of this guide, you will be able to create a bug-triage card that records issues consistently, consolidates related reports and gives a clear reason for any priority change.

Severity and Priority Are Not the Same

Severity describes the effect of a defect on the system and the business. Priority describes the order in which the team plans to address the work. The two are related, but they are not interchangeable.

A copy error may have low impact, for example, but it might need to be corrected quickly if it appears in the main message of an official campaign launching the next morning. Conversely, a technically severe defect may only occur under specific conditions and require information from an external service provider before work can continue. Its severity does not decrease while waiting; its workflow status changes to reflect the dependency.

GitLab's issue-triage tutorial recommends deciding and documenting criteria for issue type, severity and priority. The point here is not to copy a particular software tool. It is to help different team members assess similar reports against the same stated criteria.

What Information Should a Complete Bug Report Contain?

Statements such as “the page does not work” or “the form is broken” are rarely enough to begin a reliable investigation. In the Kumsal Ajans approach, a report should contain as many of the following details as possible:

1. Screen or operation: On which page, form, management action or integration does the problem occur?
2. Steps to reproduce: Which actions, and in what order, recreate the problem?
3. Expected result: What should normally happen?
4. Actual result: What did the user see, or which operation failed to complete?
5. Environment and version: Did it occur in production or testing, and on which device, browser, application or relevant version?
6. Supporting information and business impact: Is there a screenshot, error entry or log, and which task or business process is interrupted?

These details do more than help the technical team reproduce the issue. They show whether it is limited to one user, affects all mobile visitors or occurs in a shared third-party connection.

A screenshot on its own may not be sufficient. It shows the outcome, while reproduction steps and environment information explain how that outcome was reached. A log entry does not automatically make a report high priority either. Priority depends on the real effect of the finding on users and business operations.

How Should Impact Be Assessed?

Do not measure impact only by asking how many people have complained. Consider these questions together:

• Which user group is affected?
• Is a core function completely unavailable or only partially impaired?
• Are sales, applications, payments, membership or content operations interrupted?
• Is there a risk of data loss, incorrect data, unauthorised access or another security concern?
• Is the problem limited to one page, or does a shared component affect many pages?
• Can the user complete the task through a safe alternative route?

Atlassian's explanation of incident severity associates severity with business impact and notes that organisations need definitions suited to their own context. A contact form has one level of importance when it is a secondary channel and a different level when it is the only entry point for sales enquiries.

Reports involving security or data require separate consideration. The OWASP Risk Rating Methodology explains that likelihood and impact should be considered together for security risks and that business impact depends on organisational context. This does not mean converting every website defect into an OWASP security score. It means that a report involving confidentiality, data integrity or access should not remain in the same category as an ordinary visual defect without further review.

How Should Frequency Be Assessed?

Frequency is not simply the number of reports received. It describes the conditions under which a defect recurs and how consistently it can be reproduced:

• Does it happen on every attempt?
• Is it limited to a particular device, browser, user role or product group?
• Does it appear at a certain time or under heavy transaction load?
• Did it begin after a particular update?
• Are several different symptoms linked to the same root cause?

Ten users sending the same screenshot does not necessarily mean there are ten separate defects. Conversely, one report may reveal a repeatable failure that stops every payment transaction. Report count, reproducibility and affected scope therefore need to be read together.

In the Kumsal Ajans approach, reports connected to the same root cause are consolidated under one parent record. New submissions are added to it as extra findings, environment details and impact information rather than being investigated as unrelated work. This prevents duplicated effort and makes a growing impact visible in one place.

When Does Urgency Increase?

Urgency explains why a report needs action now. High impact does not always create the same time pressure. Urgency may increase when:

• sales or a core function has stopped completely;
• a release, campaign, application window or regulatory date is approaching;
• data is continuing to be lost or recorded incorrectly;
• a security or unauthorised-access risk is suspected;
• the problem is spreading to a wider user group;
• no workable temporary solution is available.

“A manager reported it” or “the client says it is very urgent” is not, by itself, an urgency criterion. The record should state the business consequence or time constraint that makes immediate action necessary.

The Impact × Frequency × Urgency Matrix

The following table is not a universal scoring standard or a service-time commitment. It is a practical framework for evaluating reports with the same questions.

The resulting classes can be interpreted as follows:

• Normal: Low or limited impact; the system continues operating and the user can complete the task.
• High: There is a significant loss of functionality, a defined user group cannot complete an operation, or the issue recurs consistently.
• Critical: The system, sales or a core function has stopped completely; there is an ongoing serious data or security risk; or there is no usable alternative for the organisation's primary transaction.

A defect does not have to score high in all three dimensions. A single critical impact, such as all sales transactions stopping, may justify a critical classification. Conversely, a minor alignment problem does not become critical simply because it appears frequently.

When Should Priority Be Reassessed?

A bug report is a living work record. Reassess it when any of the following changes occur:

• More users, pages, products, transactions or integrations are affected.
• New symptoms are linked to the same root cause.
• The issue is now reproducible on every attempt.
• The temporary solution no longer works or is not sustainable.
• Sales, applications or another core function has stopped completely.
• A data-loss, incorrect-data or security risk becomes apparent.
• The initial environment information proves incomplete or incorrect.
• A proposed fix causes a regression in another critical function.

Add a concise reason whenever the priority changes. “Three more reports received” is less useful than “The issue is no longer limited to one browser; all mobile users are now unable to complete the application process.” The second note explains the changing impact rather than merely counting messages.

How Do Workarounds and External Dependencies Affect Priority?

A workaround may let users continue the main task through a different route. This can support service continuity, but it does not remove the underlying defect or automatically close the record.

If a file-upload function fails for one format, for example, another safe and practical format might temporarily be accepted. That workaround is not sufficient if it is inaccessible to many users or introduces a risk of data loss.

When the issue depends on a hosting, email, payment, API or another external provider, the record may move into a waiting state. Waiting does not lower severity. The record should state which information is expected from whom, which function remains affected and whether a temporary solution exists.

Whether a request belongs to defect support, recurring maintenance or new development should also be decided separately from its priority. See our guide to free support and ongoing maintenance for that scope distinction.

Fictional Decision Scenario: A Form Defect Escalates from Normal to Critical

The following is not a real client case. It is a fictional decision scenario created to demonstrate the method.

One user reports that they cannot submit a proposal form from a mobile device. The initial record is marked normal because the problem appears limited to one device and the transaction can still be completed on desktop.

During investigation, additional reports connected to the same root cause are added to the parent record. The team learns that the defect is not limited to one device: it recurs in two current mobile browsers and prevents all mobile visitors from completing the final form step. Because the impact is now wider, the report moves to high priority.

It is then established that a campaign beginning that day directs all applications to this form and that no alternative application channel is visible. The sales-related core transaction is effectively stopped and no usable workaround exists, so the report is reclassified as critical.

The number of messages is not what drives the escalation. The decisive factors are the expanding user scope, repeatability, interruption of the primary business journey and immediate time pressure.

When Should the Record Be Closed After a Fix?

Changing the code is not, by itself, closure. At minimum, the team should:

• repeat the recorded reproduction steps;
• verify that the expected result now occurs;
• retest the affected device, browser, user role or integration;
• check that the change has not introduced a new problem in a related function;
• review whether a temporary solution should be removed or retained;
• inform the client of the outcome and checks completed.

Substantial changes to software, forms, account functions, databases or integrations may need validation in a controlled environment. Our guide to testing website changes in a test environment explains that release decision in more detail.

In the Kumsal Ajans approach, the record is closed after the necessary checks are complete and the client has been informed. Critical matters may also require explicit client approval. If the defect recurs, the record can be reopened with its existing context, or new findings connected to the same root cause can be added to the parent record.

A Reusable Bug-Triage Card

Use these fields to keep each issue in one clear record:

The card does not require every project to use identical software fields. Its purpose is to make the decision depend on visible impact and recurrence information rather than personal interpretation alone.

Conclusion

Effective bug prioritisation does not mean treating every message as urgent or simply working on the issue with the most complaints. It begins by improving the record, then considers impact, frequency, urgency, workarounds and external dependencies together.

Consolidate reports that share a root cause under one parent record. Reassess priority when new information expands the user or transaction impact. Explain a priority change through the altered business effect, not message count alone. After applying a fix, repeat the reproduction steps and inform the client before closing the record.