Clientes: ficha, histórico, RGPD e portal self-service

O modelo Customer guarda tudo o que importa para reconhecer e contactar:

• Email e telefone (com código de país e número sanitizados).
• NIF português (validado quando preenchido).
• Nome e data de nascimento.
• Última visita (last_visit) — actualizada automaticamente.
• Notas internas em texto livre — para o profissional registar contexto que não cabe no histórico estruturado.

Estado do cliente

• active — cliente activo no sistema.
• is_blacklisted — cliente bloqueado de fazer novas marcações pelo portal público.

Consentimento de marketing

O atributo accepts_marketing guarda explicitamente se o cliente autorizou comunicação não transaccional. Importante para alinhamento com RGPD.

A ficha do cliente liga-se a:

• Marcações — todas, em qualquer estado, com profissional e serviço.
• Transações — pagamentos recebidos, devoluções, créditos.
• Comentários internos (CustomerComment) — anotações da equipa, ordenadas no tempo.
• Audit log (CustomerAuditLog) — quem alterou que dados e quando.

O contador bookings_count é desnormalizado para queries rápidas em listagens de clientes mais frequentes.

Para reduzir fakes e marcações lixo, o FIRO suporta verificação opcional do cliente antes de finalizar a marcação:

1. Cliente insere NIF (ou outro identificador) na página pública.
2. Recebe um PIN por SMS ou email.
3. Confirma o PIN para concluir a marcação.

Esta validação está implementada em BookingContactVerificationService + endpoint /booking/request-verification-code. É activável por tenant.

O FIRO trata o cliente como entidade global — não há um Customer por tenant. Vantagens:

• Cliente que se mude entre fornecedores no FIRO mantém o seu acesso e ficha.
• Ao registar-se uma vez, pode marcar em qualquer tenant que use FIRO sem repetir dados.
• O histórico está sempre lá quando o cliente regressa.

As marcações são tenant-scoped — cada negócio só vê as suas. O cliente é a "ponte" que liga visões entre tenants do ponto de vista do cliente, não do negócio.

Cada cliente tem acesso a um portal pessoal com login por magic link ou Google OAuth. Lá pode:

• Ver o histórico de marcações com estado actual.
• Cancelar marcações futuras (sujeito ao cancel_min_hours configurado pelo tenant).
• Editar o perfil — email, telefone, NIF, consentimentos.
• Abrir tickets de suporte dirigidos ao tenant.
• Pedir exportação ou eliminação RGPD dos dados.

Reduz drasticamente o volume de chamadas que a recepção atende para "mudar a marcação para outra hora".

Para tenants que migram de outras ferramentas, há um pipeline de importação:

• Upload de CSV com mapeamento de colunas.
• CsvSource regista de onde veio cada lote (qual ficheiro, mapeamento, data).
• Cada cliente importado fica marcado com csv_source_id para rastreio.

Marcações importadas em massa

Se a importação trouxer também marcações históricas, ficam com a flag is_contact_import para distinguir de marcações criadas no produto.

O FIRO suporta os direitos do titular dos dados via GdprRequest:

• Pedido de exportação: entrega ao cliente um pacote com os seus dados (perfil, marcações e transações).
• Pedido de eliminação: retira os dados pessoais do cliente nessa loja; as faturas ficam guardadas pelo prazo legal.

O pedido só conta depois de o cliente abrir o link enviado para o email e, se indicou telemóvel, introduzir o código enviado por SMS. Nessa altura o cliente recebe um email com o prazo legal (30 dias), o dono da loja recebe um email e um aviso no backoffice, e a equipa da plataforma recebe um email para tratar do pedido no admin.

Cada vez que dados sensíveis do cliente mudam, é gravado em CustomerAuditLog: quem alterou, que campo, valor anterior e novo. Isto é importante para:

• Resolver queixas ("o meu telefone no sistema está errado, alguém mudou").
• Demonstrar conformidade RGPD em caso de auditoria.
• Recuperar valores perdidos por engano.