Zelo

O Zelo é um sistema operacional da qualidade alimentar: uma plataforma onde o consultor configura os padrões, a equipe do estabelecimento opera o dia a dia, e uma IA que entende a legislação brasileira mantém os dois em conformidade contínua — do plano de boas práticas à fiscalização. Este documento define o que vamos construir na primeira versão, para quem, por quê, em que ordem, e como saberemos que deu certo.

1. Visão do produto

A maioria das ferramentas do mercado resolve um pedaço: ou é checklist, ou é rotulagem, ou é consultoria. O Zelo une essas frentes em torno de um único princípio — conformidade não é um evento, é um estado contínuo — e coloca o consultor no centro como quem leva o sistema para dezenas de estabelecimentos.

Em uma frase: o Zelo transforma a qualidade alimentar de um esforço pontual e manual em um processo contínuo, monitorado e à prova de fiscalização — operado pela equipe do estabelecimento e orquestrado pelo consultor.

2. O problema

2.1 O mercado hoje

O setor está fragmentado em quatro frentes que não conversam entre si: apps de consultoria (Food Checker, ProApp), plataformas de checklist para redes (SULTS, Checklist Fácil), softwares de rotulagem e ficha técnica (Nutrimenu), e plataformas internacionais de food safety (FoodDocs). Nenhuma junta as quatro — e o consultor brasileiro acaba operando com planilha, PDF e WhatsApp.

2.2 As quatro dores centrais

• Offline real. A inspeção acontece na cozinha, na câmara fria, no estoque — onde quase nunca há Wi-Fi. Ferramentas que dependem de conexão travam no momento de uso.
• IA que entende a legislação local. Montar Manual de BPF, plano APPCC e POPs adaptados à RDC 216 e às normas municipais é trabalhoso e manual. As soluções com IA de ponta não falam português nem conhecem a norma brasileira.
• A ponte consultor ↔ estabelecimento. Hoje o monitoramento diário depende do consultor estar presente. Falta uma camada em que a equipe do cliente opere o dia a dia e o consultor veja tudo à distância, no mesmo dado.
• Inteligência de dados. Ninguém transforma as inspeções em score de risco, tendência e priorização. O dado morre no papel.

2.3 Por que ainda não foi resolvido

O ProApp acertou no offline e no custo, mas não tem IA nem analytics. O FoodDocs tem a IA do futuro, mas não atende o Brasil. As plataformas de checklist são genéricas e ignoram a figura do consultor. O espaço da interseção está aberto.

3. Público-alvo

3.1 Persona A — O Consultor (usuário-âncora)

Profissional de qualidade/segurança de alimentos (nutricionista, eng. de alimentos, RT) que atende uma carteira de estabelecimentos. Dores: trabalho manual e repetitivo, dificuldade de escalar a carteira, pouca diferenciação, monitoramento dependente de presença física. O que precisa resolver (jobs-to-be-done): padronizar e acelerar a geração de documentos, acompanhar vários clientes à distância, provar valor com dados, fortalecer a própria marca/autoridade.

3.2 Persona B — O Estabelecimento e a equipe operacional

Restaurante, padaria, lanchonete, cozinha industrial e sua equipe (gerente, encarregado, manipuladores). Dores: medo de fiscalização, falta de método no dia a dia, rotatividade de equipe, documentos vencendo sem aviso. Jobs-to-be-done: cumprir a rotina de boas práticas sem complicação, ter tranquilidade na fiscalização, registrar o que foi feito.

3.3 Persona C — O Gestor/proprietário

Quem assina o cheque e responde pelo risco. Jobs-to-be-done: enxergar o nível de conformidade e o risco de cada unidade, justificar o investimento, dormir tranquilo.

4. Objetivos e métricas de sucesso

4.1 North Star Metric

Estabelecimentos com conformidade ativamente monitorada por mês — a métrica que captura valor real entregue (não só cadastro, mas uso recorrente).

4.2 KPIs por dimensão

4.3 Metas iniciais (hipóteses a validar)

Números de partida — hipóteses, não metas fechadas. Servem para dar direção e serão calibrados pela validação e pelo uso real:

Meta de carteira inicial (proposta, primeiros 90 dias): 10–20 consultores-piloto no Sul e Sudeste, cada um com 3–5 estabelecimentos → 50–100 estabelecimentos ativos monitorados. É um piloto controlado para validar ativação, retenção e disposição a pagar antes de escalar.

Calibração com o negócio: o preço (proposto na seção 9) e as metas acima são hipóteses ancoradas no mercado — fecham com a disposição a pagar que a validação ajudar a medir. A região de partida está definida: Sul e Sudeste.

5. Proposta de valor e diferenciais

Quatro diferenciais que, juntos, nenhum concorrente nacional tem: (1) IA localizada na legislação brasileira, (2) offline-first de verdade, (3) a ponte consultor↔estabelecimento, (4) score de risco e analytics. O fosso defensável é a base legal estruturada (RDC 216, RDC 429, IN 75 e normas municipais) que alimenta a IA — é o que segura o concorrente internacional na fronteira e o que mais demora para copiar.

6. Escopo

6.1 Dentro do MVP (v1) — priorizado

1. Gerador de planos por IA (BPF, APPCC, POPs) — o diferencial que mais economiza tempo do consultor.
2. Inspeção/checklist offline com scoring e plano de ação — o coração do uso diário.
3. Ponte consultor↔estabelecimento (multiusuário com papéis) — sem isso, não há modelo de receita dupla.
4. Painel de risco e indicadores (versão essencial) — o que prova valor.
5. Controle de documentos com alerta de vencimento.
6. Controle de validades de insumos/estoque (origem: validação Mariana — marcado como essencial).

6.2 Fora de escopo por enquanto (v2+)

Fichas técnicas e rotulagem RDC 429 completas (entra como módulo dedicado depois); marketplace/white-label; integrações com PDV/ERP; app de cliente final; relatórios avançados de BI. Motivo: focar a v1 nos diferenciais e no fluxo que gera recorrência, sem inflar o escopo.

6.3 Princípios de priorização

Offline e IA primeiro (são os diferenciais). Nada entra na v1 se não servir ao fluxo consultor→equipe→dado. Profundidade vem por iteração, guiada pela validação.

7. Requisitos funcionais

Notação: RF = requisito funcional. Cada bloco traz objetivo e critérios de aceite (o que precisa ser verdade para considerarmos pronto).

7.1 Gerador de planos por IA

Objetivo: gerar Manual de BPF, plano APPCC e POPs adaptados ao tipo de estabelecimento e à legislação aplicável — não por "achismo do modelo", mas a partir de uma base legal estruturada.

Como a base legal vira dado consultável (o coração do diferencial): A legislação não fica "solta" na cabeça do modelo. Cada norma é decomposta em requisitos e armazenada numa base estruturada, em que cada requisito carrega metadados: esfera (federal/estadual/municipal), tipo de estabelecimento a que se aplica, tema (edificação, manipulação, higiene, controle de temperatura, documentação, etc.) e a referência exata (norma, artigo/item). Ao gerar um plano, a IA recupera os requisitos aplicáveis àquele estabelecimento e município e monta o documento citando a fonte — e o consultor revisa. Assim, o conteúdo é rastreável, atualizável e defensável.

• RF-1.1 Coletar dados do estabelecimento (tipo, porte, processos, município) por formulário guiado.
• RF-1.2 Manter uma base legal estruturada e versionada (requisitos com metadados e referência normativa).
• RF-1.3 Sobreposição municipal: aplicar a base federal (RDC 216) e sobrepor a norma do município, que prevalece/complementa quando existir.
• RF-1.4 Gerar o documento recuperando os requisitos aplicáveis e citando a fonte normativa de cada exigência.
• RF-1.5 Permitir edição do consultor antes de finalizar (a IA propõe, o consultor decide).
• RF-1.6 Sinalizar quando a base legal mudar e permitir regerar/atualizar documentos afetados.
• RF-1.7 Exportar em PDF com a identidade do consultor.
• Critérios de aceite: um plano é gerado em < 5 min; cada exigência traz a referência normativa; ao trocar o município, o conteúdo muda conforme a norma local; o consultor consegue editar qualquer trecho; quando uma norma é atualizada, o sistema avisa quais documentos podem estar desatualizados.

7.2 Inspeção / Checklist offline

Objetivo: aplicar inspeções sem internet, com pontuação e plano de ação automático — é o coração do uso diário e o requisito de engenharia mais sensível.

• RF-2.1 Funcionar 100% offline: abrir, preencher e concluir uma inspeção sem nenhuma conexão.
• RF-2.2 Salvar automaticamente (auto-save local) a cada resposta, sem o usuário precisar "salvar".
• RF-2.3 Checklist configurável por categoria, com itens classificados por criticidade (crítico / necessário / recomendável) e ponderados — o score reflete o peso de cada item.
• RF-2.4 Cálculo de score ao vivo conforme o preenchimento avança.
• RF-2.5 Para cada item, registrar conformidade (conforme / não conforme / não aplicável) e anexar foto como evidência, com data/hora.
• RF-2.6 Gerar plano de ação automático a partir das não conformidades (o quê, prazo sugerido, responsável).
• RF-2.7 Modelos de checklist reutilizáveis: o consultor cria/edita um modelo e aplica em vários estabelecimentos.
• RF-2.8 Campo de assinatura do responsável técnico/responsável pela inspeção (origem: validação Mariana).
• RF-2.9 Permitir reabrir uma inspeção concluída para correção (mantendo histórico da alteração).

Sincronização (quando volta a conexão):

• RF-2.10 Inspeções feitas offline entram numa fila local e sincronizam automaticamente ao reconectar.
• RF-2.11 Indicador visível de status de sincronização (pendente / enviado) por inspeção.
• RF-2.12 Conflitos resolvidos de forma previsível (a versão mais recente prevalece) e registrados em log — nunca apagar dado silenciosamente.

Estados de uma inspeção: rascunho → em andamento → concluída → sincronizada → (reaberta →) arquivada.

Critérios de aceite: uma inspeção completa é aplicável em modo avião e sincroniza sem perda ao reconectar; o score aparece em tempo real e reflete a criticidade dos itens; cada não conformidade gera item no plano de ação; a assinatura e as fotos ficam no relatório; o status de sincronização é sempre visível.

7.3 Painel de risco e indicadores

Objetivo: transformar inspeções em decisão — o que prova valor para o consultor.

• RF-3.1 Score de conformidade por estabelecimento e da carteira inteira.
• RF-3.2 Mapa de calor por categoria e ranking de estabelecimentos por risco.
• RF-3.3 Não conformidades mais frequentes e tendência no tempo.
• RF-3.4 Filtros (por estabelecimento, período, categoria) e drill-down do score até a inspeção que o originou.
• RF-3.5 Alertas consolidados (documentos/insumos vencendo, unidades sem sincronização recente).
• RF-3.6 Indicador de última sincronização por estabelecimento (transparência do dado).
• Critérios de aceite: o consultor identifica em < 30s quais clientes precisam de atenção; clicar num score leva à inspeção de origem; o painel deixa claro quando um dado está desatualizado.

7.4 Controle de documentos

Objetivo: nunca deixar um documento vencer sem aviso.

• RF-4.1 Cadastro de documentos com data de validade (alvará, AVCB, laudos de água, atestados de saúde).
• RF-4.2 Alerta de vencimento com antecedência configurável.
• Critérios de aceite: o sistema avisa antes do vencimento; o status fica visível no painel.

7.5 Controle de validades de insumos/estoque (origem: validação Mariana)

Objetivo: acompanhar a validade dos produtos em uso/estoque.

• RF-5.1 Cadastro de insumos com data de validade e lote.
• RF-5.2 Alerta de itens próximos do vencimento.
• Critérios de aceite: a equipe vê o que está perto de vencer; o consultor enxerga isso como item de risco. Escopo exato a refinar com a consultoria.

7.6 Ponte consultor ↔ estabelecimento

Objetivo: equipe opera, consultor supervisiona, no mesmo dado.

• RF-6.1 Multiusuário com papéis e permissões (consultor, gestor, operador).
• RF-6.2 A equipe do estabelecimento registra rotinas/inspeções; o consultor vê em tempo real.
• RF-6.3 O consultor gerencia sua carteira de estabelecimentos a partir de um único acesso.
• Critérios de aceite: um operador só vê o que lhe cabe; o consultor vê todos os seus clientes; os dados são os mesmos para ambos.

Matriz de permissões (papéis × capacidades):

7.7 Relatórios e fiscalização

Objetivo: no momento da fiscalização (ou de uma auditoria interna), provar conformidade na hora — com histórico, não com promessas.

• RF-7.1 Gerar, sob demanda, um relatório consolidado de um estabelecimento contendo: identificação da unidade; histórico de inspeções com scores e datas; não conformidades e seus planos de ação (com status); situação de documentos e validades; e assinaturas registradas.
• RF-7.2 Exportar em PDF pronto para apresentar/imprimir.
• RF-7.3 Filtrar o relatório por período.
• RF-7.4 Relatório consolidado da carteira para o consultor (visão gerencial).
• Critérios de aceite: o relatório é gerado em segundos; reflete fielmente o histórico registrado; inclui as assinaturas; e serve como evidência de conformidade perante a vigilância sanitária. (O conteúdo exato exigido pela fiscalização é um dos pontos a confirmar com a consultoria.)

8. Requisitos não-funcionais

• Offline-first & sincronização confiável, com resolução de conflitos previsível.
• Multiplataforma: PWA instalável e experiência mobile de primeira (o uso é no celular, em campo).
• Segurança & autenticação: login real por usuário, com papéis. (Hoje o portal de validação usa senha simples — para o produto, autenticação real é requisito.)
• LGPD & privacidade: dados de estabelecimentos e equipes tratados conforme a LGPD; consentimento e finalidade claros.
• Desempenho: telas críticas (inspeção, painel) respondem em < 1s.
• Auditoria/logs: registro de quem fez o quê e quando (essencial para fiscalização).
• Disponibilidade & backup: dados não se perdem; histórico preservado.

9. Modelo de negócio

Receita dupla: assinatura do consultor + um seat por estabelecimento. O consultor vira canal de distribuição — cada cliente que ele leva é uma recorrência nova, e ele pode repassar o seat com margem.

Âncoras de mercado (o que existe hoje): Food Checker ~R$22/mês (web, sem offline/IA); ProApp (offline, foco em custo); FoodDocs ~US$169/mês (IA, sem Brasil); SafetyCulture ~US$24/usuário/mês. O Zelo entrega bem mais que o Food Checker (IA localizada + offline + ponte + dados), o que justifica posicionar acima dele — sem chegar ao preço dos internacionais.

Estrutura de preço proposta (hipótese a validar com disposição a pagar):

Estes números são proposta ancorada no mercado, não preço final. O teste de disposição a pagar dos dois lados — central na validação com a Mariana — é o que fecha as faixas. A lógica: o consultor paga pela alavanca (IA + gestão da carteira); o estabelecimento paga pela tranquilidade na fiscalização.

10. Fluxos principais

Cada fluxo traz pré-condição, passos e o que acontece quando algo foge do caminho feliz.

10.1 Onboarding de um novo cliente (o fluxo que destrava a ativação)

Pré-condição: consultor com conta ativa.

1. Consultor cadastra o estabelecimento (tipo, porte, município).
2. Gera o plano por IA (BPF/APPCC/POPs) e revisa.
3. Convida a equipe do estabelecimento (envio de convite → vira seat).
4. Define o primeiro modelo de checklist para aquela unidade.
5. A equipe instala o app (PWA) e faz a primeira inspeção. Exceções: equipe não aceita o convite → lembrete automático ao consultor; município sem base legal cadastrada → usa base federal (RDC 216) e sinaliza pendência. Sucesso = ativação: 1º plano gerado e 1ª inspeção concluída.

10.2 Rotina diária da equipe (offline)

Pré-condição: operador com seat, app instalado.

1. Abre o checklist do dia no celular — sem depender de internet.
2. Registra item a item (conforme/não conforme/N.A.), anexa foto onde precisa.
3. Conclui e assina.
4. Ao reconectar, a inspeção sincroniza sozinha. Exceções: ficou sem bateria/fechou o app → o auto-save preserva o rascunho; sem sinal por horas → fica na fila e envia depois, sem perda.

10.3 Supervisão do consultor

Pré-condição: estabelecimentos com inspeções sincronizadas.

1. Abre o painel da carteira.
2. Vê scores, ranking e alertas; identifica em segundos quem precisa de atenção.
3. Entra no estabelecimento de risco, revisa não conformidades e aciona o plano de ação. Exceções: dado desatualizado (unidade sem sincronizar) → painel marca "sem sincronização recente".

10.4 Documento/insumo vencendo

1. Sistema detecta proximidade do vencimento (alvará, laudo, atestado, insumo).
2. Dispara alerta (consultor e/ou gestor) com antecedência configurável.
3. Responsável renova e atualiza → status volta ao verde. Exceções: venceu sem renovação → item entra como risco no painel até regularizar.

10.5 Fiscalização (o momento da verdade)

1. Gera, na hora, um relatório consolidado da unidade: histórico de inspeções, planos de ação, documentos e assinaturas.
2. Exporta em PDF. Valor: transforma "torcer para estar tudo certo" em "provar que está", com histórico assinado.

11. Direção técnica (alto nível, não-prescritiva)

PWA + experiência mobile; backend com banco multi-tenant; camada de IA ancorada em uma base legal estruturada (a norma vira dado consultável, não "achismo do modelo"); motor de sincronização offline. Isto é direção, não decisão final de arquitetura — serve para orientar quem for desenvolver.

12. Base regulatória (a confirmar com a consultoria)

Base de partida: RDC 216/2004 (boas práticas para serviços de alimentação), POPs e APPCC; RDC 429/2020 + IN 75/2020 (rotulagem nutricional, para o módulo futuro de rótulos); e normas municipais da vigilância sanitária, que variam por cidade. A precisão e a atualização dessas referências é exatamente o terreno da Mariana — este é um dos pontos onde a validação dela é insubstituível.

Cobertura inicial: a base municipal começa pelo Sul e Sudeste (capitais e principais municípios de SP, RJ, MG, ES, RS, SC e PR), acompanhando a meta de carteira-piloto. Novos municípios entram por demanda.

13. Riscos e mitigações

14. Roadmap em fases

• Fase 1 — MVP: gerador por IA, inspeção offline, ponte consultor↔estabelecimento, painel essencial, controle de documentos e validades, relatórios de fiscalização. Cobertura legal inicial: Sul e Sudeste.
• Fase 2: fichas técnicas e rotulagem (RDC 429), relatórios avançados, refinamento de IA.
• Fase 3: white-label/marca do consultor, integrações (PDV/ERP), expansão de cobertura legal.

15. Perguntas em aberto / a validar

• Disposição a pagar de cada lado — para confirmar as faixas propostas na seção 9 (consultor ~R$149, seat ~R$49).
• Dentro do Sul/Sudeste, quais municípios priorizar primeiro (capitais antes do interior?).
• Profundidade real necessária do controle de estoque/validades.
• Quais relatórios a fiscalização efetivamente exige.
• Fluxo ideal de convite e adoção da equipe operacional.

Estas são as perguntas que a validação com a Mariana — e o uso real — vão fechando.

16. Glossário

BPF Boas Práticas de Fabricação · APPCC Análise de Perigos e Pontos Críticos de Controle · POP Procedimento Operacional Padronizado · RDC Resolução da Diretoria Colegiada (ANVISA) · IN Instrução Normativa · CMV Custo da Mercadoria Vendida · Visa Vigilância Sanitária · RT Responsável Técnico · Seat assento/licença paga por estabelecimento · MRR receita recorrente mensal · Churn taxa de cancelamento.

Anexo A — Modelo de dados (conceitual)

Visão de alto nível das entidades e como se relacionam. Não é o desenho final do banco — é o mapa para quem for construir.

Relações principais: um Consultor tem muitos Estabelecimentos; um Estabelecimento tem muitos Membros, Inspeções, Documentos, Insumos e Planos; uma Inspeção usa um Modelo de checklist, tem muitos Itens e gera itens de Plano de ação.

Changelog

• v0.3 — Gerador por IA detalhado (base legal estruturada e consultável); módulo de relatórios e fiscalização; painel expandido; modelo de negócio com proposta de preço ancorada no mercado (consultor ~R$149, seat ~R$49); meta de carteira-piloto e cobertura legal inicial no Sul/Sudeste.
• v0.2 — Detalhamento: inspeção offline com estados e sincronização; matriz de permissões por papel; métricas com hipóteses numéricas + decisões pendentes; fluxos principais passo a passo (com onboarding e exceções); modelo de dados conceitual.
• v0 — Primeira versão, a partir da auditoria competitiva, do blueprint, do protótipo e da estrutura de validação.

Como este documento evolui

Esta é a versão 0.3 — rascunho em detalhamento. Não precisa estar perfeito: é um documento vivo. Os comentários e pedidos da consultoria entram pelo canal em zelo.portalgsemp.com.br, e cada ponto levantado vira requisito aqui (como já aconteceu com a assinatura do RT e o controle de validades). A cada rodada, sobe uma versão nova.