The short answer: Bug reporting in a business application is exactly the kind of process worth automating from end to end: the user clicks a floating icon directly in the application, marks the problem on a screenshot, and submits it. The system automatically attaches technical context, including browser console errors, while a language model summarizes the report and suggests a priority. A Telegram notification arrives before the user could have finished writing an email. We built such a system for our own operations. It runs as a central service for several projects at once, and deploying it in another application takes just one line of code. This case study explains how it works under the hood and what it can teach you about automating processes in your own company.
We have already written two general blog posts about business process automation—what is genuinely worth automating and seven processes that save hours. General advice has one weakness, however: it cannot show you what a finished automation looks like up close—where it begins, where it ends, and which parts still require a person. This time, we are therefore looking at a specific project from our own operations: a bug-reporting system we built for ourselves because we had grown tired of the usual „it doesn’t work, could you take a look?"
The starting point: „It doesn’t work" by email
We operate several web applications—both our own and applications we have built and manage for clients. Sooner or later, the same process emerges in every one of them: a user encounters an error and needs to tell someone about it.
Without a dedicated system, the process always looks the same:
- The user writes an email or calls: „I can’t save the record."
- The technician asks follow-up questions: Which browser are you using? What page were you on? What exactly did you click? Can you send a screenshot?
- Meanwhile, the user moves on to something else, replies a day later, and no longer remembers half the details.
- The technician tries to reproduce the error without enough information—often unsuccessfully because a crucial detail is missing from the description.
Every pass through this loop means waiting on both sides. More importantly, reports have no consistent structure or shared queue. One arrives by email, another by phone, and a third is mentioned verbally in a meeting. A fourth disappears entirely because the user „didn’t want to bother anyone."
According to the checklist in our automation article, this is a textbook candidate: the process is repetitive, has a clear input and output (an error → a structured report in a queue), and is currently slowed down by manual transcription and follow-up questions.
The brief: report the bug where it happens and send it to a single queue
We set the following goals:
- Users report bugs directly in the application where they encounter them—without email, switching windows, or taking screenshots separately.
- Every report has the same structure: a screenshot with the affected area marked, a description, and technical context.
- All applications report to one central queue—rather than five inboxes, five forms, and five different sets of habits.
- AI triage suggests the priority and summary so the queue is sorted before anyone opens it for the first time.
- The team learns about every new report immediately via Telegram.
What users see: a bug in the bottom-right corner
A small bug icon floats in the corner of the application. Clicking it opens a three-step wizard:
- Mark the location. The widget captures the current screen, and the user marks the problem area with a pen or selection tool. There is no need to „press Print Screen and paste it into an email"—the annotation happens directly in the application.
- Describe it. The user briefly describes what happened and what they expected. Anyone who does not want to type can dictate the description.
- Review and submit. The user sees exactly what will be sent and confirms the submission.
The entire process takes less time than opening an email client. More importantly, the report automatically includes browser console errors—precisely the technical information an ordinary user would never send because they do not know it exists.
The widget runs in a shadow DOM, making it completely independent of the technology used by the page. It does not disrupt the application’s appearance, whether the website is built with React, an older content management system, or plain static pages.
What happens after submission: sanitization, triage, Telegram
This is where things become more interesting. Everything that follows happens without any human intervention:
1. Sanitization. Before the report is written to the database, its text passes through a filter that redacts passwords, tokens, email addresses, phone numbers, and Czech birth numbers. If a user accidentally includes a password in the description, it never reaches the queue. The reporter’s identity—their name and email address—is retained so that the team can respond.
2. AI triage. A language model reads the report and adds a suggested priority and concise summary. The queue is therefore sorted before anyone opens it: a failure that prevents saving rises to the top, while a cosmetic comment about a button’s color can wait. The triage runs through an OpenAI-compatible interface, so the model can also operate locally on the company’s own hardware—reports from internal applications then never have to leave the organization.
3. Telegram notification. A message about the new report arrives in the chat immediately after submission. Each project can have its own channel, ensuring that notifications from a client’s application reach the people responsible for it.
4. Admin queue. The person handling the reports sees them all in one place and can filter them by project, status, type, or priority. Each report includes the annotated screenshot, description, console errors, and context—there is no need for follow-up questions because all the important information arrived the first time. Once the bug has been fixed, the report is marked as resolved.
Notice the division of labor we emphasize in every article about AI: the machine sorts and prepares; the person decides and fixes. Triage only suggests a priority—it does not wake anyone up or fix anything itself. This is intentional. Bug reporting is a process with a clear input and output, making it ideal for automation; the diagnosis and repair themselves are not.
Sensitive data: what the system deliberately does not record
With internal tools, security is often considered only after deployment. Here, it was part of the brief from the outset:
- Sensitive data is redacted before storage. Passwords, tokens, email addresses, phone numbers, and Czech birth numbers are removed from the report text before anything is saved.
- Screenshots are kept outside the public website. Screenshots are stored outside publicly accessible files and can only be viewed through the secured admin interface. A screenshot from an internal application is therefore never exposed at a public address.
- Origin validation. The server accepts reports only from domains registered for the project. An unrelated website cannot fill the queue with junk.
- Token-protected admin interface. The report queue is accessible only with a secret token; without it, the server denies access.
Deploying it in another system: one line of code
From the outset, the system was designed as a central service for multiple projects. Deploying it in another application looks like this:
- A single
<script>referencing the central service is added to the page. - The project receives a key, a list of allowed domains, and, if needed, its own Telegram channel in the service registry.
- That is it—the bug icon appears in the corner, and reports begin arriving in the shared queue.
There is no need to modify the client’s system: no changes to its code, no installation on its server, and no dependency on how the website was built. The entire service runs as a single container on our server, without complex infrastructure for anyone else to maintain.
It is also worth mentioning how the system came about. We reused roughly 80% of the code from a bug-reporting module that we had originally built for a specific commission management application, then generalized it for multiple projects. Our inspection records application was the next deployment. This is a typical path for effective automation—it does not begin as a large greenfield project, but as a generalization of something that has already proved itself in production.
What it actually saves
We will not claim that it saved an exact number of hours—we did not measure it that way. The savings are nevertheless clear from the structure of the process:
- The follow-up loop is gone. Previously, gathering the screenshot, browser version, and steps required several rounds of emails. Now everything arrives the first time, including console errors that users would never send themselves.
- Reports do not get lost. Everything is kept in one queue with a status. Nothing remains buried in an inbox, in notes from a phone call, or in someone’s memory.
- The priority is immediately clear. The machine pre-sorts the queue, so critical issues are not buried among minor ones.
- The reporting barrier is lower. When submitting a report takes three clicks directly in the application, users no longer think, „This isn’t worth writing an email about"—and bugs reach the person responsible sooner.
What to take away when automating your own process
This project fits precisely into the framework described in our general articles:
- Clear input and output. An error in the application → a structured report in the queue. No decisions involving accountability—ideal work for automation.
- A person remains in the loop. AI sorts and summarizes; a technician handles the diagnosis, repair, and communication with the user.
- Sensitive data stays under control. Sanitization before storage, screenshots kept outside the public website, and the option to use a locally hosted model.
- Start small, then generalize. First, a module in a single application; only after it had proved itself did it become a central service for every project.
The same pattern can be applied to order intake, complaints, internal IT requests, or document approval—anywhere unstructured emails currently fly back and forth before someone manually enters their contents elsewhere.
If reading this made you think, „We need something like this too"—whether for bug reporting or a completely different process currently handled through emails and follow-up questions—this is exactly the kind of custom automation we build for companies through our IT services for businesses. We begin with a short consultation about your specific process, not a presentation about artificial intelligence. You can reach us through our contact page. And if you want your team to learn how to identify similar opportunities themselves, take a look at our AI training for businesses.
Frequently asked questions
Does the widget work only in modern applications?
No. It is embedded using a single script and, thanks to the shadow DOM, runs independently of the page’s technology—whether in a modern single-page application, an older content management system, or a static website. The application’s code does not need to be modified.
What if a user includes a password or personal information in the report?
Before storage, the report text passes through a sanitization process that redacts passwords, tokens, email addresses, phone numbers, and Czech birth numbers. The reporter’s name and email address are retained so that the team can respond once the report has been resolved.
Does AI triage replace the developer?
No—and that is not the goal. The triage summarizes the report and suggests a priority, allowing a person to open a sorted queue instead of a pile of unstructured emails. Diagnosis and repair are always handled by a technician.
Do report data have to be sent to a foreign cloud service?
No. The service runs on the company’s own server, screenshots are stored outside publicly accessible files, and AI triage can use a locally hosted model. Reports from internal applications then remain within the company’s infrastructure.
How much does this type of automation cost?
It depends on the scope and on what your company already has in place, which is why we provide a specific proposal only after a short consultation about your process. We describe the general cost framework for business AI in our article how much AI costs for a business.
Where to find us
ITHOPE is a company based in Brno, Czechia: we do data recovery from disks, RAID and NAS, PC and laptop service and IT for business, all in our own lab at Viniční 3587/216, 615 00 Brno.
Phone +420 775 556 063 (24/7 line). You can bring the device in person, or send it by courier (Zásilkovna, PPL).