Pular para o conteúdo
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.

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

Painel ilustrativo do Sistema Centriu com sete frentes trabalhando: atendimento, comercial, operação, agentes, inteligência, conteúdo e marketing. Cada frente mostra o trabalho concluído ou o próximo passo.

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.

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.

Pular para o conteúdo

problema

Partial-Update Data-Loss Protection Automation: When Saving Four Fields Used to Erase Twenty

A wide-ranging audit of 13 screens in Centriu Run's infrastructure settings found what its own findings called the most severe defect. Two screens each save only 4 specific fields. These fields are a client's monthly value, contract type, contracted scope and expected complexity. These screens were routing through a generic update function. This function rebuilds a client's ENTIRE record on every save. It fills in literal defaults like empty string, empty array, false, null for every field the caller didn't explicitly touch. Nested groups like contact info, social accounts and address were always rebuilt from those defaults. They were not left alone. Every single save on either screen silently erased a client's contact details, address, social accounts, logos, brand colors and legal name. This was measured directly against real data. 22 of the organization's 23 active clients had contact information on file. This means nearly the entire active client base was exposed. The fix replaces the generic update path. The new path includes a column in the update only when its own source field was actually present in the request. It rebuilds a nested group of fields only when at least one of its own members was included. This closes the exposure. It does not change how any screen that legitimately edits those fields already works.

Partial-Update Data-Loss Protection Automation: When Saving Four Fields Used to Erase Twenty

Why a function built for "save everything" is dangerous the moment something only saves a little

A function that assembles a complete database record from a client object is the natural, obvious way to handle a form. This form genuinely edits every field on that record. It works perfectly for exactly that case. The danger appears the instant a second, narrower screen reuses that same function. It saves only a handful of fields it actually cares about. If the function's own logic can't tell the difference between "this field is genuinely empty" and "this field was never mentioned," it has no way to leave anything alone. It either saves everything correctly, or it silently overwrites everything else with a default. Which one happens depends entirely on whether the caller happened to populate every field. It does not depend on what the caller actually intended.

  • A function that assembles a complete database record from a client object is the natural, obvious way to handle a form. This form genuinely edits every field on that record. It works perfectly for exactly that case. The danger appears the instant a second, narrower screen reuses that same function. It saves only a handful of fields it actually cares about. If the function's own logic can't tell the difference between "this field is genuinely empty" and "this field was never mentioned," it has no way to leave anything alone. It either saves everything correctly, or it silently overwrites everything else with a default. Which one happens depends entirely on whether the caller happened to populate every field. It does not depend on what the caller actually intended.

How Centriu Run closed the gap with a save path that only touches what changed

The defect surfaced through a systematic audit of all 13 screens under Run's infrastructure settings. The audit's own summary described it as looking for problems worse than the classic empty-shell pattern. This pattern includes fake data and decorative buttons that do nothing. The audit found exactly that: real, working screens with defects that were actively harmful rather than merely incomplete. The most severe of them: a "Save data" button on two specific screens. These screens are an org-level strategic overview and a deal-intelligence panel. Each saves exactly 4 numeric and categorical fields relevant to their own purpose. Neither screen touches a client's contact details, address, social handles, or brand assets at all. But both routed their save through the same shared update function. This function is used everywhere else in the client-management area. That function's existing behavior was to reconstruct the ENTIRE client record from whatever was passed in. It filled in defaults for anything missing.

This was measured directly against the organization's real client data. 22 of 23 active clients had a populated contact-information field. The shared function always rebuilt that field. It also rebuilt social accounts and address. It did this from source fields that these two specific screens never populate. Every single click of "Save data" on either screen was silently erasing contact info, address, social handles, logos, brand colors and the client's legal name for whichever client was open at the time. This happened regardless of how carefully the person clicking save had filled in the 4 fields the screen actually shows. Notably, the file's own pre-existing code already carried a comment warning about exactly this danger. This warning was attached to a different, narrower function. The warning existed in the codebase. But the generic path everything else actually used remained exposed.

The fix replaces that generic path, for updates specifically. It uses a function that checks field by field. It uses a direct existence check rather than inferring intent from a value. It checks whether each source field was actually present in the update request. It includes the corresponding database column only when it was. For the nested groups (contact info, social accounts, address), the same discipline applies at the group level. The group is only reconstructed, and only sent, when at least one of its own component fields was actually present in the request. When none were, the entire group is omitted from the update. This leaves whatever the database already holds untouched. The one documented exception is called out directly in the fix's own comment. A caller that intentionally edits only ONE field within a nested group (say, only email inside contact info) will still overwrite that group's sibling fields. This is precisely why the single existing caller that legitimately edits those blocks — the full client-editing form — is confirmed to continue sending the complete object for any group it touches, exactly as it always has.

What is actually built today

  • A dedicated partial-update path includes a database column in a save only when its corresponding source field was actually present in the incoming request. It is not merely non-empty, but explicitly present.

  • Nested field groups (contact info, social accounts, address) are rebuilt and sent only when at least one of their own component fields was present in the request. Otherwise, they are left out entirely. This leaves the stored value untouched.

  • The narrow, 4-field save screens (the strategic overview and deal-intelligence panel) now genuinely touch only those 4 fields in the database. They have zero effect on any other part of the client record.

  • The one legitimate caller that edits contact info, social accounts or address in full (the complete client-editing form) is confirmed unchanged. It already sends the complete object for any group it touches.

  • The defect was measured directly against real production data before the fix. 22 of 23 active clients had populated contact information at risk. It was not treated as a purely theoretical risk.

  • The dangerous, full-record-rebuild function is kept in place for the one case it was always correct for. This is a genuine full-record insert or comprehensive edit. It was not removed outright and rebuilt from scratch.

What changes operationally

A narrow, purpose-built save screen can no longer silently destroy data. It was never designed to touch this data in the first place. The blast radius of a save is now limited to the fields that screen actually edits. This matches what anyone using it would reasonably expect. The fix is a shared function. It is used by the update path generically. Any future screen built the same way inherits the same protection automatically. It does not need its own special fix the next time a narrow screen is added.

  • A narrow, purpose-built save screen can no longer silently destroy data. It was never designed to touch this data in the first place. The blast radius of a save is now limited to the fields that screen actually edits. This matches what anyone using it would reasonably expect. The fix is a shared function. It is used by the update path generically. Any future screen built the same way inherits the same protection automatically. It does not need its own special fix the next time a narrow screen is added.

Updating a deal's expected complexity without touching anything else (illustrative scenario, not a real client)

Someone opens the deal-intelligence panel for an existing client. They change only the expected-complexity field before saving. Before the fix, that single field change would have silently rewritten the client's entire contact block, address and brand assets back to blank defaults. This would happen the moment the save request reached the database. This is true even though none of those fields were ever shown on that screen. After the fix, the update touches only the one column that actually changed. Everything else on the client's record remains exactly as it was.

Updating a deal's expected complexity without touching anything else (illustrative scenario, not a real client)

How to get started

Frequently asked questions

What was the actual measured impact of this defect?

Two screens saving only 4 unrelated fields were, on every save, silently erasing contact info, address, social accounts, logos, brand colors and legal name. This was measured against real data. 22 of the organization's 23 active clients had populated contact information at risk.

Why didn't this show up as an obvious error?

The save itself succeeded from the database's point of view. A normal update happened. It just included unintended default values for fields the affected screens never meant to touch.

How does the fix know which fields to actually include in an update?

It checks, field by field. It checks whether the source field was genuinely present in the incoming request. It does not just check if it has a value. It includes the corresponding database column only when it was.

What about grouped fields like contact info or address?

A nested group is only rebuilt and sent when at least one of its own component fields was present in the request. If none were, the entire group is left out. The stored value is left untouched.

Can I still clear just one field inside a group, like removing only a phone number?

Not as an isolated operation today. Editing any field within contact info, social accounts or address goes through the full client-editing form. This form sends the complete group for any block it touches.

What does Centriu Run cost?

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

See how Centriu Run protects client data from partial-update overwrites

A wide-ranging audit of 13 screens in Centriu Run's infrastructure settings found what its own findings called the most severe defect. Two screens each save only 4 specific fields. These fields are a client's monthly value, contract type, contracted scope and expected complexity. These screens were routing through a generic update function. This function rebuilds a client's ENTIRE record on every save. It fills in literal defaults like empty string, empty array, false, null for every field the caller didn't explicitly touch. Nested groups like contact info, social accounts and address were always rebuilt from those defaults. They were not left alone. Every single save on either screen silently erased a client's contact details, address, social accounts, logos, brand colors and legal name. This was measured directly against real data. 22 of the organization's 23 active clients had contact information on file. This means nearly the entire active client base was exposed. The fix replaces the generic update path. The new path includes a column in the update only when its own source field was actually present in the request. It rebuilds a nested group of fields only when at least one of its own members was included. This closes the exposure. It does not change how any screen that legitimately edits those fields already works.