Before AI, the Reorganization: How Operations Became a System at CERC
← Back to Articles

Before AI, the Reorganization: How Operations Became a System at CERC

TL;DR — In 2024, CERC’s operations had a clear symptom: the same situation could be handled in five different ways depending on which analyst picked it up. Operational knowledge lived scattered, inside each person’s head. Instead of layering AI on top of the problem, we first reorganized the team around ownership per participant. AI came in afterward, on two fronts backed by the same institutional knowledge base: Madonna, which assists the analyst inside HubSpot, and dott.ai, a certification platform that guides participants in runtime. Average response time dropped from 9.4 to 4.1 hours with Madonna in the flow. Onboarding and certification of new participants went from over 60 days to an average of 5.


In 2024, we realized we were getting good at something bad: handling the same situation in five different ways, depending on which analyst picked it up.

The obvious move would have been to put AI on top of the problem, which is what plenty of companies started doing that year. We took a different route. Before turning on any agent, we reorganized who responded to what. Operational knowledge, which lived scattered inside each analyst’s head, was consolidated by participant: each person became the owner of a fixed set, with depth on their products and flows. Only with that model already in place did AI come in, to scale what remained as a bottleneck.

The side effect was more interesting than we expected: each analyst became a curator of an agent that carries their domain. The people running the system started shaping it as well.

What follows is how this was built on two fronts, backed by the same institutional knowledge base: Madonna, in day-to-day operations, and dott.ai, in participant certification.


Knowledge lived in people’s heads

The knowledge that should have been institutional lived fragmented inside each analyst’s head. Each person accumulated context on their own, without that context reaching anyone else. It wasn’t a people problem or a competence problem; it was an organizational one. And in an operation that holds up critical infrastructure of the Brazilian financial market — where systemic rules are dense and change all the time — that compromises compliance directly. It’s not just slowness.

Hiring more people would only multiply the fragmentation. So we decided to reorganize the structure before touching any tools.


Ownership per participant

The generic model, where any analyst could answer for any participant, gave way to a team of specialists. Each person became the owner of a fixed set of participants, with depth on the products, flows and specifics of that slice. Variability dropped immediately, context stopped being lost at every handoff, and decisions became more consistent.

A new bottleneck remained. The specialist’s time started being spent on information retrieval: documentation, history, current rules. All of that needed to be assembled before any decision. It was at that point, and only there, that AI became an appropriate solution.

Structure first. The agent later.


Madonna

Madonna is the agent we built in partnership with CERC’s Center of Excellence. She runs in a separate layer, but she delivers her recommendations inside HubSpot itself, which is where the analysts already spend their day. The person doesn’t need to open another tab or switch tools: the suggestion shows up next to the ticket.

Before generating a suggestion, Madonna gathers the context a human would reasonably want at hand: the rules that apply to the case, the participant’s history, the flows involved, and the current documentation. On top of that, she proposes a course of action. The analyst reads, critiques, digs deeper where something feels missing, and decides what goes back to the participant.

This supervised model is intentional, not transitional. It’s how the team calibrates trust in the agent before releasing direct responses to the customer. Madonna is on the edge of that transition right now: after a long validation period, she should soon start responding directly to participants in the scenarios where the accumulated evidence already shows she gets it right.

What changes the work of whoever operates the most, though, is something else. Each analyst is responsible for developing and evolving a specific domain of the agent. Madonna’s knowledge is segmented by product, operational flow, and participant profile, and each person on the team is the active curator of their own piece. The agent ends up being a distributed construction, maintained by the same team that uses it.

The effect of all that shows up in the numbers in a somewhat unusual way. Between April 30 and May 5, with Madonna offline for a few days, the average response time on support tickets sat at 9.4 hours. The following week, with version 2 back in the flow, it dropped to 4.1 hours: more than a 56% reduction, directly attributable to the agent’s return. Today, 100% of tickets in the Production Support and Onboarding Support teams receive from her a suggested first response and a recommended runbook.


How Madonna learns

Most of Madonna’s evolution doesn’t come from learning after the fact, but from anticipation. Whenever a relevant change is about to take effect (regulatory, product, or operational), the team triggers a standard cycle before the change becomes a problem:

Anticipate → Structure → Teach → Assist → Refine

In practice, that means structuring the new scenarios, creating the corresponding skills in the agent, developing the playbooks, standardizing how to decide, updating CERC Docs, and communicating with the market. By the time the scenario actually shows up in a ticket, Madonna already has what she needs to suggest a path.


dott.ai

Madonna acts on day-to-day operations. There’s a second front, with a different dynamic: certifying participants who are about to connect to CERC.

That process scales poorly by nature. The more participants want in, the more manual follow-up and validation cycles are needed. The answer was to adopt dott.ai, an AI-integrated certification platform — a Vericode product, in use at CERC and backed by the same institutional knowledge base that powers Madonna.

dott.ai operates at runtime over the certification environment. It intercepts the transactional events the participant fires while running the scripts, compares them against the expected behavior, and returns contextual feedback at the very moment the test is happening. It doesn’t only validate technical integration errors: it also evaluates whether the operational behavior matches the systemic rules, the business scenarios, and the flows that operations defined. When it makes sense, it offers reference payloads and examples so the participant can see what the system would expect.

In practice, the certification script becomes an executable scenario for learning: the participant learns about the system while being tested by it, without depending on someone at CERC watching the whole time. Once the script ends, dott.ai itself consolidates the patterns of doubts and deviations that came up, feeding documentation and the next cycles.

The platform’s content — the scenarios, the validation rules, the expected flows — was designed by the Operations team itself, from accumulated experience with real participants.

The gain shows up directly in how fast the market can connect: the onboarding and certification cycle for a new participant dropped from over 60 days to an average of 5 days — more than 90% reduction.


What changed for the team

This model shifts what’s expected of people working in Operations. Fluency in AI tools, automation, and data analysis became part of the team’s job, because without it no one can be an effective curator of the knowledge that feeds the agents.

To keep up with that requirement, we set up a continuous training program with HR. The idea is simple: training isn’t an isolated event or a separate perk; it’s part of the team’s normal work.


Why this is hard to copy

The main obstacle to reproducing this model isn’t the technology itself — anyone can buy the same tools. What takes time is the rest: operational knowledge needs to be structured and evolved with discipline, and operations needs the mandate (and the culture) to shape its own system, instead of handing that responsibility off to the technology team.

None of this shows up at once, and no AI package comes with it built in. It only works when the organizational model has been corrected before the technology comes in.


Where Operations sits now

For a long time, Operations in financial infrastructure was treated as a reactive area, the place where someone responds when something goes wrong. The model described above no longer fits that definition. Operational knowledge has become a system, sustained by an agent the team itself maintains. Part of the work is anticipating problems that haven’t even arrived. And a slice of how CERC’s system gets defined now happens inside the team that knows the ecosystem best, because they operate it every day.


CERC operates the infrastructure of the Brazilian financial market for receivables registration — a system where correctness, scale and reliability are non-negotiable. If you want to build Operations as a system, with AI entering as a scaling mechanism rather than a packaged solution, we’re hiring.


This post was written by: Iasmine Massignan Rinaldi — Operations, CERC.