FastInBox | Business and product strategy
Business Model Canvas Tecnico
Versao: 2.0 | Alinhado ao MVP Canvas de referencia | Data-base: 2026-04-10
Documento executivo-tecnico que consolida o modelo de negocio do FastInBox com detalhamento operacional para tomada de decisao, priorizacao de backlog e planejamento de escala.
1. Visao de modelo
O FastInBox opera como infraestrutura digital white label para clinicas e nutricionistas venderem marmitas personalizadas com marca propria, mantendo a experiencia do paciente consistente e operacionalmente rastreavel.
O modelo combina plataforma SaaS, camada de operacao alimentar e trilha financeira integrada para reduzir improviso manual, minimizar erro e aumentar previsibilidade de atendimento.
2. Segmentos de clientes
| Segmento | Problema atual | Valor entregue |
|---|---|---|
| Nutricionistas e clinicas | Operacao fragmentada em chat e planilhas | Fluxo unificado com marca propria e rastreabilidade |
| Pacientes finais | Compra confusa e sem visibilidade de status | Revisao clara, pagamento simples e acompanhamento |
| Fabricas parceiras | Pedidos incompletos e baixa padronizacao | Fila de producao estruturada e status operacionais |
| Gestao FastInBox | Baixa governanca de ponta a ponta | Consolidacao de dados de negocio e operacao |
3. Proposta de valor
3.1 Camada comercial
- Permite ao nutricionista vender marmitas com assinatura visual da clinica.
- Reduz tempo operacional para montar pedidos e validar informacoes.
- Cria diferenciacao por personalizacao nutricional sem perder padrao de entrega.
3.2 Camada do paciente
- Pedido acessado por codigo unico sem friccao de descoberta.
- Revisao objetiva antes de pagar, reduzindo ruido e retrabalho.
- Acompanhamento de producao e entrega por status padronizado.
3.3 Camada operacional
- Fabrica recebe somente pedido apto para producao.
- Atualizacao de status com trilha historica recuperavel.
- Base de dados pronta para indicadores de SLA e capacidade.
4. Canais e relacionamento
O canal primario e web, com jornada responsiva para desktop e mobile. O relacionamento e orientado por jornada transacional: cada persona recebe interface e mensagens adequadas ao seu contexto de decisao.
| Canal | Objetivo | Metrica recomendada |
|---|---|---|
| Painel nutricionista | Criar e acompanhar pedidos | Tempo medio de criacao |
| Landing do paciente | Revisar e pagar pedido | Taxa de conversao pagamento |
| Painel da fabrica | Executar producao | Lead time pago -> pronto |
| Dashboard administrativo | Governanca e qualidade | Pedidos com status consistente |
5. Estrutura de receita e custos
5.1 Receitas previstas
- Comissao por pedido processado.
- Plano de assinatura por volume para clinicas maiores.
- Servicos premium de analytics e previsao operacional.
5.2 Custos tecnicos principais
- Infra de hospedagem e observabilidade.
- Manutencao de gateway e trilha financeira.
- Evolucao de produto, QA e suporte operacional.
No recorte Sprint 1, o custo foi otimizado por entregas incrementais de infraestrutura, sem comprometer validacao de fluxo de negocio.
6. Hipoteses de validacao
- Nutricionistas aceitam migrar fluxo manual para painel estruturado.
- Pacientes concluem pagamento com baixa taxa de abandono.
- Fabrica opera com menor incidencia de inconsistencias de pedido.
- A experiencia white label melhora percepcao de confianca.
Cada hipotese possui metrica associada e criterio de sucesso operacional, permitindo decisao orientada por evidencias e nao por opiniao isolada de stakeholders.
7. Roadmap de monetizacao e escala
| Fase | Objetivo de negocio | Capacidade tecnica requerida |
|---|---|---|
| Sprint 1 | Validar fluxo principal | Jornada ponta a ponta funcional em ambiente controlado |
| Sprint 2 | Consolidar API e persistencia real | Integracao front-back e modelo de dados robusto |
| Sprint 3 | Expandir eficiencia operacional | Relatorios, filtros, alertas e historico confiavel |
| Sprint 4 | Escala comercial | Assinaturas, SLA por clinica e telemetria de performance |
8. Unidade economica de referencia (MVP)
| Indicador | Definicao operacional | Uso na decisao |
|---|---|---|
| CAC colaborativo | Custo medio de ativacao por clinica parceira | Definir limite de investimento por canal |
| Ticket medio por pedido | Receita media por transacao concluida | Ajustar estrategia de comissao e margem |
| Taxa de conversao do paciente | Confirmacao + pagamento / pedidos enviados | Priorizar melhorias de jornada |
| Custo operacional por pedido | Infra + suporte + retrabalho por transacao | Definir eficiencia de escala por sprint |
| Retencao de clinicas | Clinicas ativas apos ciclos recorrentes | Validar aderencia real da proposta de valor |
9. Riscos de modelo e resposta
| Risco | Efeito no negocio | Mitigacao prioritaria |
|---|---|---|
| Baixa adesao de nutricionistas | Reducao do funil de pedidos | Onboarding guiado e prova de valor por tempo poupado |
| Abandono no pagamento | Queda de receita e operacao ociosa | Jornada de pagamento mais curta e transparente |
| Inconsistencia operacional na fabrica | Aumento de custo de retrabalho | Padrao de status com validacao de transicoes |
| Escala sem governanca | Perda de qualidade percebida | Indicadores minimos por clinica e fase de rollout |
O canvas deve evoluir junto com dados reais de uso. Hipoteses que nao performarem devem ser substituidas por estrategias testaveis.
10. Jobs, dores e ganhos por perfil
| Perfil | Job principal | Dor dominante | Ganho esperado |
|---|---|---|---|
| Nutricionista | Montar e vender pedido com sua propria marca | Operacao fragmentada em chat e planilha | Mais previsibilidade e menor retrabalho |
| Paciente | Entender, confirmar e pagar sem inseguranca | Checkout confuso e pouca clareza do pedido | Compra simples e confiavel |
| Cozinha | Executar somente pedidos validos | Fila com informacao incompleta ou fora de ordem | Fluxo operacional limpo e rastreavel |
| Administrador | Monitorar saude da operacao | Baixa visibilidade consolidada | Decisao mais rapida por dados |
11. Experimentos de validacao do modelo
| Experimento | Hipotese testada | Metrica principal | Criterio de sucesso inicial |
|---|---|---|---|
| Piloto com clinica parceira | Nutricionista substitui parte do fluxo manual | Pedidos criados por semana | Pelo menos um pedido completo por nutricionista no ciclo |
| Jornada por codigo unico | Entrada simples reduz abandono | Acesso -> confirmacao | Maior parte dos acessos chega ao checkout |
| Liberacao por pagamento | Fila qualificada melhora execucao da cozinha | Pedidos pagos sem retrabalho | Baixa incidencia de correcao manual |
| White label visivel | Marca da clinica aumenta confianca do paciente | Conversao e feedback qualitativo | Reducao de duvidas sobre origem do pedido |
12. Recursos-chave e parceiros
| Categoria | Recurso ou parceiro | Papel no modelo |
|---|---|---|
| Produto | Front-end com jornadas por perfil | Captura o valor percebido e conduz o fluxo E2E |
| Tecnologia | Back-end NestJS e schema relacional alvo | Sustenta escalabilidade e governanca futura |
| Operacao | Cozinhas parceiras | Executam producao e entrega |
| Financeiro | Gateway de pagamento | Confirma o evento que libera producao |
| Canal | Vercel e GitHub Pages | Viabilizam demonstracao publica do app e dos artefatos tecnicos |