Forux · Projeção de Produto
Rascunho para discussão

Maria Clara de Mercado

De motor interno da rede de clínicas a produto vendável — empacotado em três níveis de inteligência e quatro módulos, para que o mercado compre exatamente o que precisa e pague pelo que usa.

Full — LLM ponta a ponta Economy — LLM reduzido Lite — sem LLM
3
Níveis de inteligência
4
Módulos vendáveis
1
Produto, muitos planos

O problema & a oportunidade

Hoje a Maria Clara roda sob medida para a nossa rede de clínicas: um agente de LLM completo, poderoso — e caro por conversa. Esse formato entrega muito, mas é difícil de vender "de prateleira" e o custo de token cresce com o volume.

Onde estamos

Um produto único, robusto, acoplado à operação interna. Cada implantação é artesanal.

O atrito

LLM em toda conversa = custo variável alto, jornada menos previsível e margem de erro maior.

A jogada

Reempacotar em classes de custo e módulos avulsos — abrindo faixas de preço e um mercado muito além da rede.

A ideia em uma frase

Um produto. Três níveis de inteligência. Quatro módulos. O cliente monta o plano.

A produtização se organiza em dois eixos independentes: o quanto de IA o agente usa (nível) e quais capacidades ele entrega (módulos). Combinando os dois, cada clínica compra a solução no seu orçamento e na sua realidade operacional.

Eixo 1 — Níveis de inteligência

O mesmo esqueleto de jornada, com quantidades diferentes de LLM. Quanto menos IA, menor o custo e maior a previsibilidade — ao preço de menos naturalidade na conversa.

Full
Premium · o produto de hoje
  • Conversa natural de ponta a ponta
  • Lida com o inesperado, linguagem livre
  • Maior encantamento — e maior custo
LLM
alto
Economy
Reestruturação econômica · "Full" do PDF
  • Menu-first: CPF → identifica → opções
  • LLM só em pontos-chave (script reduzido)
  • Prompt simples, jornada previsível
LLM
pontual
Lite
Sem IA · "Lite" do PDF
  • Zero token — 100% determinístico
  • Menu roteia direto para o setor
  • Queda enorme na margem de erro
LLM
nenhum

Eixo 2 — Módulos

Quatro capacidades que já existem como fluxos separados na operação — logo, tecnicamente destacáveis para venda avulsa ou como add-on.

Agente de Atendimento

Recebe, identifica pelo CPF e resolve agendamento, reagendamento e financeiro.

Confirmações

Confirma consultas automaticamente e reabre agenda quando o paciente não pode ir.

Lembretes

Avisa o paciente antes da consulta e trata "não posso ir" sem intervenção manual.

Follow-ups (FUP)

Reengaja quem não respondeu ou não fechou, em réguas de tempo configuráveis.

Os fluxos, redesenhados

A jornada determinística

Em vez de "conversar", o agente conduz: identifica e oferece um menu. É isso que torna Economy e Lite baratos e previsíveis.

Olá, bom dia!
Olá, sou a Maria Clara, especialista em atendimento nas Clínicas Inteligentes! Você já é nosso cliente?
1 · Sim   2 · Não
1
Digita por favor o CPF para confirmar o teu cadastro!
123.456.789-00
Encontrei seu cadastro, Marcelo! O que você precisa hoje?
1 · Agendar   2 · Remarcar   3 · Financeiro
Por que menu-first
  • Previsível: cada passo tem um destino claro.
  • Barato: template e tool no lugar de LLM.
  • Seguro: menos "clientes amigos do LLM" e menos alucinação.
Atenção operacional. Nos níveis Economy e Lite, os pontos que hoje o LLM resolve caem para atendente humano. Isso exige equipe do lado do cliente — é decisão de modelo (ver questões em aberto).

Atendimento — Economy × Lite

Mesma espinha dorsal. A única diferença está nos pontos de escape: no Economy eles vão para um LLM reduzido; no Lite, para um atendente humano.

Economy
LLM pontual nos escapes
Mensagem do cliente Campanha (s/ Ecuro) Cliente ou lead novo? Coleta CPF · identifica LLM Menu de opções Agendamento Reagendamento Financeiro LLM ·script reduzido Atendente humano
Lite
Escapes viram atendente humano
Mensagem do cliente Campanha (s/ Ecuro) Cliente ou lead novo? Coleta CPF · identifica Atendente humano Menu de opções Agendamento Reagendamento Financeiro Atendente humano Atendente humano
Passo determinístico (menu / tool / template) LLM (IA) — só no Economy Atendente humano

Fluxos auxiliares

Confirmações e Lembretes seguem a mesma regra: template no caminho positivo; o desvio é que muda entre os níveis.

Confirmações
Confirmar? Sim/Não
SimTool confirma + template
NãoLLM reagendaEconomyAtendente humanoLite
Lembretes
Template de lembrete
Estou cienteTemplate de encerramento
Não posso irLLM reagendaEconomyAtendente humanoLite

Comparativo dos níveis

CritérioFullEconomyLite
Uso de LLMToda conversaPontual (escapes)Nenhum
Custo de tokenAlto / variávelBaixoR$ 0
NaturalidadeMáximaMédia (menu + IA)Menu / scripts
PrevisibilidadeMédiaAltaTotal
Margem de erroMaiorBaixaMínima
Depende de equipe humanaPoucoNos escapesSim, mais
Indicado paraEncantamento e volume alto qualificadoO melhor custo-benefício da linhaOrçamento enxuto / operação simples

Possibilidades de venda

Monte seu plano: nível × módulos

Qualquer módulo pode ser vendido avulso, como add-on ou no pacote completo — em qualquer um dos três níveis. A tabela mostra como cada módulo se comporta por nível.

MóduloFullEconomyLite
Agente de AtendimentoConversa livre com IAMenu + IA reduzidaMenu + humano
ConfirmaçõesIA no reagendamentoTemplate + IA no desvioTemplate + humano
LembretesIA no reagendamentoTemplate + IA no desvioTemplate + humano
Follow-ups (FUP)Régua com copy de IARégua com templateRégua com template

Combinações-exemplo

Completo
Tudo ligado — o pacote premium.
AgenteConfirmaçõesLembretesFUP
Só o Agente
Sem auxiliares e sem FUP.
AgenteConfirmaçõesLembretesFUP
Agente + add-ons
Base + módulos escolhidos.
AgenteFUPConfirmaçõesLembretes
Só Confirmações
Sem agente — apenas confirmar consultas.
AgenteConfirmaçõesLembretesFUP
Só Lembretes
Sem agente — apenas lembrar.
AgenteConfirmaçõesLembretesFUP
Confirmações + Lembretes
Dupla de retenção, sem agente.
AgenteConfirmaçõesLembretesFUP

Cada combinação se repete nos três níveis — ex.: "Completo Full", "Completo Economy", "Só Confirmações Lite". 3 níveis × combinações de 4 módulos = um catálogo amplo a partir das mesmas peças.

O que falta para ir ao mercado

Além das três telas que você citou (landing, página de produto e home), há uma camada de operação sem a qual não dá para cobrar de forma escalável. Marquei o que é MUST para o V1 e o que é NICE.

Vitrine (marketing)

  • MUSTLanding page — captação e conversão, com as dores e os 3 níveis.
  • MUSTPágina de produto — detalha níveis, módulos e preços; a matriz "monte seu plano".
  • NICEProva social / cases da rede e blog de SEO.

Produto (experiência)

  • MUSTHome / área logada — o cliente cria, ajusta e acompanha seu agente. Podemos evoluir do AI Agent Control.
  • MUSTOnboarding self-service — conectar WhatsApp, agenda/Ecuro e escolher plano sem implantação manual.
  • NICECatálogo interativo de planos + upsell de módulos.

Operação (infra & receita)

  • MUSTProvisionamento multi-tenant automático de instância por cliente.
  • MUSTCobrança recorrente por plano + add-ons.
  • MUSTMedição de tokens nos níveis com IA (para precificar e limitar).
  • NICEModelo de handoff humano + SLA de suporte.

Management System

Nosso sistema de gestão — no lugar do Ecuro

Hoje a Maria Clara executa todas as tools dentro do Ecuro — a agenda, a busca de pacientes, os agendamentos. Para virar produto de mercado, precisamos de um sistema online próprio que a Maria Clara consome via API REST, replicando o Ecuro no que importa (agenda, disponibilidade, pacientes, agendamentos) e nos dando controle total de dados, custo e evolução. Esta seção é o norte de desenvolvimento: modelo de dados, contrato da API e regras de negócio para conduzir a construção.

tools · REST SQL Maria Clara Full · Economy · Lite Management System API REST própria Banco de dados substitui o Ecuro
A Maria Clara deixa de falar com o Ecuro e passa a falar com a nossa API — mesmo comportamento, stack nossa.

Modelo de dados

Seis entidades-núcleo. Todo recurso pertence a uma clinic_id (multi-tenant).

Clinica
A unidade. Fonte do fuso e do horário de funcionamento.
iduuidIdentificador da clínica.
nome · slugstringNome e apelido da unidade.
timezonestringEx.: America/Sao_Paulo.
horario_funcionamentojsonJanelas por dia da semana.
configjsonCadeiras, duração padrão, antecedência, janela máx.
Dentista
Profissional. Tem especialidades e jornada própria.
id · clinic_iduuidDoutor e sua clínica.
nomestringNome do profissional.
especialidadesuuid[]Especialidades que atende.
jornadajsonHorário de trabalho por dia.
duracao_por_especialidadejsonTempo de consulta (min).
ativoboolEntra ou não na disponibilidade.
Especialidade
Ex.: Avaliação, Ortodontia, Medicina.
iduuidEspelha o specialtyId do Ecuro.
nomestringRótulo exibido pela MC.
duracao_padrao_minintDuração default do procedimento.
Paciente
Identificado por telefone/CPF. Sem duplicatas.
id · clinic_iduuidPaciente e clínica.
nomestringNome completo.
telefoneE.164Chave de busca principal.
cpfstringChave secundária / dedup.
nascimento · emailstringDados de cadastro.
Agendamento
A consulta. Núcleo da agenda.
id · clinic_iduuidAgendamento e clínica.
patient_id · doctor_iduuidQuem e com quem.
specialty_iduuidEspecialidade do atendimento.
inicio · duracao_minISO-8601Começo e duração (deriva o fim).
statusenumVer "Status" abaixo.
origemenumMC / humano.
Bloqueador
Intervalo indisponível: feriado, almoço, ausência.
id · clinic_iduuidBloqueio e clínica.
doctor_iduuid?Nulo = clínica inteira.
inicio · fimISO-8601Intervalo bloqueado.
motivo · recorrenciastringRótulo e regra de repetição.

Regras de controle de agenda

O que o sistema precisa garantir para funcionar como o Ecuro.

Doutores

Cadastro com especialidades e jornada por dia. Só doutor ativo e com a especialidade pedida entra na disponibilidade.

Pacientes

Cadastro com dedup por telefone/CPF — nunca criar ficha duplicada; ao achar mais de uma, usar a mais recente/ativa.

Tempo de duração

Duração por especialidade e/ou doutor, com default da clínica. Define o passo dos horários e o fim do agendamento.

Agendamentos simultâneos

Capacidade = nº de cadeiras/atendimentos concorrentes. Um horário só fica indisponível quando a capacidade se esgota.

Bloqueadores

Feriados, almoço e ausências removem janelas da disponibilidade — por doutor ou pela clínica toda.

Horário de funcionamento

A disponibilidade vive sempre dentro de (funcionamento da clínica ∩ jornada do doutor), respeitando antecedência mínima e janela máxima.

Como a disponibilidade é calculada — o coração do sistema
disponibilidade(clinica, doutor, dia, duracao):
  janela = funcionamento(clinica, dia)  INTERSEC  jornada(doutor, dia)
  slots  = fatiar(janela, passo = duracao)
  para cada slot em slots:
    se dentro_de_bloqueador(slot):               descarta
    se slot.inicio < agora + antecedencia_min:   descarta
    ocupacao = agendamentos_que_colidem(slot)
    se ocupacao >= capacidade_simultanea:        descarta
  retorna slots_restantes

Referência da API

Base https://api.<sistema>.forux.io/v1 · autenticação Authorization: Bearer <api_key_da_clinica> · JSON · Idempotency-Key nos POST/PATCH. Cada endpoint abaixo é uma tool da Maria Clara.

GET/v1/clinicslist_clinics

Lista as clínicas do tenant. Usado para roteamento multi-unidade.

Resposta 200
[
  {
    "id": "cli_9x…",
    "nome": "Clínica Carapicuíba",
    "slug": "carapicuiba",
    "timezone": "America/Sao_Paulo",
    "ativo": true
  }
]
Regras
  • Retorna só clínicas do tenant da API key.
  • Filtra por ativo=true por padrão.
GET/v1/patients?telefone=&clinic_id=consultar_paciente_por_telefone

Busca o paciente pelo telefone (E.164). É como a MC descobre quem está falando.

Resposta 200
{
  "encontrado": true,
  "paciente": {
    "id": "pac_12…",
    "nome": "Marcelo Souza",
    "telefone": "+5511998887766",
    "cpf": "123.456.789-00"
  }
}
Regras
  • Normaliza o telefone antes de buscar.
  • Dedup: se houver mais de uma ficha, retorna a mais recente/ativa e descarta a antiga.
  • encontrado:false quando não há cadastro.
POST/v1/patientsinserir_dados

Cria ou atualiza o cadastro do paciente (novo paciente ou captura de lead). Upsert.

Corpo
{
  "clinic_id": "cli_9x…",
  "nome": "Marcelo Souza",
  "telefone": "+5511998887766",
  "cpf": "12345678900",
  "nascimento": "1990-05-12",
  "origem": "MC"
}
Regras
  • Upsert por telefone/CPF — não duplica ficha.
  • Valida CPF e formato de telefone.
  • Retorna o paciente com criado: true|false.
GET/v1/availabilityconsultar_disponibilidade_dentista

O endpoint mais importante. Retorna os horários livres respeitando funcionamento, jornada, bloqueadores, duração e simultaneidade.

Parâmetros
clinic_id     obrigatório
specialty_id  obrigatório
doctor_id     opcional (todos da esp.)
date_from     obrigatório  (ISO)
date_to       obrigatório  (ISO)
duration_min  opcional (senão, default)
Resposta 200
{
  "slots": [
    {
      "doctor_id": "den_7…",
      "specialty_id": "esp_3…",
      "inicio": "2026-08-14T09:00-03:00",
      "fim":    "2026-08-14T09:30-03:00",
      "duracao_min": 30
    }
  ]
}
  • Sem doctor_id, considera todos os doutores ativos da especialidade.
  • Aplica antecedência mínima e janela máxima da clínica.
  • Só oferece o slot enquanto a capacidade simultânea (cadeiras) não estourou.
POST/v1/appointmentscriar_agendamento

Cria o agendamento em um horário disponível.

Corpo
{
  "clinic_id": "cli_9x…",
  "patient_id": "pac_12…",
  "doctor_id": "den_7…",
  "specialty_id": "esp_3…",
  "inicio": "2026-08-14T09:00-03:00",
  "duracao_min": 30,
  "origem": "MC"
}
Regras
  • Revalida o slot no momento da escrita (evita double-booking).
  • Idempotente via Idempotency-Key.
  • Retorna 409 se o horário não estiver mais livre.
POST/v1/appointments/{id}/confirmconfirmar_agendamento

Confirma a presença. É o que o módulo Confirmações chama.

Resposta 200
{
  "id": "agd_55…",
  "status": "confirmado",
  "confirmado_em": "2026-08-13T18:20-03:00"
}
Regras
  • Muda o status para confirmado e grava o timestamp.
  • Só a partir de agendado ou remarcado.
GET/v1/patients/{id}/appointmentslistar_agendamentos_do_paciente

Lista os agendamentos do paciente (para confirmar, remarcar, consultar).

Filtros
status   opcional (ex.: agendado)
from,to  opcional (período)
Regras
  • Inclui remarcados (status 3) — não pode omitir, sob risco de "especialidade não especificada".
  • Ordena por inicio desc.
PATCH/v1/appointments/{id}atualizar_agendamento

Remarca, cancela ou muda o status de um agendamento.

Corpo (parcial)
{
  "inicio": "2026-08-15T14:00-03:00",
  "doctor_id": "den_7…",
  "status": "remarcado"
}
Regras
  • Remarcação revalida a disponibilidade do novo horário.
  • Cancelar libera o slot imediatamente.
  • Respeita as transições de status válidas.
POST/v1/handoffacionarAtendimentoHumano

Transfere a conversa para um atendente humano. É o destino dos escapes (financeiro, casos fora do fluxo, níveis Economy/Lite).

Corpo
{
  "clinic_id": "cli_9x…",
  "telefone": "+5511998887766",
  "motivo": "financeiro",
  "contexto": "Paciente quer negociar débito"
}
Regras
  • Integra com o Chatwoot: desatribui a MC e coloca na fila humana.
  • Registra motivo e contexto para o atendente.

Status do agendamento

Códigos espelham os do Ecuro (ex.: 3 = remarcado, confirmado no nosso fluxo).

agendado criado confirmado presença ok remarcado mudou horário (3) cancelado liberou slot realizado compareceu falta no-show

Fases de desenvolvimento

Uma trilha para chegar à paridade com o Ecuro sem parar a operação.

Fase 1

Núcleo da agenda

Clínicas, doutores, especialidades e pacientes; CRUD de agendamento; cálculo de disponibilidade com funcionamento + jornada + duração. Endpoints: clinics, patients, availability, appointments.

Fase 2

Paridade operacional

Bloqueadores, simultaneidade (cadeiras), antecedência/janela, confirmar/remarcar, dedup de paciente e handoff humano (Chatwoot). É aqui que "funciona como o Ecuro".

Fase 3

Produto & migração

Multi-tenant com API key por clínica, medição de uso, hooks de cobrança e migração dos dados do Ecuro. Rodar em paralelo (shadow) até a virada.

Decisões técnicas em aberto. Stack e banco (ex.: Postgres + API própria); estratégia de migração Ecuro → novo (big-bang × unidade a unidade); e se a camada MCP atual da MC vira cliente desta API sem reescrever os fluxos.

Decisões em aberto (para a reunião)

Nomenclatura dos níveis

No PDF, "Full Version" é a econômica com LLM reduzido — colide com chamar o produto atual de "Full". Sugiro: Full (atual) · Economy · Lite.

Modelo de preço

Assinatura por nível + add-ons por módulo. Nos níveis com IA, cobrar consumo de token à parte ou embutir em franquia?

Nome do produto

"Maria Clara de Mercado" é o codinome. Definir a marca comercial (pode herdar de "Clínicas Inteligentes" / Forux Agents).

LGPD — coleta de CPF

A jornada pede CPF logo no início (dado pessoal). Precisa de base legal, consentimento e tratamento adequado antes de vender externamente.

Nicho além de odontologia

O esqueleto (identifica → menu → setor) serve outras clínicas/serviços. Vale desenhar como template por vertical?

Próximos passos