How do I know whether something is a bug or a chargeable change request?

The test is what the specification says, not how convenient the behavior feels. If the system behaves differently from what was agreed in the specification, that is a defect and the vendor should fix it. If the system behaves as specified and you now want it to do more, or to do it a different way, that is a change request and needs to be assessed separately. The gray area is usually where the specification is silent, typically an exception nobody discussed at the time. The best way to handle that is not to argue about which category it falls into but to establish severity first: anything blocking business operations gets fixed now, anything that improves the experience goes into the next round, and the classification can be settled at leisure inside the issue list.

In an emergency there is no time for the full format. What is the minimum?

Three things cannot be dropped: one line describing the behavior, when it happened, and an identifier that locates it, such as your account or an order number. With those, an engineer can at least pull that moment out of the system records. What can wait is the tidy screenshot, the full reproduction steps, and the environment detail; adding them later costs nothing at the point where you are trying to stop the bleeding. Two things are worth avoiding however urgent it feels: do not write only "it is broken" without saying which page, and do not pack several behaviors into one message, because the hardest part of an emergency is working out which one to rescue first. One line now, full format ten minutes later, is the order that works.

I reported a problem, the vendor said it was fixed, and it came back. What now?

Record a recurrence as a new issue, and state explicitly that it is the same problem as the earlier one, referencing its number. Add two pieces of information: whether the conditions this time match the conditions last time, and whether anything else changed between the fix and the recurrence, such as a new release or a configuration change. Repeated recurrence usually means the original work addressed the symptom rather than the root cause, and at that point it is reasonable to ask the vendor to explain the underlying cause and how this fix differs, rather than simply reporting it as resolved again. If the same feature keeps failing, that is a quality signal, and the testing approach deserves review alongside it.

Bug Reports: What to Write for Your Vendor

Once a system is live, problems will appear. That part is not surprising. What genuinely consumes time on both sides is the quality of the bug reports: a message saying “the system is being weird today” dropped into a group chat leaves the engineer with nothing to do but ask questions back, and days can pass before anyone has reproduced the problem at all.

One boundary first: this article is about reporting after launch. Defect severity during the acceptance period, and how those levels tie to payment milestones, are covered in How Software Acceptance Works and are not repeated here. What follows breaks post-launch reporting into parts: telling a defect from a change request, what an effective report contains, how to rank severity quickly, and how to agree on channels and cadence.

First, separate the two: is this a defect or a change request?

This is the source of almost every argument, so it is worth settling up front.

A defect (bug) is behavior that differs from the agreed specification. An order total calculated incorrectly, a submit button that does nothing, a layout that breaks on a phone — these are defects, and fixing them falls to the vendor.

A change request is behavior that matches the specification but that you would now like to be different. “Could this field be made mandatory?” “We would like a button to export the report.” “Can this flow be simplified into two steps?” All reasonable ideas, none of them defects, and each needs its own assessment of effort and schedule.

How to decide. Ask yourself one question: was it agreed in advance how this should behave? If the specification described it and the system does not do it, that is a defect. If the specification never mentioned it, this is a new decision.

The most common misstep is reporting everything that feels awkward as a defect. Over time that buries the real defects, and it pushes the vendor into arguing classification line by line, so both sides spend their energy fighting instead of solving. The more practical habit is to describe the behavior and its impact accurately and let the classification be discussed in the issue record rather than settled mid-conversation. Whether the specification was clear enough in the first place can be checked against How to Write Software Requirements.

The six elements of a report that works

A report an engineer can act on immediately usually contains all of the following:

A one-line title. Describe the behavior, not the feeling. “Shipping fee does not update after selecting convenience-store pickup at checkout” rather than “checkout is broken.”
Reproduction steps. Which page you started from, what you clicked, what you entered — one step per line.
Expected result. What you believed you should see.
Actual result. What you actually saw, with any error message copied out word for word.
Environment. Which device, which browser or app version, which account, and when it happened.
A screenshot or recording. A picture beats a description, and a brief screen recording of the sequence is better still.

The two elements most often missing are the environment and the verbatim text of the actual result. A great many problems only occur in a particular browser, under an account with particular permissions, or against a particular state of the data. Without those clues, an engineer can try ten times in their own environment and never see it.

How to write reproduction steps that help

Reproduction steps are the heart of the report, because “reliably reproducible” is very close to “fixable.”

Three points make them useful. First, start from logging in rather than from halfway through, because the earlier actions may well be the trigger. Second, write down the actual data you used — the specific order number, the quantity you entered — since abstract descriptions drop the detail that matters. Third, state the frequency: every time, occasionally, or only once. Those three cases are handled completely differently.

Should you report something that happened once and worked fine on retry? Yes, but note honestly that you cannot reproduce it, and include the time it happened as precisely as you can. Timing is a valuable clue, because the engineer can go back through the system records for that moment. Do not stay quiet out of a worry that you mis-clicked. Intermittent events of this kind are often an early warning from a more serious problem.

How to rank severity so not everything is the most urgent

If every report is marked extremely urgent, there is no ranking at all. For day-to-day reporting after launch, three lines are enough:

Core business has stopped — customers cannot order, nobody can log in, displayed amounts are wrong. Use the agreed urgent channel immediately rather than leaving an entry in a system waiting to be noticed.
A major function is broken but a workaround exists — the report export fails, but the records can still be looked up one by one in the back office. Handle it this week, without interrupting work in progress.
Flaws and appearance issues that do not prevent the task — collect them and prioritize them at the next issue review.

Finer-grained levels, and how each level maps to acceptance and payment arrangements, belong to the acceptance stage; see How Software Acceptance Works.

The deciding factor is not how much it bothers you but how much the business is affected. A problem that stops a customer paying belongs at the top level even if it only appears in one browser. An ugly but harmless layout issue stays at the bottom however much it grates. Response and resolution times for each level should be written into the maintenance terms in advance; What Website Maintenance Actually Covers discusses that in more depth.

Reporting channels: what belongs in a system, what can go in chat

The most common failure is dumping every report into a messaging group. Messages scroll away, there is no status, nothing can be counted, the same problem gets raised three times by three people, and nobody knows whether it was ever fixed.

A division of labor that actually works looks like this: every issue goes into a ticketing system or a shared list, regardless of size; messaging is reserved for urgent alerts and quick clarification, and whatever gets clarified is written back into the ticket. The specific tool matters less than people think — a shared online spreadsheet will do — as long as every issue has a number, a status, and an owner. The list needs only five columns: number, one-line behavior, severity, current status, and owner. Design it more elaborately than that and nobody will still be filling it in a week later.

Agree on who may report, too. If everyone in the company can approach the engineers directly, the same thing gets reported several times and nobody has made a first judgment internally. The steadier arrangement is to funnel through one or two contacts who first check whether it is a settings problem and whether anyone else is seeing it. That step filters out a fair share of false alarms and means every report the vendor receives is worth acting on.

Agree on the cadence too. A workable arrangement is to batch non-urgent issues and review them together at a fixed time each week, with the meeting doing only three things: confirming severity for new issues, updating the status of issues in progress, and setting the order of the next batch. Urgent issues get a separate notification route and a named contact, plus an explicit definition of “urgent” and the hours that route covers, so that after-hours calls are not decided case by case. Avoid phoning the moment anything is spotted; that fragments the development rhythm and ends up slowing every issue down.

After the report: statuses, response times, and verification

The full life of an issue should run through these states: reported, confirmed reproducible, in progress, fixed and awaiting verification, closed. The state most often skipped is awaiting verification — the person who reported it should operate the system and confirm the fix, rather than the issue being closed because the vendor says it is done.

Verification involves two checks: that the original behavior is gone, and that nothing nearby was broken in the process. The second is routinely skipped, yet changing one thing and breaking another is not rare, especially where parts of a system are tightly connected. This is exactly where automated testing earns its keep; for the concepts, see What Automated Testing Is.

Common useless reports, and how to rewrite them

The recurring patterns are easy to fix:

“The system is slow” becomes “The order list page in the back office takes more than ten seconds to load after filtering by date range; other pages are normal; this was around ten this morning.”
“A customer says their order disappeared” becomes “An order placed on this date by this customer account does not appear in the order list in the member area, but is visible in the back office; screenshot attached.”
“This feature is hard to use” is not a defect report. Rewrite it as a suggestion and describe which step the user got stuck at and why.
“Everything is broken” should be split into separate issues, one behavior per report.

That last point matters more than it looks: one report, one thing. Put five behaviors in a single report and the status becomes untrackable — if three are fixed, is it fixed? Split apart, each one can be prioritized and closed on its own.

Settle the line between warranty and maintenance first

Before reporting anything, it is worth confirming which stage the system is in. Defect fixes inside the warranty period are usually covered by the original contract; outside it, they fall under maintenance. Change requests are assessed separately at any stage.

The boundaries between the three are best written down at signing: how long the warranty runs, what it covers (normally defect fixes, excluding new features and problems caused by environmental changes), and which services and response times the maintenance agreement includes. Without that, every report after launch carries an argument about classification along with it, which drains both sides.

A well-written report is really a way of saving your own time. A few extra minutes of clear description often buys back days of waiting, and it keeps the relationship focused on solving the problem rather than proving who was right.

A reporting process that holds up is usually agreed before a system goes live, not improvised after something breaks. To settle the report format, the urgent channel, and maintenance response times in one conversation, book a time with NETVANA to talk through your system. We discuss the support arrangement that fits the scale of your system and how it is actually used. Software services are quoted individually rather than sold as fixed packages; for what each service includes and delivers, see the software services overview.

Further reading: the contract model shapes how changes are counted, so see Fixed Price or Agile. Finishing the pre-launch checks reduces how much gets reported afterwards, covered in The Website Launch Checklist. For the support questions worth asking while choosing a vendor, see How to Choose a Software Development Company. And when the same area keeps failing there is usually a structural reason, explained in Technical Debt Explained for Business Owners.