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

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.

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

problema

Consent-Revocation Suppression Integrity Automation: Whoever Revoked Kept Being Contacted

When a contact revoked marketing consent through Centriu Flow, the handler tried to stop future outreach. It tried to write a record using the contact's internal ID and a consent-type field. But the real suppression table uses a contact's e-mail or phone number directly. It also pairs which of the two it is. It has no consent-type column at all. Every one of these writes was rejected by the database. The calling code did not check the result. The interface reported the revocation as processed. But the actual suppression record was never created. This means a contact who explicitly revoked consent remained eligible for future outreach. They were as eligible as before they revoked it. The fix looks up the contact's e-mail or phone directly. It writes the suppression record under the fields the table actually uses. This closes the gap between a person's choice and what the system did.

Quero resolver isso
Consent-Revocation Suppression Integrity Automation: Whoever Revoked Kept Being Contacted

The interface said "revoked." The database never received a row that said the same.

A consent-revocation feature can be implemented correctly at every layer a person actually sees. This includes a clear toggle, a confirmation message, and an updated status on screen. But it can still fail entirely at the one layer nobody sees directly. This is whether the specific database write meant to enforce that choice actually succeeds. When that write is silently rejected, nothing downstream notices. The interface and the database tell two different stories. Only the database's version determines whether a message actually goes out.

  • A consent-revocation feature can be implemented correctly at every layer a person actually sees — a clear toggle, a confirmation message, an updated status on screen — and still fail entirely at the one layer nobody sees directly: whether the specific database write meant to enforce that choice going forward actually succeeds. When that write is silently rejected and nothing downstream notices, the interface and the database tell two different stories, and only the database's version is the one that determines whether a message actually goes out.

Quero resolver isso

How a database-level rejection with no visible symptom was traced back to a mismatched schema, and confirmed live

The consent-revocation handler's job is simple. When a contact revokes consent, it writes a record. Future outreach logic will check this record and refuse to act against it. The handler did exactly that. It just wrote the record using the wrong shape. It used the contact's internal ID and a field for the consent type. But the actual suppression table identifies a record by the contact's e-mail address or phone number directly. It is tagged with which of the two it is. It carries no field for consent type at all. The database's own schema enforces this strictly. So, every attempted write was rejected outright.

The fix changes how the write is structured. It now matches what the table actually expects. Before inserting a suppression record, the handler looks up the contact's e-mail and phone number directly. It writes the suppression keyed to whichever of the two identifies the revoking contact. It populates both the identity type and the identity value the table's own schema actually requires. This is a different lookup than the original code performed. It is not a renamed field on the same shape. This is because the suppression table was designed to identify a person by a reachable address. It was not designed by an internal record ID. A downstream send-check would not look up an internal record ID on its own.

This specific defect was found after a broader schema-comparison gate. This gate was built to catch a database write pointed at a table name that does not exist. It was extended to also check the shape of what a write sends. It compares field names, not just table names, against the live database's real schema. That extension found this defect. It also found several similar defects in the same investigation. The original, narrower version of the gate could not see any of these.

Ver como funciona

What is actually built today

  • When a contact revokes consent, Centriu Flow looks up that contact's e-mail address and phone number directly. It does not rely on an internal identifier the suppression table was never built to store.

  • The suppression record is written with the identity type and identity value fields the real table actually requires. This matches the table's own design, not an assumption about it.

  • A schema-comparison gate now checks field names. It does not just check table names. It checks every insert and upsert in the codebase. This extension found this specific defect and its close relatives in the same investigation.

  • The fix is a corrected identity lookup and write. It is not a new suppression mechanism. The same downstream send-check logic always meant to consult this table. It now has a real record to find.

  • This automation is specifically about the database write. This write turns a stated revocation into an enforced suppression. This is different from Centriu TrustOps's separate consent-governance and audit-trail layer. That is a different system entirely.

  • There is no change to how a contact revokes consent from their own side. The interface and confirmation flow they interact with were already correct. The fix is entirely on the write that used to fail silently underneath it.

Conhecer os recursos

What changes operationally

A contact who revokes marketing consent through Centriu Flow now has an actual suppression record. This record can be enforced. It is created at the moment they revoke consent. This closes a gap where the interface reported success. But the underlying database write silently failed every time.

  • A contact who revokes marketing consent through Centriu Flow now has an actual, enforceable suppression record created at the moment they revoke it — closing a gap where the interface reported success while the underlying database write silently failed every time.

Quero esses resultados

A revocation that looked processed and changed nothing (illustrative framing of the actual measured finding)

A contact clicks to revoke marketing consent. They see a confirmation. They reasonably assume the matter is settled. Before the fix, the suppression record meant to enforce that choice failed to write. It failed silently. The very next campaign still considered that contact eligible. The revocation changed nothing about what actually happens next. After the fix, the identical revocation finds the contact's e-mail or phone directly. It writes a suppression record the send-check logic can actually find. The next campaign correctly excludes them.

A revocation that looked processed and changed nothing (illustrative framing of the actual measured finding)
Conversar sobre meu caso

How to start

Começar agora

Frequently asked questions

Why did a consent revocation not actually stop outreach?

The handler tried to write a suppression record using a contact ID and a consent-type field. But the real suppression table identifies records by e-mail or phone number. It has no consent-type column. Every write was rejected, silently.

How was this found?

A schema-comparison gate was built to catch writes pointed at tables that do not exist. It was extended to also compare field names, not just table names, against the live database schema. This defect and several related ones surfaced from that extension.

Is this the same as Centriu TrustOps's consent and compliance features?

No. TrustOps provides a separate governance and audit-trail layer. This automation is specifically the database write inside Flow. It turns a revocation into an enforced suppression.

Were any revocations before this fix lost permanently?

The suppression records that failed to write before the fix were never created. A workspace concerned about a specific past period should review its own historical revocation requests directly.

Does a contact need to do anything differently to revoke consent now?

No. The interface and confirmation flow a contact interacts with were already correct. Nothing about how a person revokes consent has changed.

What does Centriu Flow 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 Flow enforces a consent revocation the moment it happens

When a contact revoked marketing consent through Centriu Flow, the handler tried to stop future outreach. It tried to write a record using the contact's internal ID and a consent-type field. But the real suppression table uses a contact's e-mail or phone number directly. It also pairs which of the two it is. It has no consent-type column at all. Every one of these writes was rejected by the database. The calling code did not check the result. The interface reported the revocation as processed. But the actual suppression record was never created. This means a contact who explicitly revoked consent remained eligible for future outreach. They were as eligible as before they revoked it. The fix looks up the contact's e-mail or phone directly. It writes the suppression record under the fields the table actually uses. This closes the gap between a person's choice and what the system did.

Quero resolver isso