O PROJETO
Cuidado não deveria depender de matching aleatório.
O Z8N foi pensado como uma plataforma de coordenação de cuidado e suporte, não como um simples marketplace.
A lógica central parte da necessidade da pessoa, avalia contexto, riscos e requisitos, identifica as capacidades necessárias e só então procura profissionais adequados para aquela situação.
Isso muda completamente a arquitetura do produto.
Em desenvolvimento
Produto real em construção contínua.
Backend
Arquitetura modular em PHP.
MySQL
Dados relacionais e operacionais.
Piloto
Estrutura inicial voltada para Goiânia.
O PROBLEMA
Uma solicitação de cuidado contém muito mais informação do que um nome de serviço.
“Cuidado de idoso” ou “apoio pós-cirúrgico” não explicam mobilidade, risco, cognição, equipamentos, urgência, dependência ou capacidades necessárias.
NECESSIDADE
Pedidos vagos
Uma descrição curta raramente contém informação suficiente para decidir quem realmente está preparado para atender.
RISCO
Contexto operacional
Mobilidade, cognição, risco de queda, equipamentos e condições do ambiente podem mudar completamente a missão.
CAPACIDADE
Nem todo profissional serve para toda situação
Disponibilidade sozinha não significa capacidade para executar um atendimento específico.
OPERAÇÃO
Depois do matching ainda existe trabalho
Aceite, deslocamento, início, acompanhamento e conclusão da missão também fazem parte do sistema.
MODELO OPERACIONAL
Need → Assessment → Requirements → Match → Mission.
A arquitetura do Z8N segue a lógica da operação real, não uma lista de profissionais disponíveis.
01
Need
A pessoa informa localização e o que precisa.
02
Assessment
O sistema aprofunda a situação, contexto e riscos.
03
Requirements
A necessidade é transformada em capacidades exigidas.
04
Match
Profissionais são filtrados por adequação e disponibilidade.
05
Dispatch
A operação encaminha a missão ao profissional adequado.
06
Mission
A execução é acompanhada até conclusão ou encerramento.
ASSESSMENT ENGINE
Antes do matching, o sistema precisa compreender a situação.
A avaliação foi estruturada para capturar condições operacionais reais em vez de depender de classificações vagas como “baixa” ou “média complexidade”.
- Tipo e urgência da missão
- Número de pessoas assistidas
- Faixa etária
- Mobilidade
- Cognição e comunicação
- Pessoa acamada
- Higiene e alimentação
- Transferências e mobilidade
- Monitoramento noturno
- Risco de queda
- Demência e supervisão
- Oxigênio e equipamentos
- Cateter, sonda ou ostomia
- Pós-cirúrgico
- Presença de familiares ou outro cuidador
NETWORKS
Uma plataforma, duas redes operacionais.
O escopo atual concentra-se em Care Network e Pet Network.
CARE NETWORK
Cuidado & Suporte
Assistência a idosos, recuperação, mobilidade, cuidado pessoal, acompanhamento e suporte domiciliar.
PET NETWORK
Pet Care
Passeios, companhia, alimentação, medicação, pós-cirúrgico, cuidado de pets idosos e outras necessidades.
EXPERIÊNCIA
Complexidade por trás. Clareza na frente.
A plataforma pode ter dezenas de regras internas, mas o usuário não deveria sentir esse peso.
Para a família ou cliente, a experiência começa com uma pergunta simples: onde você está e do que precisa?
A complexidade aparece progressivamente apenas quando a informação realmente é necessária.
ADMINISTRATION
A operação exige um sistema administrativo tão sério quanto a área pública.
O Z8N possui uma administração modular para acompanhar acesso, redes, geografia, operações, configurações e segurança.
ACCESS
Controle de acesso
Administradores, funções, permissões, sessões, escopos e atividades.
NETWORKS
Care & Pet
Gestão das redes, profissionais, disponibilidade, bookings, missões e verificações.
GEOGRAPHY
Cobertura territorial
Países, regiões, estados, cidades, zonas e áreas operacionais.
SETTINGS
Configuração global
Operação, segurança, integrações, notificações e manutenção do sistema.
PROFESSIONAL FLOW
O profissional também precisa de um fluxo operacional claro.
- Available
- On Mission
- Offline
- Recebimento de missão
- Aceite
- Deslocamento
- Verificação de chegada
- Início da missão
- Acompanhamento
- Conclusão
TECHNICAL ARCHITECTURE
PHP, MySQL e modularidade como base.
Plain PHP
Backend controlado diretamente sem dependência obrigatória de framework pesado.
MySQL
Dados relacionais para usuários, operações, permissões e histórico.
Reusable partials
Tabelas, filtros, navegação, modais e componentes compartilhados entre módulos.
Domain-based folders
A arquitetura separa áreas como access, geography, networks e operations.
Mobile-first public experience
Fluxos públicos são pensados primeiro para celular.
Admin expansion
A estrutura suporta diferentes funções administrativas e escopos conforme a operação cresce.
O QUE ESTE PROJETO DEMONSTRA
ISEUB não está limitada a websites institucionais.
O Z8N funciona como demonstração prática de arquitetura de produto, operação, dados e sistemas administrativos.
PRODUCT
Product thinking
O sistema é construído a partir de um problema operacional.
ARCHITECTURE
Arquitetura modular
Módulos independentes com responsabilidades claras.
OPERATIONS
Fluxos reais
O produto acompanha ações e mudanças de estado.
ADMIN
Administração complexa
Controle operacional separado da experiência pública.
STATUS
O produto continua em desenvolvimento.
Este estudo de caso não apresenta o Z8N como um produto finalizado.
A plataforma continua sendo desenvolvida, revisada e expandida conforme novos módulos e necessidades operacionais são definidos.
O objetivo do case study é mostrar a arquitetura e o raciocínio reais por trás do projeto.