How to decide which website reports get an investigation

A website can collect more reports in one week than a small team can investigate in one month. A monthly investigation limit is not a tooling failure. It is a normal constraint that makes one decision important: which stored reports earn an investigation first. A short written rule beats an inbox sorted by whoever wrote most recently.

This article is about the spending decision. For ranking a report by severity first, read how to triage user-reported website issues.

Ask what an investigation would change

The purpose of a bounded investigation is to turn a report into a source-backed next step: a conclusion, evidence citations, the unknown facts, a recommended action, and a draft response. Before spending a monthly investigation, ask what a result would change.

Investigate when a result would:

• Point you to the source area before you open the code.
• Decide between a fix and a product explanation.
• Give you a plain-language draft you can review and send yourself.
• Record, honestly, that the cause is still unknown.

Do not spend an investigation when the next step is already decided. If you will rebuild the page this week regardless, or the report is a product question you must answer yourself, store the report and act. The report is not lost. It stays stored and reviewable.

Use the attached evidence to rank

Two reports can describe the same severity and still differ in readiness. A report with a clear visitor action, a bounded console error, failed request metadata, or a visitor-approved screenshot gives an investigation more to connect to the source. A report that says only that something is broken gives it less.

This does not mean thin reports never earn an investigation. It means that when the limit forces a choice, the report with more attached evidence usually returns a more useful result.

One nuance matters. A conclusion labeled likely or confirmed needs repository evidence, and a confirmed conclusion also needs direct visitor-browser evidence. A report with no browser evidence can still end in a likely conclusion backed by source citations, but not in a confirmed one. If a confirmed answer is what you need, give the credit to a report that carries browser evidence. The guide to what browser evidence helps explains each category and its limits.

Separate a problem from a suggestion

A problem report says the website did not do its normal job. A suggestion says the current result works but a different result could help. Both are valid reports, and both can be investigated, but they usually need different first steps.

A problem usually needs a cause. A suggestion usually needs a product decision. Investigating a suggestion before you have decided whether you want the change can spend a monthly investigation on a question you will answer with a decision, not with source evidence. Decide first, then let an investigation find where the change belongs.

Store the rest, do not discard it

A report that arrives when the account has no monthly investigations left is not thrown away. It remains stored without an investigation, next to the reports that were investigated. That stored record still has value:

• Several similar stored reports are a signal about frequency, even before any investigation starts.
• A stored report keeps its optional unverified contact email, so you can follow up manually if you choose to.
• The raw text and safe browser evidence stay available for later review.

Revisit the stored list when the month resets. Some stored reports will no longer matter because the page changed. That is fine. Deleting or ignoring the queue is the only real loss.

Spend one investigation at a time per website

An account has one active investigation at a time on the Free plan, and Pro permits one active investigation for each registered website. The limit means order matters more than speed. Starting the right report first beats starting three reports in a rush.

Keep the queue short and honest. If a stored report no longer matters, record that decision and archive the report instead of leaving it in a backlog nobody reads.

When a reinvestigation is worth a credit

A reinvestigation of the same report consumes one monthly investigation again. It earns that second credit in a small number of cases:

• The website deployed a new revision after the first investigation, so the old result may describe code that no longer runs.
• The first investigation ended with an unknown cause, and your own checks produced a new fact worth checking against the source.
• You made a change based on the recommended action and need the result reviewed against the current source before you close the report.

Do not reinvestigate merely because the first conclusion was unwelcome. Re-read the evidence citations and the unknown facts first. The guide to reviewing an investigation result shows how to check whether a second run can add anything.

Write the rule down and recheck it

Decide the rule while the queue is small. A workable starting rule:

1. One active core flow is blocked. Investigate now.
2. A blocked flow has a workaround. Investigate this week.
3. A suggestion. Decide the product question first, then investigate.
4. A cosmetic issue or a question. Store and batch.

Recheck the rule once a month against the reports you investigated and the results you received. If investigations keep ending in unknown causes for one kind of report, change the rule for that kind instead of spending more credits on it.

How IssueProbe fits this decision

IssueProbe stores every report. Each eligible report receives one isolated, bounded, read-only investigation, and a report that arrives without quota stays stored without losing its content. The Free plan permits three investigations each month, and the Pro plan permits twenty, so the spending rule above stays relevant at both sizes. The result separates the conclusion, the evidence citations, the unknown facts, a recommended action, and a draft response, and a human reviews it before anything is sent.

Compare the exact limits on the pricing page, see the structure in the example report, and improve the raw material for future reports with the guide to writing a useful problem report.