A customer rings to say they can't pay. You try the checkout yourself and something odd happens. Or maybe a form that worked yesterday suddenly stops sending. In that moment, most business owners do the same thing. They fire off a quick message that says something like, “The website is broken.”
That reaction is completely understandable. It's also the message that usually creates the longest path to a fix.
Reporting a bug isn't a technical exam. It's a communication job. The better you describe what happened, where it happened, and what you expected instead, the faster your web agency can stop guessing and start fixing. Most advice online is written for developers, which leaves a gap for business owners. That matters because 67% of UK SMEs lack in-house IT support, so many people reporting problems aren't technical in the first place, as noted in this bug reporting teaching resource .
If your website is part of your daily sales, bookings, or enquiries, good reporting saves time at both ends. It also makes ongoing website maintenance and support far smoother, because the issue arrives with enough context to act on immediately.
From 'It's Broken' to a Fast Fix
A useful bug report starts with one shift in mindset. Don't think like “someone who found a fault.” Think like “someone handing over clear directions.”
When a developer receives “the site is broken”, they still have to ask a string of follow-up questions. Which page? Which device? Can you repeat it? Is everyone affected or just you? Is it stopping customers from buying, or is it a layout issue on one screen size? That back-and-forth often takes longer than the fix itself.
What a developer needs from you
You don't need technical terms. You need observations.
A strong report answers ordinary business questions in plain English:
- Where did it happen. The exact page or step, not just “on the website”.
- What were you trying to do. Book an appointment, submit a form, add to basket, log in.
- What happened instead. Error message, blank page, spinning loader, wrong total, missing button.
- How serious it is. Mild annoyance, blocked lead, or lost sale.
A bug report works best when it reads like a clear witness statement, not a frustrated verdict.
Why vague messages slow everything down
Non-technical clients often worry they'll “say the wrong thing”, so they keep it short. Ironically, that creates more work for everyone.
“The booking page isn't working” could mean the calendar won't load, the form won't submit, the payment step fails, or the confirmation email never arrives. Those are four different problems. A developer can't responsibly jump to a fix without narrowing it down first.
Good reporting a bug doesn't require expertise. It requires detail. Once you see it that way, the process becomes simpler and less stressful.
Gathering Your Clues Like a Detective
Before you send an email or WhatsApp message, collect the small details that tell the story. These details are the difference between “something seems wrong” and “here's exactly how to reproduce it.”
A 2026 survey of UK development teams found that bug reports with precise reproduction steps, environment details, and expected versus actual behaviour achieved 40% faster resolution times than vague submissions. That same guidance also highlights the value of UK-specific context, such as postcode formatting or a payment gateway used on the site.
If you already keep an eye on website performance monitoring , this will feel familiar. You're looking for signals, not trying to diagnose the code yourself.
Start with the exact location
“On the contact page” is helpful. The full page link is better.
If the issue happened on a specific product, service, booking, or checkout step, include that exact URL. Developers often manage multiple pages with similar templates. The direct page link removes one layer of guesswork immediately.
Also mention whether you were logged in, using a test account, or browsing as a normal visitor. Some bugs only appear for one type of user.
Write down the steps you took
This is the most useful habit in the whole process. Retrace your actions and list them in order.
For example:
- Go to the cart page
- Click Checkout
- Enter billing details
- Add a UK postcode
- Click Pay Now
- Receive an error page
That sequence matters because developers need to reproduce the bug before they can fix it confidently. If they can make it happen on demand, they can usually isolate the cause much faster.
Practical rule: If you can repeat the issue, write the steps exactly as you performed them, even if they feel obvious.
Note your setup
A bug can behave differently depending on the device, browser, or operating system.
You don't need a technical inventory. Usually these basics are enough:
- Device. iPhone, Windows laptop, iPad, Android phone
- Browser. Chrome, Safari, Firefox, Edge
- Connection or context. Home broadband, mobile data, office Wi-Fi if relevant
- Locale details. UK postcode, UK payment method, or anything that seems tied to local formatting
This matters because some issues only appear in one environment. A postcode validation bug, for example, may show up only when a real UK format is entered.
Compare what you expected with what happened
This sounds simple because it is.
Write one line for each:
- Expected. “After clicking Pay Now, I expected to go to the payment provider.”
- Actual. “The page refreshed and showed an error.”
That comparison tells the developer what the system should have done from a business perspective. It's often clearer than a technical explanation.
Capturing the Evidence with Screenshots and Videos
When clients ask what single thing speeds up a bug fix the most, the answer is usually simple. Send a picture.
A screenshot or short screen recording shows the problem exactly as you saw it. It removes the risk that your description and the developer's interpretation drift apart. According to the earlier-cited Disbug guidance, adding relevant visual evidence can boost the successful fix rate by up to 25%.
What makes a screenshot useful
A useful screenshot captures context, not just the obvious error.
Try to include:
- The full browser window so the page, menu, and browser area are visible
- The page address if possible so the location is clear
- The error message or wrong behaviour without cropping too tightly
- The date or time if relevant for issues that come and go
A tiny cropped image of one broken button often creates more questions than answers. A full-screen image gives the developer layout context, device clues, and surrounding content.
When video is better
Use a short screen recording when the bug only appears after several actions. Checkout problems, filters that reset unexpectedly, forms that fail after submission, and menus that disappear on mobile are all easier to understand on video.
Keep it brief. Start just before the problem appears. Narration helps if you're comfortable with it, but it isn't required.
If you're interested in the broader support side of visual evidence, this piece on the impact of missing product screenshots makes the same point from a ticket-handling perspective. Missing visuals slow understanding.
Show what you clicked, what changed, and the exact moment it went wrong.
Don't worry about perfection
The goal isn't to make a polished demo. The goal is to show reality.
A basic screenshot from Windows Snipping Tool, macOS Screenshot, iPhone Screen Recording, or Android's built-in capture is usually enough. If file sizes are large, send the image first and say you also have a recording available.
For website owners who manage their own content, the same habit improves communication in other areas too, especially when discussing layout and sizing images for websites .
Classifying the Bug's Business Impact
Not every bug deserves the same response. A typo on an old blog post isn't in the same category as a checkout failure on your busiest product page.
Business impact matters more here than technical detail. If you tell your web agency what the issue is costing you in practical terms, they can triage properly instead of treating every message as equally urgent.
A vague report like “site broken” can cause resolution delays of up to 50%, and classifying severity by business impact helps developers focus on what matters most, according to bug reporting guidance used in software engineering education . That same source gives a useful example of a Critical issue being one that causes revenue loss over £500 per day.
A simple way to describe severity
Use plain business language. Ask yourself one question: what is this stopping people from doing?
Here's a straightforward framework.
| Severity Level | Description | Business Impact Example |
|---|---|---|
| Critical | Core website function has failed | Customers can't pay, website is down, bookings can't be submitted |
| High | Major function works badly or unreliably | Contact form fails for some users, checkout errors on one browser |
| Medium | Problem affects experience but has a workaround | Image gallery breaks on mobile, one page layout is distorted |
| Low | Cosmetic or minor content issue | Typo, spacing issue, outdated staff bio, minor button alignment problem |
What to include with the severity
Don't just label it “urgent.” Explain why.
Useful examples include:
- Revenue impact. Customers can't complete payment
- Lead impact. Enquiry forms aren't sending
- Operational impact. Staff can't log in to update orders
- Reputation impact. Key service page looks broken on mobile
This is far more actionable than saying something is “really important”. The developer can line that up against other open work and respond sensibly.
Business-first test: If the bug stops money, leads, or operations, say that plainly in the report.
Urgent doesn't mean dramatic
Some clients feel awkward marking a problem as critical. Others mark everything as urgent because it feels safer. Both habits create confusion.
A balanced report helps everyone. If the issue is costing sales, say so directly. If it's cosmetic, say that too. Clear severity improves scheduling, support planning, and discussions around the ongoing cost for website maintenance .
Writing the Perfect Bug Report (Template Included)
Once you've gathered the clues, don't scatter them across five messages. Put everything into one report. One issue, one report, one clear trail.
That last point matters. Combining unrelated issues into one email seems efficient, but it usually slows things down. Separate reports are easier to track, assign, test, and close.
A copy and paste template
Use this format when reporting a bug to your web agency:
Subject[Page or feature] Short description of the issue
Page URLPaste the exact page link
What I was trying to doBriefly describe the task
Steps to reproduce
Expected resultWhat should have happened
Actual resultWhat happened instead
Device and browserExample: iPhone 15, Safari
SeverityCritical / High / Medium / Low
Business impactExample: customers can't complete checkout
Visual evidenceScreenshot or screen recording attached
Weak report versus strong report
Weak report:
The contact form isn't working.
Strong report:
On the contact page, the form fails after clicking Submit. I tested it on an iPhone using Safari. I filled in all fields, clicked Submit, and the page refreshed without showing a success message. I expected the enquiry to send. This is High severity because new leads may be lost. Screenshot attached.
That's the difference between a message that starts work and a message that starts questions.
If you build your own internal support process, these feedback form best practices are useful for turning this template into a simple form staff can fill out consistently. It also pairs well with broader agile development best practices , where clean issue reporting keeps work moving.
What Happens After You Report a Bug
Once your report is sent, the job moves into triage. The agency will usually try to reproduce the problem first. If they can recreate it, they'll assess severity, look for the cause, and decide whether it needs an immediate patch, a scheduled fix, or more information from you.
That's why a clear first report matters so much. It shortens the time spent clarifying and increases the time spent solving.
What good follow-up looks like
If the developer asks a question, keep the reply tied to the original issue. New screenshots, a second test on another device, or confirmation that the problem also happens to a colleague can all help.
If you're using a support channel that mixes conversations together, organised follow-up matters even more. Teams handling customer messages across multiple channels often rely on better workflows and tools. If you're interested in that side of support operations, this overview of software for social customer care is a useful read.
Your part isn't finished at send
When the fix is ready, test the original steps again. Don't just check whether the page “looks fine”. Repeat the same action that caused the bug in the first place.
If it's resolved, say so clearly. If the issue has changed but not fully gone, report what's different. That keeps the thread clean and avoids the same bug bouncing around unresolved.
A good bug report, a sensible triage process, and a quick verification loop usually turn a stressful website problem into a manageable support task.
