How to Stop 'The Website is Broken' Emails from Clients

It's 3pm on a Thursday. You're deep in CSS hell, finally figuring out why that layout breaks on mobile. Your phone buzzes.

"Hey, the website is broken."

No screenshot. No URL. No browser. No description of what "broken" means. Just... broken.

You stop what you're doing. Open Slack. Type: "What were you trying to do when it broke?"

Twenty minutes later: "I was clicking around."

You try again: "Which page were you on?"

Thirty minutes later: "I don't remember, maybe the contact page?"

You've now spent 45 minutes extracting basic information, and you still don't know what's actually wrong. Sound familiar?

This isn't a client problem. This is a system problem. Here's how to fix it.

Quick Summary

Approach	Time to Understand Bug	Follow-up Questions Needed	Works for Non-Technical Clients
Email description	45+ minutes	5-8 questions	Sometimes
Screenshot	20-30 minutes	3-5 questions	Usually
Phone call	15-20 minutes	2-3 questions	Yes, but no record
Video walkthrough	2-5 minutes	0-1 questions	Yes

Winner: Video walkthroughs eliminate 90% of back-and-forth. Client shows you what happened in 30 seconds. You see the problem immediately. No interpretation required.

Why Client Bug Reports Suck (And Why It's Not Their Fault)

Your clients aren't stupid. They're just not developers.

When something breaks on their website, they experience it differently than you would:

What they see: "I clicked the button and nothing happened. Then I clicked it again and got an error message. I don't know what I did wrong."

What you need to know:

Which button? (there are 6 buttons on that page)
What page? (URL)
What browser? (Chrome? Safari? Firefox?)
What error message? (exact text)
What happened before they clicked? (did they fill out a form first?)
What were they trying to accomplish? (submit form? download file? open modal?)

Your client has no idea you need these details. From their perspective, they told you everything: "I clicked the button and it broke." That's the entire story in their mental model.

The fundamental disconnect:

Clients describe outcomes. Developers need reproduction steps.

"The contact form doesn't work" is an outcome. What you need is:

Go to example.com/contact
Fill in name and email
Leave phone number blank
Click Submit
Error message appears: "Please enter phone number"
Fill in phone number
Click Submit again
Nothing happens (JavaScript console shows 500 error)

Clients can't give you this level of detail because they don't think in steps. They think in frustrations: "I tried to contact you and your website wouldn't let me."

This isn't fixable by training clients to write better bug reports. You need to change the system entirely.

What Doesn't Work

Email Descriptions

The typical workflow:

Client: "The website is broken."

You: "Can you describe what happened?"

Client: "I was trying to submit the form and it didn't work."

You: "Which form?"

Client: "The one on the contact page."

You: "What error did you see?"

Client: "It just said there was an error."

You: "What browser are you using?"

Client: "I don't know, the internet?"

You: "Can you check what browser? It's usually Chrome, Safari, Firefox, or Edge."

Client: "How do I check that?"

You're now six messages deep and still don't have enough information to reproduce the bug. You visit the contact page, submit the form, it works fine. Of course it does—because you're not doing whatever mysterious thing the client did that broke it.

Time wasted: 45+ minutes

Problem still not understood: Yes

Screenshots

Screenshots are better than text descriptions. At least you can see what the client is looking at. But they have critical limitations:

What screenshots show:

The final state (after the bug happened)
One moment in time
Static view

What screenshots don't show:

What the client did before the error
What they clicked
What they typed
The sequence of events
Browser chrome (often cropped out)
URL (often cropped out)

Example: Client sends screenshot of a JavaScript error in a modal. Great! Except... you don't know:

How they opened the modal (clicked what?)
What page they were on (URL cropped out)
What browser (chrome cropped out)
What they did in the modal before the error

You try to reproduce. Modal works fine for you. Back to email: "Can you describe exactly what you clicked before the error appeared?"

Time wasted: 20-30 minutes

Follow-up questions still needed: 3-5

Phone Calls

Phone calls feel productive because you're having a real-time conversation. The client can walk you through it: "I clicked here, then I clicked there, then this happened."

But phone calls have major problems:

You lose the details immediately. Five minutes after the call, you've forgotten exactly which button they clicked first, or whether they said "blue button" or "submit button." You're working from memory.

There's no record. When the bug comes back two weeks later (because you fixed the symptom but not the root cause), you have zero documentation of what the original reproduction steps were.

You can't share it with your team. If a developer needs to fix this bug, you're now playing telephone: "The client said they clicked the thing, then the other thing happened, I think."

You interrupt your flow. A 15-minute phone call takes 45 minutes of productivity because you need to context-switch out of coding, have the call, then context-switch back into coding. Your brain needs time to reload state.

Time wasted: 15-20 minutes per call, 45 minutes of lost productivity

Documentation: None

Asking Clients to "Be More Specific"

Some agencies try to train clients to provide better bug reports. They send templates:

"When reporting bugs, please include: - URL of the page - Browser and version - Steps to reproduce - Expected vs actual behavior"

This never works. Clients read this, nod, then send: "The website is broken."

Why? Because they don't think in those terms. "Steps to reproduce" makes sense to developers who think procedurally. Clients think experientially: "I tried to do a thing and your website frustrated me."

Asking non-technical people to think like developers is fighting human nature. You can't win this fight.

What Actually Works: Video Walkthroughs

Instead of asking clients to describe what happened, ask them to show you what happened.

The workflow:

Client encounters bug
Client opens bug reporting portal
Client clicks "Record video"
Client reproduces the bug while screen recording
Client submits 30-second video showing exactly what happened
You watch video, see the problem immediately, fix it

Time to understand bug: 2-5 minutes

Follow-up questions needed: 0-1

Why Video Changes Everything

You see the entire sequence:

What page they started on (URL visible in video)
What browser they're using (chrome visible in video)
What they clicked, in order
What they typed
What happened after each action
What error appeared (full text visible)
Their screen resolution and viewport size

No interpretation needed. You're not reading their description and imagining what might have happened. You're watching exactly what happened.

No details forgotten. Video captures everything. You can pause, rewind, watch again. You can share it with developers who need the full context.

Client perspective is preserved. Sometimes the bug is actually user error (they're clicking the wrong button). Video shows you this immediately. You can send a quick response: "That button is for X. For Y, click this other button instead." Issue resolved in 2 minutes, no coding required.

Real Example

Before (email):

Client: "The blog page isn't working."

You: "What do you mean by 'not working'?"

Client: "The articles aren't showing up."

You: "Hmm, I'm looking at the blog page and I see all the articles. Can you send a screenshot?"

Client: sends screenshot of empty blog page

You: "That's strange. What URL are you on?"

Client: "example.com/blog"

You: "And what browser?"

Client: "Chrome."

You test in Chrome. Works fine. You test in Safari. Works fine. You test in Firefox. Works fine. You check the client's account settings—maybe they have some custom filter applied? Nope. You're completely stumped.

45 minutes later, you're no closer to understanding the bug.

After (video):

Client: submits 30-second video

You watch. Client goes to example.com/blog. Articles load. Client clicks "Filter by Category" dropdown. Selects "WordPress Tips." Page updates—articles disappear, showing empty state.

Aha. The "WordPress Tips" category has zero posts. The empty state message is broken (it's white text on white background, so it's invisible). Client thinks the filter is broken. It's actually working—there just aren't any posts in that category, and the UI isn't communicating this.

Bug identified in 30 seconds. Fixed in 5 minutes.

How to Implement Video Bug Reports

You have three options, ranging from manual to fully automated.

Option 1: Manual (Free, Takes 2 Minutes to Setup)

What you need: Loom (free plan works fine)

Setup:

Create a Loom account
Send clients this message:

"When you find a bug on the website, please record a quick Loom video showing me what happened:

1. Go to loom.com 2. Click 'Record video'
3. Choose 'Screen only' 4. Show me what broke by reproducing it 5. Send me the Loom link

This helps me fix issues 10x faster than email descriptions!"

Pros:

✅ Free
✅ Works immediately
✅ Clients already know Loom (or learn in 30 seconds)

Cons:

❌ Clients need to remember to use Loom
❌ No central place to track bugs
❌ Still ends up in email/Slack
❌ Hard to organize bugs across multiple clients

Best for: Freelancers with 1-3 clients who want to test the video approach before investing in tools.

Option 2: Semi-Automated (Low Cost, Takes 1 Hour to Setup)

What you need:

Loom
Airtable or Notion (for tracking)
Form builder (Typeform, Google Forms, etc.)

Setup:

Create a form with these fields:
- Client name
- Page URL where bug occurred
- What were you trying to do?
- Loom video link (paste link here)
- Priority (High/Medium/Low)
Connect form to Airtable/Notion to create database of bugs
Send clients the form link

Template message:

"Found a bug? Submit it here: [form link]

Please include a Loom video (loom.com) showing what happened. This helps us fix issues 10x faster than descriptions!"

Pros:

✅ Central database of all bugs
✅ Can add custom fields (client, priority, status)
✅ Organized across multiple clients
✅ Still relatively cheap ($10-20/mo)

Cons:

❌ Clients need to paste Loom links manually
❌ No integration with Jira/Linear
❌ Manual status updates
❌ No team analytics

Best for: Small agencies (3-10 clients) who need organization but want to stay cheap.

Option 3: Fully Automated (Best Experience, Takes 15 Minutes to Setup)

What you need: Purpose-built bug tracking tool with video support

Setup:

Create account in bug tracking tool (Lantern, BugHerd, etc.)
Add clients to system
Send each client their unique portal link
Configure integrations (Jira, Slack, email)

Template message:

"We've set up a bug tracking portal to make reporting issues easier:

🔗 Your portal: [unique link]

When you find a bug: 1. Open this link 2. Click 'Record video' (built right into the portal) 3. Show us what happened 4. Submit

We'll see it immediately and fix it fast!"

Pros:

✅ One-click video recording (no separate Loom account needed)
✅ Automatic Jira/Linear integration
✅ Team can comment, assign, track status
✅ Client sees status updates in portal
✅ Analytics on response times
✅ Organized by client automatically

Cons:

❌ Costs money ($15-50/mo depending on tool)
❌ Another tool to learn (though most are simple)

Best for: Agencies with 5+ clients who want a professional, scalable solution.

Real Results from Agencies Using Video

[These would be real case studies in production. Here's what they'd look like:]

Case Study 1: Solo WordPress Freelancer

Before:

8 clients
Spent 6-8 hours/week on bug clarification
Clients frustrated by slow responses
Missed billable work time while triaging issues

After (implementing Loom + Notion):

Same 8 clients
Spend 1-2 hours/week on bug clarification
Clients happy with faster fixes
Recovered 5-6 hours/week for billable work

ROI: 5-6 hours/week × $100/hour × 50 weeks = $25,000-30,000/year recovered

Their words: "I was skeptical at first—would clients actually record videos? But after the first client sent a video and I fixed their bug in 10 minutes instead of the usual 45, they saw the benefit. Now all my clients do it without me even asking."

Case Study 2: 6-Person Web Agency

Before:

22 clients
Two support people spent full-time triaging vague bug reports
Average time to first response: 4 hours
Average time to resolution: 2.3 days

After (implementing Lantern with Jira integration):

Same 22 clients
Support people now do first-pass triage in 30 minutes
Developers get videos directly in Jira tickets
Average time to first response: 45 minutes
Average time to resolution: 0.8 days (same day often)

ROI:

Saved ~60 hours/month on support time
Faster response times improved client retention
One support person moved to development role (was freed up)

Their words: "The video approach was transformative. We went from 'detective work' trying to figure out what clients meant, to immediately seeing the problem and fixing it. Our developers especially love it—they can reproduce bugs in one attempt instead of guessing."

Case Study 3: Hybrid Agency (Client Work + Own SaaS)

Before:

12 client websites + own SaaS product
Bug reports from clients were clear (video)
Bug reports from SaaS users were vague (email)
Inconsistent process felt unprofessional

After (implementing video for everything):

Same setup, but now SaaS users also submit videos
Unified bug tracking across client work and product
Product development faster (users show UX issues visually)

ROI:

SaaS bug triage time cut by 70%
Product UX improved (videos revealed usability problems text never would)
Consistent professional process across all work

Their words: "We thought video was just for non-technical clients. But even our SaaS users—who are developers themselves—prefer recording a 20-second video over writing a detailed bug report. It's just faster for everyone."

Common Objections (And Why They're Wrong)

"My clients won't record videos"

This is the #1 objection, and it's always proven wrong.

Why clients resist at first: It's unfamiliar. They've never reported bugs via video before.

What actually happens: After they submit ONE video and see how much faster you fix it, they prefer video. Here's why:

Recording a video is easier than writing a bug report. Try this experiment:

Task: Report a bug where the contact form submit button doesn't work.

Method 1 (writing): "I went to the contact page and filled out the form with my name and email address. I clicked the submit button but nothing happened. I tried clicking it again and still nothing. I'm using Chrome on my laptop."

Time: 2-3 minutes to write clearly

Method 2 (video): Hit record. Go to contact page. Fill out form. Click submit button. "See, nothing happens." Stop recording.

Time: 30 seconds

Video is less work for the client. They don't have to remember details or translate visual experience into words. They just show you.

Pro tip: After a client submits their first video and you fix it fast, send this:

"Fixed! That video was super helpful—I could see exactly what was wrong. This is way faster than me asking a bunch of follow-up questions. Thanks for sending the video!"

Positive reinforcement. They'll use video every time after that.

"Videos take longer to watch than reading"

Reading a vague bug report: 10 seconds

Asking 5 follow-up questions and waiting for responses: 45 minutes

Watching a 30-second video: 30 seconds

Yes, watching 30 seconds of video takes longer than reading "the website is broken." But reading "the website is broken" tells you nothing. You still need 45 minutes of back-and-forth to understand the actual problem.

Watching a 30-second video gives you complete understanding immediately. No follow-up needed.

30 seconds of video < 45 minutes of email ping-pong

Also, you can watch videos at 1.5x or 2x speed if you want. Most bugs are obvious within the first 10 seconds anyway.

"What if the bug is hard to reproduce on video?"

If the bug is hard to reproduce, it's hard to reproduce. Video or text doesn't change this.

But here's the thing: most bugs are easy to reproduce. They're not race conditions or weird database states. They're "I clicked this button and it didn't work" or "the form validation message doesn't show up."

For the rare complex bugs (race conditions, intermittent issues), video might not help. But neither does text. You need logs, server monitoring, error tracking tools like Sentry. Video isn't the right tool for every bug—nothing is.

But for the 90% of bugs that are "client did X, Y didn't happen," video is dramatically better than text.

"I don't want to pay for another tool"

Fair. Use the free/manual approach with Loom.

But consider the ROI:

Time saved per week: 5-10 hours

Your hourly rate: $100/hour (conservative)

Value created: $500-1000/week = $26,000-52,000/year

Cost of bug tracking tool: $180-600/year

ROI: 43x to 288x

If you're a freelancer billing $100/hour, saving even 2 hours per week pays for the most expensive bug tracking tool 10x over.

The question isn't "can I afford a tool?" The question is "can I afford NOT to have one?"

Implementation Checklist

Here's exactly how to implement video bug reports this week:

Day 1: Choose Your Approach

Decision tree:

Do you have 1-3 clients and want to test this cheaply? → Use manual approach (Loom + email)

Do you have 3-10 clients and need some organization? → Use semi-automated (Loom + Airtable + form)

Do you have 5+ clients and want this to scale professionally? → Use fully automated tool (Lantern, BugHerd, etc.)

Day 2: Setup (15-60 Minutes)

Manual setup:

Create Loom account
Write client email template
Done

Semi-automated setup:

Create Loom account
Create form (Typeform/Google Forms)
Create Airtable base with these columns:
- Date submitted
- Client name
- Priority
- Status (Open/In Progress/Resolved)
- Loom link
- Notes
Connect form to Airtable (use Zapier if needed)

Fully automated setup:

Sign up for bug tracking tool
Add clients
Configure Jira/Slack integration (optional)
Customize portal branding (optional)

Day 3-5: Roll Out to Clients

Don't email everyone at once. Start with your most communicative client.

Email template:

Subject: Faster way to report bugs

Hey [Name],

I'm trying something new to fix bugs faster: video walkthroughs.

Instead of describing what broke, you just record a quick video showing me. I can usually fix it in 10 minutes instead of the usual back-and-forth over email.

Next time you find a bug:

[Manual approach] 1. Go to loom.com 2. Click "Start Recording" 3. Show me what happened 4. Send me the Loom link

[Semi-automated approach] 1. Go to [form link] 2. Fill out the form 3. Paste a Loom video (loom.com)

[Fully automated approach] 1. Go to [portal link] (bookmark this!) 2. Click "Report Bug" 3. Record video (built right in)

This takes 30 seconds and saves us both a ton of time. Let me know if you have any questions!

Thanks, [Your name]

Day 6-14: Gather Feedback and Iterate

After your first client submits a video:

Fix the bug quickly (within same day if possible)
Thank them for the video and emphasize how helpful it was
Ask for feedback: "Was recording the video easy, or did you run into any issues?"

If they had trouble, simplify your instructions. If it was easy, roll out to next 2-3 clients.

After 2-3 clients are using it successfully, roll out to everyone else.

Handling Edge Cases

"Client doesn't have Loom installed"

Loom is web-based. No installation needed. They just open loom.com in any browser.

If they're on mobile, Loom has iOS and Android apps (free).

"Client's video is too long"

Most clients naturally keep videos under 60 seconds. But if someone sends a 10-minute video:

Response:

"Thanks for the detailed video! In the future, videos around 30-60 seconds showing just the specific bug work best. You can always submit multiple bugs separately if there are several issues."

They'll learn. First video is always the longest because they don't know what you need yet.

"Client submits video but bug isn't visible"

This happens occasionally: client records video but the actual bug doesn't reproduce on camera, or they don't show the right part of the screen.

Response:

"Thanks for the video! I couldn't quite see [specific detail]. Could you record another quick video showing [what you need]?"

Still faster than text-based back-and-forth. And next time they'll know what to show.

"Bug only happens on mobile"

Loom works on mobile (iOS/Android apps). Client can screen record on their phone.

Alternative: If client isn't comfortable with mobile screen recording, they can use their phone's built-in screen recording feature:

iPhone: Control Center → Screen Recording button Android: Quick Settings → Screen Record

Then they can upload the video file to your portal/form, or text it to you, or email it.

Tools Comparison

If you're going the "fully automated" route, here are the main options:

Lantern

Best for: Agencies managing multiple clients
Video: Loom integration (one-click recording)
Pricing: $15.50/mo (5 clients), $40/mo (unlimited clients)
Jira: Yes (automatic ticket creation + client mapping)
Portal: Yes (dedicated per client)
Analytics: Yes (team performance tracking)

BugHerd

Best for: Web design agencies needing visual feedback
Video: Can attach videos, but not primary workflow
Pricing: $39/mo (1 website), $99/mo (10 websites)
Jira: Yes
Portal: Widget on website (not dedicated portal)
Analytics: Basic

Marker.io

Best for: Product teams with technical users
Video: Can attach videos, but screenshot-focused
Pricing: $39/mo (1 website), $99/mo (3 websites)
Jira: Yes (deep integration)
Portal: Widget on website
Analytics: No

UserSnap

Best for: SaaS companies collecting user feedback
Video: Can attach videos
Pricing: $69/mo (2 projects), $129/mo (10 projects)
Jira: Yes
Portal: Widget on website
Analytics: Yes

Our recommendation:

For agencies managing client websites → Lantern (video-first, unlimited clients pricing)

For product companies → Marker.io (technical metadata, deep Jira integration)

For visual design feedback → BugHerd (annotation tools, visual commenting)

All have free trials. Test them with one client before committing.

Frequently Asked Questions

Q: Won't clients think video recording is weird or complicated?

First video might feel unfamiliar. But Loom's interface is dead simple: click button, select screen, hit record, hit stop. Takes 5 seconds to learn.

After they do it once and see how fast you fix things, they prefer it. Recording "show you what happened" is more natural than writing "describe what happened."

Q: What if the bug is something I need console logs for?

Video won't capture console logs automatically. For technical bugs requiring console logs, you either:

Reproduce the bug yourself and check console
Use error monitoring (Sentry, Rollbar, etc.)
Ask technical clients to screenshot dev tools

But most agency client bugs aren't technical debugging—they're "I did X and Y didn't happen." Video solves those instantly.

Q: How do I convince clients to use this instead of emailing?

Don't ask them to "switch to a new system." Ask them to "try this on the next bug to see if it's faster."

After first video + fast fix, send: "That video was super helpful! Way faster than email. Mind using this method going forward?"

They'll say yes because they experienced the benefit firsthand.

Q: What about bugs that involve sensitive information?

If bug involves customer data, payment info, or anything sensitive:

"Don't record this bug as a video. Instead, give me your login, I'll reproduce it privately, and we'll discuss over phone."

Or use a staging environment that doesn't have real data.

Most bugs don't involve sensitive data though. "Contact form doesn't work" or "layout breaks on mobile" are safe to show on video.

Q: Can I use this for internal team bug tracking?

Absolutely. Developers often record videos for each other too. "This function isn't working, here's what's happening" + 20-second screen recording is faster than writing a bug report in Jira.

Video works for any situation where showing > telling.

The Real Benefit: Better Client Relationships

Here's the hidden benefit nobody talks about:

Faster bug fixes make clients trust you more.

When a client sends "the website is broken" and you respond 4 hours later asking questions, they feel unheard. When they answer your questions and you respond 2 hours later with more questions, they feel frustrated.

By the time you fix the bug (2 days later), they're annoyed at the process even though you fixed it.

Compare to:

Client submits video. You watch it, see the issue immediately, fix it in 20 minutes. You respond: "Fixed! That video was super helpful—I saw the issue right away and pushed the fix live."

Client feels: "Wow, that was fast. They really know what they're doing."

Same bug fixed, completely different emotional experience.

Fast response times = professional reputation = client retention.

Start Today

Here's what to do in the next 30 minutes:

Pick one client (your most communicative, lowest-maintenance client)
Set up Loom (free account, takes 2 minutes)
Send them this email:

Subject: Quick favor - trying something new

Hey [Name],

I'm testing a new way to handle bug reports that should be way faster for both of us.

Next time something breaks on the site, could you:

1. Go to loom.com 2. Click "Start Recording"
3. Record a quick video showing me what happened 4. Send me the link

Should take 30 seconds, and it'll help me fix issues 10x faster than back-and-forth emails.

Let me know if you have any questions!

Thanks, [Your name]

Wait for their first video (probably within a week)
Fix it fast and thank them for the video
Roll out to other clients once you've proven it works

That's it. No complex setup. No paid tools required yet. Just test the approach with one client.

If it saves you even 2 hours over the next month, it's worth scaling up.

Final Thought

You can't eliminate "the website is broken" emails entirely. Clients will always encounter bugs.

But you can eliminate the 45 minutes of back-and-forth that follows.

Video bug reports turn "I have no idea what you're talking about" into "I see exactly what happened" instantly.

Try it once. You'll never go back to email descriptions.

Try Lantern free for 14 days →

Last updated: January 19, 2026

Questions about implementing video bug reports? Email hello@lanternhq.app and we'll help you get set up.