Para empresas que querem crescer com controle

Um sistema para operar sua empresa com IA.

Vendas, marketing, atendimento, operação, financeiro e inteligência trabalhando sobre o mesmo contexto — para sua empresa ganhar escala sem perder controle.

Sua empresa inteira. Uma operação. IA trabalhando.

Ver a Centriu funcionando

Para empresas de qualquer setor que querem crescer com estrutura, controle e inteligência.

Representação ilustrativa do trabalho em execução

O problema

Sua empresa não deveria operar em pedaços

Não é falta de ferramenta. É que cada ferramenta resolve um pedaço, e ninguém é dono do todo. O custo disso não aparece numa fatura — aparece no mês seguinte.

Sistemas que não se falam
O mesmo dado é digitado de novo — e cada cópia conta uma história diferente.
Dados duplicados
Ninguém sabe qual versão é a verdadeira na hora de decidir.
Conversas perdidas
O cliente repete o contexto a cada canal e a cada pessoa.
Tarefas espalhadas
O trabalho vive em planilhas, mensagens e na memória de alguém.
Decisões sem contexto
A escolha é feita com o recorte que estava à mão, não com o que importava.
Automações desconectadas
Cada ferramenta automatiza um pedaço e ninguém enxerga o todo.

Nenhum desses problemas se resolve comprando mais um software. Eles se resolvem quando a operação inteira passa a trabalhar sobre o mesmo contexto.

A resposta

Tudo trabalha sobre o mesmo contexto.

A Centriu não é uma coleção de produtos. É uma plataforma em que clientes, áreas e agentes leem e escrevem no mesmo lugar.

Cliente 360

Um contexto, não vários cadastros

Cada conversa, tarefa, campanha, cobrança e decisão fica ligada ao cliente e à operação — não a um sistema isolado.

Clientes
Comercial
Atendimento
Operação
Financeiro
Marketing
Inteligência
Agentes
Consultoria

As áreas abaixo são partes da mesma operação, não produtos separados. Elas compartilham conta, permissões e histórico.

IA que trabalha — não um chatbot ao lado

A inteligência artificial da Centriu participa da operação: entende contexto, prepara trabalho, executa rotinas e pede aprovação quando importa.

Entende o contexto

Lê a operação, o cliente e o histórico antes de propor qualquer coisa.

Prepara o trabalho

Redige, organiza, calcula e deixa pronto para revisão humana.

Executa rotinas

Roda o que é repetitivo dentro dos limites definidos pela empresa.

Recomenda a próxima ação

Cruza áreas, identifica prioridade e mostra o motivo da recomendação.

Pede aprovação

O que é sensível passa por uma pessoa antes de valer. Sem exceção silenciosa.

Mantém histórico e aprende

Registra o que aconteceu e usa o resultado para melhorar a próxima decisão.

O que a Centriu faz

Uma plataforma, várias frentes de trabalho. Tudo no mesmo contexto, com a IA participando do que dá para acelerar.

Comercial

CRM, pipeline, oportunidades, propostas, follow-up e automações.

Atendimento

WhatsApp, Instagram, Messenger, chat do site e e-mail no mesmo contexto.

Operação

Tarefas, responsáveis, prazos, aprovações, agenda e capacidade.

Financeiro

Contas, cobranças, caixa, fiscal, margem, IR, orçamento e inteligência econômica.

Marketing

Planejar, produzir, aprovar, publicar e medir conteúdo e campanhas.

Inteligência

Painéis, alertas, previsões, recomendações e leitura executiva.

Agentes

Rotinas executadas continuamente pela IA com controle e aprovação.

Consultoria

Diagnóstico, estratégia, transformação, acompanhamento e especialistas.

Para quem é

Para empresas que querem crescer — e crescer certo.

A Centriu faz sentido quando o volume aumenta e a estrutura precisa acompanhar. Não é sobre setor nem tamanho: é sobre a operação conseguir sustentar o próximo estágio.

As vendas crescem, mas o processo não acompanha.

As áreas trabalham separadas e o cliente sente.

A operação depende de pessoas específicas.

O financeiro ficou complexo e o caixa perde visibilidade.

O atendimento cresce em volume e em canais.

A IA entra sem contexto, controle ou histórico.

Se a empresa ainda não começou a crescer, a Centriu também ajuda a preparar a estrutura para o primeiro salto.

Ver a Centriu funcionando

Consultoria

Tecnologia sozinha não resolve uma operação mal desenhada.

A Centriu combina tecnologia, inteligência, método e acompanhamento. A consultoria diagnostica, desenha, implanta e acompanha — com evidências, não com apresentação.

Diagnóstico e imersão na operação

Estratégia e prioridades

Roadmap de transformação

Desenho da arquitetura operacional

Implantação conduzida

Acompanhamento com evidências

Benchmarking e leitura de mercado

Especialistas, rede e inteligência coletiva

A participação de especialistas depende da solução e do contrato. Não é um item incluído automaticamente em toda contratação, e não prometemos acompanhamento humano ilimitado.

Veja a Centriu funcionando na sua operação

Uma conversa para entender onde a sua operação perde tempo, dinheiro ou capacidade — e o que a Centriu faria primeiro.

Ver a Centriu funcionando

problema

Approval Decision Audit-Trail and Atomicity Automation: An Indexed Column No Write Path Ever Filled

Centriu Axis's client-approvals table has carried a column recording exactly who responded to an approval decision. It has its own dedicated database index. This index was built to look answers up by it. This has been true for as long as the table itself has existed. Every one of the three independent code paths that ever wrote a decision to that table left that column empty every single time. These paths were the approval screen's own direct write, the calendar and deliverables edge function, and the batch-planning service. None of them ever set it. A column purpose-built, and specifically indexed, to answer "who approved this" had structurally never been able to answer it. The same investigation found the decision itself was never atomic. Approving or rejecting a single post ran as an unprotected sequence of up to six separate reads and writes across two tables. There was no database transaction and no row lock holding any of it together beyond a single conditional update. The fix replaces that sequence with one locked, transactional function per decision type. It takes a lock on the row before evaluating anything. It performs every related write as a single all-or-nothing transaction. As part of that same write, it finally stamps who responded. This closes a gap in a column that had been sitting there, indexed and unused, the whole time.

Quero resolver isso

An index is a promise that someone intends to ask this question later

Building a dedicated database index for a specific column is not a neutral, cost-free decision. It is a deliberate signal that someone expects that column to be queried, looked up, filtered, or reported on later. They are willing to pay the ongoing cost of maintaining that index to make those future queries fast. An index on an empty column is a promise nobody kept. The infrastructure to answer a question was built and maintained. But the one thing that would let it actually answer that question — a value ever being written into the column at all — never happened.

Building a dedicated database index for a specific column is not a neutral, cost-free decision. It is a deliberate signal that someone expects that column to be queried, looked up, filtered, or reported on later. They are willing to pay the ongoing cost of maintaining that index to make those future queries fast. An index on an empty column is a promise nobody kept. The infrastructure to answer a question was built and maintained. But the one thing that would let it actually answer that question — a value ever being written into the column at all — never happened.

Quero resolver isso

How three independent write paths shared one gap, and how a single locked function closed it

The client-approvals table's own schema has carried a column recording who responded to a given decision. This schema is captured in a dedicated reference snapshot. This is because the table itself predates the project's migration history. The column has its own purpose-built index. This has been true for the table's entire life. Confirming whether that column was actually ever populated meant checking every place that ever wrote a decision into the table. It meant not assuming the most obviously relevant one had it covered. These places were the approval screen's own direct database write, which set only the decision's status and the time it was made. Another was the edge function handling calendar and deliverable decisions. This was thirteen hundred lines, searched directly for the column's own name — zero matches. The third was the separate service handling batch planning-day approvals. This was searched the same way — zero matches. Three independently written, independently maintained code paths, spanning years of the table's use, all wrote decisions into the identical table. Not one of them had ever set the one column specifically built and indexed to record who made the decision.

The same investigation traced exactly how a single approve or reject action actually executed. It found the decision itself was never a single atomic operation. Approving one post ran as an ordered sequence of database calls from application code. It read the approval record to find the related task. It wrote the approval as approved. This was protected only by a check that it was still pending at the time. It read the workspace's own configured service-stage name. It read the related task's own details. It wrote the task's stage and status. Separately, and as a best-effort, it inserted a notification for the internal team. This was six steps and two tables. Zero of it was wrapped in a shared database transaction. No row lock was held across any of it beyond the single conditional update in step two. That specific update genuinely protected against the one race it was built for. This was two people deciding the same item within the same instant. But nothing protected the OTHER five steps from running inconsistently with each other if any one of them behaved unexpectedly.

The fix addresses both findings with the same structural change. This is one dedicated, security-scoped database function per decision type. Examples are a standalone post, a planning day, a batch of planning days, a finished deliverable, an internal review. Each function opens by taking an explicit lock on the specific approval row before evaluating anything else. Nothing else can act on that same row until the function finishes. Every related write for that one decision happens inside that same function. This includes the approval's own status, the connected task or content item, and now the identity of whoever actually made the call. It happens as a single transaction. It either all commits together, or none of it does. This closes the six-step, two-table sequence into one atomic unit. The responding identity is available directly, inside the database. This is at the exact moment the decision is being recorded. So, the column that had sat indexed and empty since the table's own creation is finally set. This is not a separate afterthought bolted onto the old flow. It is one more field written by the same atomic operation that decides everything else.

Ver como funciona

What is actually built today

A dedicated database function per decision type performs the ENTIRE decision. This includes status change, connected record updates, and who-responded. It does this as one atomic transaction.
Each function takes an explicit row lock before evaluating or changing anything. This closes the exposure window that previously existed. That window was across a six-step, un-transacted sequence run from application code.
The column recording who responded to a decision is now set by every decision path. This is for the first time in the column's own lifetime. This column was present in the table's schema, with its own dedicated index, since before this fix.
A batch decision runs as a single request. This is for approving every remaining planning day in a month in one action. It evaluates each item through the identical per-item function. It skips anything already decided. It does not fail the whole batch on one already-answered item.
An approver can now leave a written comment as part of approving an item. This is a new column added by the same migration. The previous schema had no field to hold this at all.
The frontend no longer performs any of the multi-step orchestration itself. It calls the appropriate decision function once. It reads back a structured result. It does not sequence reads and writes across two tables from application code.

Conhecer os recursos

What changes operationally

Every client approval decision in Centriu Axis now runs as a single, row-locked, all-or-nothing transaction. This is instead of an unprotected multi-step sequence across two tables. As part of that same write, a column is finally set on every decision going forward. This column had been present and indexed on the approvals table since before this fix. But it was never once populated by any of its three independent write paths.

Every client approval decision in Centriu Axis now runs as a single, row-locked, all-or-nothing transaction. This is instead of an unprotected multi-step sequence across two tables. As part of that same write, a column is finally set on every decision going forward. This column had been present and indexed on the approvals table since before this fix. But it was never once populated by any of its three independent write paths.

Quero esses resultados

A decision recorded, with nobody able to say who made it (illustrative framing of the actual measured finding)

A team lead reviews a client's approval history. This is to understand a recent dispute over who signed off on a specific post. The approval record clearly shows the item was approved, and when. The column built specifically to record who is sitting right there. It is indexed for exactly this kind of lookup. It is empty. It has been empty for every decision ever recorded in that table. This is regardless of which of the three code paths made it. This is because none of them had ever set it. After the fix, the identical lookup on a new decision returns a real answer. This is because the column is now set by the same atomic operation that records everything else about the decision.

Conversar sobre meu caso

How to start

Começar agora

Frequently asked questions

Was the "who responded" column really never populated?

It was confirmed directly by searching each of the three independent code paths that ever wrote a decision into the table for the column's own name. There were zero matches in any of them. This is despite the column and its own dedicated index existing on the table the whole time.

Why does an unused, indexed column matter?

A dedicated index is an ongoing cost. This cost is paid on every write to the table. It is specifically so that column can be looked up quickly later. Paying that cost while the column is never actually filled means the underlying question it was built to answer could never be answered.

What does "the decision was never atomic" mean in practice?

Approving or rejecting a single post ran as up to six separate database reads and writes across two tables from application code. There was no shared transaction. There was no row lock protecting the sequence beyond a single conditional update.

What is the fix?

One dedicated database function per decision type now locks the relevant row. It performs every related write as a single all-or-nothing transaction. It records who responded as part of that same write.

Does this recover historical attribution data?

No. Decisions made before this fix have no responding identity to recover. The column is populated going forward. This starts with decisions made after the fix.

What does Centriu Axis cost?

It is sold by subscription with a published starting price. Exact current values are on the central pricing page.

Ainda tenho dúvida

See how Centriu Axis makes every approval decision atomic and attributed

Centriu Axis's client-approvals table has carried a column recording exactly who responded to an approval decision. It has its own dedicated database index. This index was built specifically to look answers up by it. This has been true for as long as the table itself has existed. Every one of the three independent code paths that ever wrote a decision to that table left that column empty every single time. These paths were the approval screen's own direct write, the calendar and deliverables edge function, and the batch-planning service. None of them ever set it. A column purpose-built, and specifically indexed, to answer "who approved this" had structurally never been able to answer it. The same investigation found the decision itself was never atomic. Approving or rejecting a single post ran as an unprotected sequence of up to six separate reads and writes across two tables. There was no database transaction and no row lock holding any of it together beyond a single conditional update. The fix replaces that sequence with one locked, transactional function per decision type. It takes a lock on the row before evaluating anything. It performs every related write as a single all-or-nothing transaction. As part of that same write, it finally stamps who responded. This closes a gap in a column that had been sitting there, indexed and unused, the whole time.

Quero resolver isso