prompt inicial do projeto
This commit is contained in:
116
docs/00-VISAO-E-PRODUTO.md
Normal file
116
docs/00-VISAO-E-PRODUTO.md
Normal file
@@ -0,0 +1,116 @@
|
||||
# 00 — Visão e produto
|
||||
|
||||
## 1. O problema
|
||||
|
||||
Portaria física custa caro: três porteiros em turno somam encargos, férias, rotatividade e treinamento. Condomínios brasileiros vêm migrando para portaria remota — cerca de 12% dos síndicos já usam, com NPS 48 e redução de até 50% no custo de segurança.
|
||||
|
||||
Mas as soluções estabelecidas do mercado funcionam com **interfone inteligente + operador humano remoto 24h**. O condomínio troca o porteiro do prédio por um operador em central. Economiza, mas continua pagando por gente de plantão.
|
||||
|
||||
**Nossa aposta:** na maioria das interações, quem decide quem entra é o próprio morador — não um operador. Se o morador atende direto pelo vídeo, o operador vira exceção em vez de regra, e o custo cai de novo.
|
||||
|
||||
**O risco dessa aposta, assumido de olhos abertos:** a taxa de atendimento do morador não é 100%. Gente em reunião, dirigindo, dormindo, com o celular no silencioso. Por isso o produto não vende "sem operador" — vende **dois planos**, e o operador é retaguarda paga para quem quiser cobertura.
|
||||
|
||||
## 2. Personas
|
||||
|
||||
| Persona | Contexto | O que não pode acontecer |
|
||||
|---|---|---|
|
||||
| **Visitante** | Em pé na calçada, no sol, celular na mão, talvez sem saber português direito | Esperar mais de 30s sem feedback, ou precisar instalar app |
|
||||
| **Entregador** | Tem mais 12 entregas, moto ligada, pressa real | Videochamada obrigatória. Ele vai embora ou larga na calçada |
|
||||
| **Morador** | Trabalhando, dirigindo, dormindo | Chamada que não toca de verdade (o caso do iOS sem CallKit) |
|
||||
| **Responsável pela abertura** | Zelador ou segurança no local | Receber autorização sem saber quem é a pessoa |
|
||||
| **Operador** | Central remota, várias visitas em paralelo | Fila sem contexto: precisa ver foto e histórico antes de atender |
|
||||
| **Síndico / administradora** | Presta contas à assembleia; responde juridicamente | Não conseguir provar o que aconteceu numa ocorrência |
|
||||
|
||||
## 3. Jornadas
|
||||
|
||||
### Visita (o caso "nobre", minoria do volume)
|
||||
|
||||
Chega → escaneia QR → vê aviso de tratamento de dados → permite câmera e localização → tira foto → informa bloco e unidade → **espera** → morador aparece no vídeo → conversa → autorizado → recebe PIN → o responsável pela abertura é notificado com a foto e abre.
|
||||
|
||||
**Ponto de maior atrito:** a espera. O visitante precisa ver progresso real ("chamando o morador", "chamando outros moradores da unidade", "transferindo para a portaria"), nunca um spinner mudo. Um spinner de 35 segundos é indistinguível de um app quebrado.
|
||||
|
||||
### Entrega (a maioria do volume)
|
||||
|
||||
Chega → escaneia QR → **[Entrega]** → foto do pacote → unidade → morador recebe push com dois botões e resolve sem abrir o app → "pode deixar na portaria" em ~6 segundos.
|
||||
|
||||
**Se ninguém responde em 15s**, aplica-se a regra padrão da unidade. O entregador nunca fica parado sem instrução.
|
||||
|
||||
### Prestador de serviço
|
||||
|
||||
Eletricista que fica 4h, mudança com caminhão. Fluxo de visita, mas o grant tem validade estendida e o registro guarda entrada e saída. **v2.**
|
||||
|
||||
### Sem smartphone / sem sinal / sem bateria
|
||||
|
||||
Botão físico na portaria → mesmo fluxo, sem celular nenhum. Ver `07-REQUISITOS-DE-CAMPO.md`.
|
||||
|
||||
## 4. Planos
|
||||
|
||||
| | **Autônomo** | **Assistido 24h** |
|
||||
|---|---|---|
|
||||
| Chamada para o morador | ✓ | ✓ |
|
||||
| Escalonamento na unidade | ✓ | ✓ |
|
||||
| Funil rápido de entrega | ✓ | ✓ |
|
||||
| Recado em vídeo | ✓ | ✓ |
|
||||
| **Fila de operador humano** | — | ✓ |
|
||||
| Promessa | "Você decide quem entra" | "Nunca fica sem resposta" |
|
||||
| Custo operacional | Só infraestrutura | Infraestrutura + plantão |
|
||||
|
||||
**Add-ons:** notificações por WhatsApp, gravação de chamadas, integração com hardware de portão, autorizações recorrentes.
|
||||
|
||||
Na v1 a cobrança é manual (contrato/boleto). O sistema controla apenas quais módulos estão ligados por tenant.
|
||||
|
||||
## 5. Escopo
|
||||
|
||||
### v1
|
||||
|
||||
Fluxo de visita completo, funil rápido de entrega, escalonamento com fila de operador, recado em vídeo, app do morador (Android + iOS), app do operador, painel admin com auditoria, planos e feature flags, LGPD (aviso, retenção, expurgo, exportação), PIN de abertura, um condomínio por instância com `tenant_id` já no schema.
|
||||
|
||||
### v2
|
||||
|
||||
Integração com hardware de portão, WhatsApp, autorizações recorrentes e pré-autorização, fluxo de prestador com entrada/saída, multi-tenancy ativado, billing automatizado, app do porteiro presencial (modo híbrido).
|
||||
|
||||
### Fora de escopo, com motivo
|
||||
|
||||
**Reconhecimento facial.** Eleva os dados a *sensíveis* na LGPD (art. 11), com exigência jurídica muito maior. Decisão de produto com fundamento legal — ver `06-LGPD-E-SEGURANCA.md`.
|
||||
|
||||
**Substituir 100% da portaria física.** Enquanto a abertura depender de humano e houver queda de energia ou internet, o condomínio precisa de contingência. Vender autonomia total seria desonesto.
|
||||
|
||||
## 6. Métricas
|
||||
|
||||
### Norte
|
||||
|
||||
**Visitas resolvidas sem operador humano.** É a tese do produto. Abaixo de ~70%, o modelo autônomo não se sustenta e o Assistido vira o produto principal.
|
||||
|
||||
### SLOs
|
||||
|
||||
| Métrica | Alvo |
|
||||
|---|---|
|
||||
| QR → celular do morador tocando (p95) | < 5s |
|
||||
| Taxa de atendimento pelo morador | > 70% |
|
||||
| QR → resposta em entrega (p95) | < 10s |
|
||||
| Abandono do entregador | < 10% |
|
||||
| Disponibilidade do fluxo de entrada | 99,5% |
|
||||
|
||||
### Saúde da operação
|
||||
|
||||
Visitas por dia e por tipo · fila de operador (tempo médio e pico) · **push falhados por dispositivo** (detecta token morto antes de virar reclamação) · moradores sem app instalado por condomínio · recados não resolvidos em 24h.
|
||||
|
||||
**Alerta de negócio:** se a taxa de atendimento de um condomínio cai abaixo de 50% por 7 dias, algo está errado — moradores sem app, tokens expirados ou base desatualizada. Vira tarefa de customer success, não incidente técnico.
|
||||
|
||||
## 7. Riscos
|
||||
|
||||
| Risco | Mitigação |
|
||||
|---|---|
|
||||
| Morador não atende com frequência | Plano Assistido, escalonamento, regra padrão de entrega, alerta de baixa adesão |
|
||||
| Entregador abandona | Funil de 1 toque com meta de 10s e regra padrão |
|
||||
| Base de moradores desatualiza | `valid_until` + relatório de reconciliação + importação CSV |
|
||||
| Hall sem sinal de celular | Wi-Fi de visitante como requisito contratual |
|
||||
| Autorização indevida gera responsabilidade | Auditoria íntegra com hash de mídia; contrato define responsabilidade |
|
||||
| Concorrência estabelecida | Diferencial é custo e experiência do morador, não substituir a central |
|
||||
| Sistema cai e ninguém entra | Modo degradado + contingência física contratada |
|
||||
|
||||
## 8. Referências de mercado
|
||||
|
||||
- [SíndicoNet — adoção e economia da portaria remota](https://www.sindiconet.com.br/informese/economia-para-condominios-manutencao-portaria-virtual)
|
||||
- [TownSq — como funciona a portaria remota](https://blog.townsq.com.br/inovacao/portaria-remota/)
|
||||
- [ConJur — reconhecimento facial em condomínios sob a LGPD](https://www.conjur.com.br/2024-abr-07/reconhecimento-facial-em-condominios-desafios-sob-a-otica-da-lgpd/)
|
||||
Reference in New Issue
Block a user