When AI solves an operations problem.

Context

AUVP Analítica is the research SaaS that backs investment decisions from AUVP Capital. ProdMan worked on several fronts alongside that product team: strategic dashboards, applied research, strategic market analysis, AI automations. The main front, and the focus of this case, was an operations problem suffocating the Analítica team: an inadequate technical support process, a growing queue of tickets, a backlog piling up.

We looked at the process before the technology

Before proposing a solution, we went inside the operation. How the user reports. How a report becomes a task. Who triaged it. How the evidence travels. How the technical team gets pulled in.

The root cause was procedural. The intake channel mixed bugs, suggestions and questions in the same inbox. Triage depended on a human reading case by case. Reports reached the queue without enough evidence, and the technical team spent hours finding out that most of them were never bugs.

Technology does not fix a broken process. It scales a good one.

Getting the concepts straight

Definition first: a bug is erratic software behavior, designed and programmed intentionally to do A but behaving like B. Until the nature of a report is validated, it is not a bug yet.

In the new "possible problem" flow, rich fields were collected: detailed description, date and time, evidence of the problem, expected and observed behavior. The new analysis process would start from there.

Layers of the flow

Every step that used to be raw human work became a bounded function, with clear inputs and defined context:

• Triage cross-checks the report against business rules, open tasks and software, product and data documentation.
• Reproduction tries to recreate the problem under conditions identical to the user's, to collect empirical evidence.
• Log analysis covers backend, frontend, database, scheduled jobs, releases and vendors.
• Product prioritizes, gives its assessment, sets severity and destination.
• Flow coordination moves the task between steps.
• Quality closes the loop. If a step failed, the task goes back to it. It does not move forward.

The purpose is direct: cure the task before it reaches the technical team.

Choosing AI, not headcount

With the flow designed, one operational decision remained: who runs each step.

Hiring new technical support people was the most obvious alternative. It was declined on our recommendation. The process had been defined so tightly that each step took the shape of a bounded function, and that is exactly the kind of work where applied AI fits, with scale, predictable cost and full traceability.

This was not "let's use AI for the sake of it". It was "this is the type of work where applying AI is the best alternative".

One human operator was kept in place, responsible among other duties for running the new automated flow day to day, validating the output of the AI's work and, when needed, enriching the solution's knowledge base so it kept getting better. A job that took a few minutes a day.

The multi-agent system

Each step became a specialized AI agent, with its own tools and skills, bounded context and dedicated knowledge bases. The set is orchestrated and runs like a production line, with quality control at the end.

The human operator's interface is a fish tank. Every agent in execution, reasoning on display, auditable outputs. It runs on demand, with data under control. Two ways to trigger the system: a batch of reports, or a single report.

How we thought about the risks

AI can get things wrong. The system was architected to handle that from day one.

• Its own quality control, automatically sending tasks back to the step that failed.
• Living knowledge bases. An internal mini-chat lets the operator update context, point to the right knowledge base, spell out a rule in more detail. The solution evolves with the team and gets better every day.
• Human validation on the way out, in a short window, focused on the quality of the decision.
• Transparent history, automatic retry on isolated failures, manual regeneration whenever the operator sees fit.

Result

The problem was solved at the source. The new process takes a few minutes a day from one human operator who absorbed the function, it contributed considerably to shortening the time to resolve bugs reported by users, and it freed dozens of team hours previously spent triaging possible problems, now available to focus on what actually matters and produces strategic results.