Aplica-se a todos os planos do DataVault: Gratuito, Team, Business e Enterprise. Diz como pedir ajuda, quando respondemos e o que esperar de manutenções e descontinuações. Última revisão: 29 de setembro de 2026.
Esta política não é um acordo de nível de serviço (SLA). Os tempos de primeira resposta abaixo são objetivos que a Praxis se compromete a cumprir. Nenhum plano inclui, por omissão, um SLA com créditos; um SLA só vincula a Praxis quando consta de contrato assinado (Termos de Serviço, secção 5). As condições próprias do Enterprise, como tempos por severidade, um canal dedicado e relatórios de saúde do serviço, ficam no contrato de cada cliente.
1. Canais
- Na app, o botão «Pedir ajuda». Está na barra lateral e na página Ajuda. Escreves o assunto, a categoria e a
descrição. O pedido segue para a equipa de suporte com contexto técnico automático: o identificador do workspace, o
plano, a versão da app, a página em que estavas, o idioma e o navegador. Nunca leva dados das tuas fontes. Recebes
um número de pedido (
sup_…) para referência. A resposta chega ao email da tua conta. - Email: suporte@praxis.lbostuff.tech. Escreve a partir do email da conta. Este canal funciona mesmo sem sessão iniciada.
- Vulnerabilidades de segurança: usa o contacto de segurança publicado em
/.well-known/security.txte na página Segurança do site. Não uses o suporte geral para isto. - Proteção de dados (RGPD): privacidade@praxis.lbostuff.tech.
2. Horário
O suporte funciona nos dias úteis, de segunda a sexta, das 9h00 às 18h00, hora de Lisboa. Não funciona nos feriados nacionais de Portugal. Um pedido que chega fora deste horário fica na fila. O tempo de resposta começa a contar no início do período útil seguinte.
3. Tempo de primeira resposta por plano
| Plano | Primeira resposta |
|---|---|
| Gratuito | Melhor esforço, sem tempo garantido |
| Team | Até 1 dia útil |
| Business | Até 4 horas úteis |
| Enterprise | Conforme o contrato |
A primeira resposta é a de uma pessoa da equipa. Nela confirmamos que recebemos o pedido e damos um primeiro diagnóstico ou pedimos a informação que falta. Não é o prazo de resolução. Os tempos contam só dentro do horário da secção 2. Vale o plano que está em vigor no workspace no momento do pedido; durante uma experimentação, é o plano experimentado.
4. Severidades
| Severidade | Quando | Exemplos |
|---|---|---|
| S1: crítica | O serviço está indisponível ou há risco para a segurança dos dados, sem alternativa | A app ou a API não respondem para todo o workspace; suspeita de acesso indevido |
| S2: alta | Uma funcionalidade principal falha e não há alternativa razoável | Nenhum scan corre; os alertas deixaram de chegar |
| S3: normal | Uma funcionalidade falha em parte, ou há alternativa | Um conector falha numa fonte; um relatório demora mais do que o habitual |
| S4: baixa | Dúvidas de utilização, pedidos de funcionalidade, documentação | «Como configuro…?»; sugestões |
A equipa de suporte atribui a severidade na triagem, a partir da descrição. Indica o impacto na descrição para a triagem ser certa. Nos planos Gratuito, Team e Business, os tempos da secção 3 valem para todas as severidades, e os pedidos S1 e S2 são tratados primeiro. Tempos diferentes por severidade só existem no Enterprise, por contrato.
5. O que incluir num pedido
- O que tentavas fazer e o que aconteceu, com a mensagem de erro exata, se houver.
- Quando aconteceu, com data, hora e fuso, e se se repete.
- Onde aconteceu: a página da app e o nome do dataset, da regra ou da conexão. Dá o nome só se o puderes partilhar.
- O impacto: quantas pessoas ou processos estão afetados e se há alternativa.
- Para a API: o método e o caminho, o estado HTTP, a hora em UTC, o cabeçalho
X-Request-IDda resposta e a resposta deGET /version. Nunca envies o token.
Nunca envies passwords, tokens, chaves de API nem dados pessoais das tuas fontes. Se precisarmos de ver o teu workspace, pedimos acesso de suporte. Esse acesso é só de leitura, tem prazo e só começa quando um admin do teu workspace o aprova.
6. Manutenções planeadas
A maior parte das atualizações não precisa de janela de manutenção. Uma intervenção pode interromper ou degradar a app, a API ou os scans. Nesse caso anunciamo-la por email aos admins dos workspaces com pelo menos 5 dias úteis de antecedência, com a data, a hora e a duração prevista. Fazemo-la fora do horário de suporte, de preferência entre as 20h00 e as 23h00, hora de Lisboa.
Correções urgentes de segurança podem obrigar a uma intervenção sem aviso prévio. Nesse caso comunicamo-la logo que possível.
7. Descontinuação de funcionalidades
Retirar ou mudar de forma incompatível uma funcionalidade de um plano pago exige um aviso com pelo menos 90 dias
de antecedência. O aviso vai por email aos admins dos workspaces e aparece nas notas de versão (/datavault/changelog do site).
A API pública tem uma política própria, mais longa, com 180 dias entre o anúncio e a remoção
(versionamento da API). Uma obrigação legal ou um risco de segurança podem obrigar a um
prazo mais curto; nesse caso explicamos porquê no aviso.
8. Estado do serviço e incidentes
A página de estado pública ainda não está publicada. Quando estiver, a ligação fica nesta secção. Até lá, os incidentes que afetem o serviço são comunicados por email aos admins dos workspaces afetados. Depois de um incidente S1, enviamos um resumo da causa e das medidas tomadas.
9. Alterações a esta política
Uma alteração que reduza o suporte, seja nos canais, no horário ou nos tempos de resposta, é anunciada por email aos admins com pelo menos 30 dias de antecedência. A data da última revisão está no topo desta página.