There is a category of wasted time that almost no company tracks. A bug, a complaint, or a request lands in the wrong place. The wrong team spends time reading it. They pass it on. The next team spends time getting up to speed. The original issue sits unresolved for days. Nobody files this under "cost." It just disappears into the calendar.
Miro decided to measure it. What they found was 42 years of cumulative lost productivity per year, caused by bugs being routed to the wrong teams. That figure comes from a company with roughly 100 internal engineering teams. When a bug could go to any one of them, the odds of a correct first guess, without help, are low. Miro found that a meaningful portion of its bugs were missing internal resolution deadlines, and the primary reason was that they kept being passed from team to team.
Their solution, called BugManager, works through Slack, which is where most of their engineers already operate. An engineer posts a bug report. BugManager reads the text, processes any attached screenshots or screen recordings, searches through internal documentation, past resolved tickets, and team responsibility descriptions, then suggests the five most likely teams to own the problem, ranked by confidence, with a written explanation for each choice. The whole process takes about 53 seconds.
The accuracy number here matters. The system correctly identifies the right team on its first suggestion more than 75 percent of the time. Its previous tool, a model that had been trained specifically for the task, was doing that correctly only about 44 percent of the time. The difference is not a small improvement in a software metric. It is the difference between a bug landing in the right hands immediately versus spending days in the wrong queue.
What makes this technically interesting for non-technical readers is the reason the old approach failed. Trained classification models are like a specialist who learned the company's structure at one point in time. Every time a team merges, splits, or changes what it owns, the model becomes slightly less accurate. Retraining it is slow and expensive. The new approach works more like a very attentive generalist who reads the current team descriptions every time they make a decision. Changes propagate immediately because the system reads the descriptions fresh rather than relying on old training data.
The broader signal here is not about software bugs specifically. It is about routing problems, which are everywhere. A customer complaint that lands with the wrong department. A procurement request that sits with the wrong approver. A support ticket escalated to the wrong team. Research shows that more than half of organizations surveyed in 2025 identified lack of automation in ticket handling as their single biggest operational challenge. The problem is not unique to tech companies. It is present in any organisation where requests need to be matched to the right people, and where the structure of those people changes over time.
The approach Miro used is also notable for what it does not require. There is no large upfront data labelling project. There is no months-long model training cycle. The system relies on documentation the company already maintains, like team descriptions, past tickets, and internal wikis, and reads that documentation at the moment it needs to make a decision. That makes it far more accessible than traditional approaches, which demanded significant data science resources before they could work at all.
The financial case is worth understanding plainly. Developers are among the highest-cost employees in most organisations. Research consistently shows they spend 30 to 50 percent of their time on unplanned work like bug investigation rather than building new features. Each wrong routing decision triggers a chain: reading, investigating, escalating, re-reading. All of it is invisible in the budget until someone measures it. Miro measured it. The number was large enough to justify building a dedicated system.
For any organisation that processes internal requests at scale, whether those are IT tickets, customer complaints, claims, or operational queries, the Miro case is a useful reference point. The technology required is now accessible through major cloud providers without deep technical expertise. The harder part, as Miro found, is knowing what your internal knowledge base actually contains and keeping those team and responsibility descriptions accurate. That is a management problem, not a technology problem.