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

Deal Lifecycle Automation Rule Execution and Crash-Safe Retry Automation: Every Run Ends Completed, Failed or Skipped — Never Lost

A rule that is supposed to fire "when a deal goes stale" or "when an activity is overdue" is only actually useful if it is guaranteed to run exactly once. It must keep working after a crash. It must leave a record either way. Centriu Orbit lets a team define automation rules against four real triggers. These are: a deal created, a deal moved to a new stage, a deal gone stale past its own threshold, or an activity that missed its due date. It has condition groups checked against the deal itself. It has a fixed set of four real actions. These are: create a linked follow-up activity, log a note on the deal's own timeline, change the deal's priority, or pass its owner to another person. A background worker claims a batch of queued rule runs atomically. This means two worker passes can never grab the same run. It re-checks the conditions at the moment it actually acts. This is not just when the rule was written. It executes every action in the run together. If any single action fails, the entire run is marked failed with the specific error kept. There is never a silent partial result. A run stuck mid-execution for more than five minutes is automatically re-queued. This can happen up to three total attempts. After that, it is marked permanently failed with a stated reason. It is not retried forever or quietly dropped.

Quero resolver isso

Why "the rule fired" needs to mean something specific

A CRM automation rule that "usually" works is worse than no automation at all. This is because a team stops manually checking the thing it was built to replace. The real engineering question behind any such rule is never just "can it evaluate a condition and take an action." It is what happens when two background passes run close together. It is what happens when the worker crashes mid-action. It is what happens when the deal the rule was about to touch was deleted a second before it got there. Centriu Orbit's automation-rule engine is built around those specific failure modes. It is not just built for the happy path.

A CRM automation rule that "usually" works is worse than no automation at all. This is because a team stops manually checking the thing it was built to replace. The real engineering question behind any such rule is never just "can it evaluate a condition and take an action." It is what happens when two background passes run close together. It is what happens when the worker crashes mid-action. It is what happens when the deal the rule was about to touch was deleted a second before it got there. Centriu Orbit's automation-rule engine is built around those specific failure modes. It is not just built for the happy path.

Quero resolver isso

How Centriu Orbit executes and safeguards automation runs

A rule is defined against one of four triggers. These are: deal created, deal stage changed, deal stale past a configured number of days, or activity overdue past a configured number of hours. It has an optional set of condition groups. An "all" group requires every condition to match. An "any" group requires at least one. Each condition compares a deal field like value, priority or status against an operator and a value. It has an ordered list of actions from a fixed set of four. These are: create a linked follow-up activity, log a system note on the deal's own timeline, change the deal's priority, or pass its owner to another person.

When a trigger fires, a run is queued rather than executed immediately. A background worker then claims a batch of queued runs atomically. It uses a database-level locking mechanism. This guarantees no two worker passes can ever claim the same run. This replaces an earlier design that briefly allowed exactly that race. For each claimed run, the worker independently re-verifies that the automation still belongs to the same organization as the run. This is a defense-in-depth check that does not simply trust the join. It skips (rather than fails) the run if the rule has since been paused or the target deal or activity no longer exists. It re-evaluates the rule's conditions AT THIS MOMENT against the entity's current state. This is not the state it was in when the run was originally queued. Only if conditions still match does it execute every action in the run in order. If any single action fails, the entire run is marked failed with that specific error preserved. It does not report success for the actions that happened to work.

A run that gets stuck mid-execution is automatically detected. This happens if a worker instance crashed or timed out partway through. It is detected once it has sat in the "running" state for more than five minutes. It is then re-queued for the next pass. This can happen up to three total attempts. Beyond that, the run is marked permanently failed with a specific, stated reason. This way, a genuinely broken rule surfaces clearly instead of silently retrying forever or disappearing from view.

Ver como funciona

What is actually built today

Four real triggers: deal created, deal stage changed, deal stale past a configured threshold, activity overdue past a configured threshold.
AND/OR condition groups evaluated against real deal fields (value, priority, status) with comparison operators. These are re-checked at the moment of execution. This is not just when the rule was authored.
A fixed set of four real actions. These are: create a linked follow-up activity, log a system timeline note, change deal priority, pass deal owner to another person. Each one is a confirmed, real database write, not a simulation.
An atomic, database-locked claim step. This guarantees two worker passes can never execute the same queued run.
A defense-in-depth organization check on every claimed run. This is independent of whatever join produced it.
All-or-nothing execution per run. Every action must succeed for the run to be marked completed. Any single failure marks the whole run failed with the specific error kept.
A stuck-run reaper: a run stuck in "running" for more than five minutes is automatically re-queued. This is capped at three total attempts. After that, it is marked permanently failed with a stated reason.
Every successfully executed action is logged as its own system-authored note on the deal's timeline. This means a rule never fires invisibly.
Role-gated visibility and editing: an admin or manager can create, edit and delete rules. A sales-role team member can see which rules exist but not change them.

Conhecer os recursos

What changes operationally

A stale deal, an overdue activity, a stage change or a new deal can each trigger a real, logged action. No one needs to remember to check for it manually. A worker crash mid-execution results in exactly one clean execution once recovery completes. There is never a silent miss and never a duplicate. Every fired rule leaves a visible trace on the deal's own timeline. So nobody has to trust that "the automation probably ran."

A stale deal, an overdue activity, a stage change or a new deal can each trigger a real, logged action. No one needs to remember to check for it manually. A worker crash mid-execution results in exactly one clean execution once recovery completes. There is never a silent miss and never a duplicate. Every fired rule leaves a visible trace on the deal's own timeline. So nobody has to trust that "the automation probably ran.".

Quero esses resultados

A stale-deal rule surviving a worker crash (illustrative scenario, not a real client)

An admin sets up a rule. When a deal in the "Proposal Sent" stage goes 5 days without an update AND its value is at or above a configured threshold, create a follow-up activity due the next day. Also, log a note on the deal's timeline. A qualifying deal crosses the 5-day mark and a run is queued.

A background worker instance claims a small batch of queued runs, including this one. It uses the atomic claim step. This guarantees no other worker pass could have claimed the same run at the same moment. Partway through executing this specific run's actions, the worker instance crashes. Five minutes later, the reaper detects the run still marked "running" with no completion recorded. It re-queues it for attempt number two. The next worker pass claims it again. It re-checks that the deal still exists and still meets the stale-and-value conditions. It does — nothing changed in the interim. This time, it completes both actions. The follow-up activity is created, and the timeline note is logged. The deal owner sees both changes reflected on the deal with no indication anything went wrong. This is because from their side, nothing did.

A stale-deal rule surviving a worker crash (illustrative scenario, not a real client)

Conversar sobre meu caso

How to get started

Começar agora

Frequently asked questions

What triggers can start an automation rule in Orbit?

Four: a deal created, a deal moved to a new stage, a deal gone stale past a configured number of days, or an activity that missed its due date by a configured number of hours.

What actions can a rule actually take?

A fixed set of four: create a linked follow-up activity, log a system note on the deal's timeline, change the deal's priority, or pass its owner to another person. This is not a custom or open-ended action list.

Can the same rule run twice on the same event by mistake?

No — a database-level atomic claim step guarantees two worker passes can never execute the same queued run.

What happens if the worker crashes while a rule is running?

A run stuck in "running" for more than five minutes is automatically re-queued. This can happen up to three total attempts. After that, it is marked permanently failed with a stated reason. It is not retried forever.

If one action in a rule fails, do the other actions still count as successful?

No — the entire run is marked failed if any single action fails. The specific error is kept. There is no partial-success state.

What does Centriu Orbit cost?

It is sold with tiered plans (Starter/Pro/Max). These start at a published entry price. Exact current values are on the central pricing page.

Ainda tenho dúvida

See how Centriu Orbit executes deal automation rules safely

Quero resolver isso