Devs kept stopping work to investigate payment errors. Now that time goes into the product.

The context

Tempo is a concierge that runs over WhatsApp. The client asks for something, an AI triages it into payment or task, and if it's a payment the AI tries to execute it on its own. If it's a task, the AI chases the missing information until it can open a card in a human assistant's kanban.

I was the company's only PM. Three squads, 12 engineers, 30 operations assistants, around 400 clients. The business goal that quarter was easy to state: grow the value transacted on the platform.

To keep track of everything, assistants had a notification screen in the Cockpit, the internal panel, split into three columns: unread conversations, task notifications, and payments due or overdue in the last three days.

The problem nobody was measuring

That screen had been designed for manually sent payments. As we automated more of the sending, it got less and less useful, and an executed payment didn't even leave the list on its own.

The bigger hole was elsewhere. When a payment failed, that information showed up nowhere an assistant could reach. She only found out if the client complained, which sometimes took days. And most of the time the client wasn't even the first to notice: it was his payee chasing a transfer that never landed. So our client looked bad in front of a third party because of our platform.

Three costs stacked up at once. Client trust. Money sitting still, because a failed payment is value that stops circulating. And engineering capacity burned on investigation instead of product.

Discovery, and what only showed up sitting beside them

Part of the diagnosis I already had, because I read the assistants' tickets every day. What actually changed the diagnosis was roughly 10 hours sitting next to them, watching the work happen. The whole process took two weeks: observation, mapping the errors in the payment provider's documentation, writing the PRD, and validating with seven of the thirty assistants.

The assistants worked on a single monitor, usually a small one. There was no notification header visible from any screen. To resolve a payment they had to leave Home, open that specific client's screen, fix it and come back. In practice that meant a pile of open tabs and losing your place halfway through.

Validating with those seven assistants changed the design before it became code. I was going to make the payments tab the default view for everyone. They showed me that each of them worked at a different rhythm, and what shipped instead was saving each person's last used filter.

What I chose not to build

The obvious answer was a global notification header, visible from any screen on the platform. It was also the right answer in the abstract, and it was the first thing I wanted to do.

I dropped it. Building that from scratch at that moment cost more engineering time than the problem could wait for, on a team already losing 10 hours a day to that same problem. So I changed the question. Instead of "what's the ideal solution", it became "how do I turn the screen that already exists into something that solves the real problem".

It was a deliberate trade-off and it has a price. Outside that one screen, an assistant still sees no notifications at all. The global header is still the right evolution, just later, with the engineering queue free and the stuck money moving.

From a notice board to an operations hub

The decision was to change the concept of the whole screen rather than polish the notification: from a place where the assistant finds out to a place where she resolves.

• Two resizable columns

  Conversations on one side, notifications on the other, with tabs for tasks, payments and reminders. Clicking a conversation collapses the notifications, clicking a notification collapses the conversation. A small monitor could finally hold both contexts.

• Resolution without leaving the screen

  The conversation opens right there, no jump to the client's screen. The payment brings every resolution action with it, immediately.

• 28 errors mapped across Pix, Boleto and TED

  I went through the Celcoin documentation and mapped every possible error with the correct action for each: resend, un-expire, edit missing information. Three of them accounted for most of the volume.

• Technical error translated into a human action

  The notification title explains the problem in plain language, with amount, client and date visible, and the fix right underneath. No API return codes in front of the person doing the work.

• The PRD as the contract with engineering

  Here I didn't build the final version alone, because I needed engineering to wire it to real payment data. I wrote a table in the PRD with all 28 errors (title, explanation, action) and replicated every one of them in a full Lovable prototype, so the devs could see the exact behaviour of each screen before implementing.

Closing the loop with AI

With the screen live, I automated the parts that needed no human at all. When a payment was one day out and some information was missing, the AI chased the client by itself. No reply within a few hours, it chased again, and only then raised a notification for an assistant to push harder.

When an error did happen, the AI told the client immediately, with the way out already attached: "this payment couldn't go through because it was outside boleto processing hours, shall I schedule it for the next business window?"

The AI ended up resolving around 80% of errors on its own. The assistant's queue stopped receiving what the machine could already handle, and roughly 15 notifications a day were left for human treatment, counting the errors the AI couldn't resolve and the preventive chases that needed a person leaning on them.

What changed

What I'd do differently

I instrumented the wrong metric. I never really measured adoption, because I blocked the old screen and everyone moved to the new one by force. That's substitution. The metric I should have shipped alongside the feature was average time between an error happening and an error being resolved, and I didn't ship it. The part that stings: at Qulture.Rocks I built the exact process that forces a PM to deliver tracking and a monitoring screen with every feature. I didn't apply it to myself.

The launch order created rework. I shipped the hub first and the AI automation after, because the lack of visibility was already costing real money and centralising it was urgent. It was the right call for the business and it still had a cost: some of the notifications I'd designed for the assistant stopped making sense once the AI started resolving those cases itself.

And there was a regression that was mine. During rollout, notifications for unapproved payments stopped displaying for one cohort, and those assistants spent a few days not chasing client approvals. I fixed the bug, but the bug wasn't the real damage. The real damage was the doubt that stayed: "what else am I not seeing?" I opened a direct channel for them to report anything until the full QA was done. The four-phase rollout, from leadership to 5, then 10, then 30 assistants, is the reason this hit a small group instead of the whole operation.