Objetivo deste artigo
Este artigo orienta o parceiro sobre quando uma solicitação do cliente deve ser tratada como customização e encaminhada para avaliação da Dersalis.
Use este guia quando o cliente pedir alterações em monitoramentos, cenários de risco, gatilhos, parâmetros, tratativas, notificações ou fluxos operacionais que saiam da configuração inicial recomendada.
Para entender quais configurações não devem ser alteradas no início, consulte Configurações que não devem ser alteradas no início [ADICIONAR LINK].
Regra principal
Toda customização que altere a lógica de risco, a interpretação dos incidentes, o protocolo de resposta ou o suporte da operação deve ser validada com a Dersalis antes de ser prometida ou aplicada.
O parceiro não deve tratar toda solicitação do cliente como uma simples configuração.
Algumas mudanças parecem pequenas, mas podem afetar:
quantidade de incidentes gerados;
intensidade dos alertas;
comportamento de agravamento;
regras de encerramento;
necessidade de tratativa;
notificações via WhatsApp;
entendimento do operador;
atuação da supervisão;
interpretação de relatórios;
suporte de primeiro nível.
O que é uma customização
Neste contexto, customização é qualquer alteração que modifica o comportamento recomendado da solução para atender uma necessidade específica do cliente.
Pode envolver:
criação de novos cenários de risco;
alteração em cenários existentes;
uso de gatilhos diferentes dos recomendados;
combinação de gatilhos;
alteração de limiares;
alteração de intensidade de risco;
alteração de agravamento;
alteração de encerramento;
alteração de tratativa;
mudança em notificações;
mudança no protocolo de resposta;
uso de dispositivo não homologado;
integração com sistema externo;
demanda por dashboard, relatório ou fluxo específico.
Nem toda customização é proibida. O ponto é que ela precisa ser avaliada, aprovada e documentada.
Quando uma customização pode fazer sentido
Uma customização pode fazer sentido quando há uma necessidade operacional clara.
Exemplos:
o padrão não atende ao contexto da operação;
o cliente possui requisito interno obrigatório;
o protocolo de resposta do cliente exige uma variação;
há evidências de que um cenário está gerando alertas demais;
há evidências de que um cenário está gerando alertas de menos;
o primeiro uso mostrou uma necessidade real de ajuste;
a operação possui risco específico não coberto pelo padrão;
a equipe responsável tem maturidade para operar uma lógica mais avançada;
há necessidade de integração com processo interno do cliente.
A customização deve resolver um problema concreto, não apenas atender curiosidade ou preferência inicial.
Quando não solicitar customização
Não solicite customização quando:
o cliente ainda não realizou o primeiro uso;
a operação ainda não entendeu os alertas padrão;
os operadores ainda não foram treinados;
o problema parece ser falta de treinamento;
o problema parece ser falha de uso do dispositivo;
o problema parece ser conectividade ou cadastro;
a solicitação é apenas preferência sem impacto operacional;
o cliente quer “ver todas as possibilidades”;
a equipe ainda não definiu quem responde aos incidentes;
a mudança tornaria o suporte inicial mais confuso.
Nesses casos, recomende começar pela configuração inicial e revisar depois da experiência real.
Tipos de customização que exigem avaliação da Dersalis
1. Alterações em gatilhos
Solicite avaliação da Dersalis antes de:
trocar o gatilho de um cenário;
adicionar gatilhos a um cenário existente;
combinar múltiplos gatilhos;
ativar gatilhos não previstos no caso de uso;
remover gatilho recomendado.
Gatilhos afetam diretamente a geração de incidentes e devem ser tratados com cuidado.
2. Alterações em intensidade de risco
Solicite avaliação antes de:
aumentar a intensidade inicial;
reduzir a intensidade inicial;
alterar níveis de criticidade;
configurar cenários para iniciar em níveis mais altos;
ajustar risco apenas por percepção subjetiva do cliente.
A intensidade precisa estar alinhada ao risco e à resposta esperada.
3. Alterações em ocorrência mínima
Solicite avaliação antes de alterar a condição mínima para geração de incidente.
Mudanças nesse ponto podem fazer a plataforma gerar incidentes cedo demais ou tarde demais.
4. Alterações em agravamento
Solicite avaliação antes de mudar quando ou como um incidente sobe de nível.
O agravamento impacta prioridade, tratativa, notificação e interpretação histórica.
5. Alterações em encerramento
Solicite avaliação antes de alterar regras de encerramento automático, manual ou por condição.
Encerramentos mal configurados podem gerar histórico inconsistente ou incidentes ativos por tempo inadequado.
6. Alterações em tratativas
Solicite avaliação quando o cliente quiser mudar:
quais incidentes exigem tratativa;
quem deve tratar;
quando a tratativa deve ocorrer;
como a tratativa será registrada;
quais opções de resposta estarão disponíveis;
como o WhatsApp será usado na resposta operacional.
A tratativa precisa ter responsável claro e protocolo definido.
7. Alterações em alertas ao colaborador
Solicite avaliação quando o cliente quiser ativar, desativar ou mudar alertas enviados ao colaborador.
Antes de alterar, confirme se:
o operador será treinado;
o alerta tem ação esperada;
a notificação não atrapalha a atividade;
a supervisão entende seu papel;
o protocolo do cliente está preparado.
8. Novos cenários de risco
Solicite avaliação antes de criar cenários que não estejam previstos na configuração inicial.
Cada novo cenário precisa ter:
objetivo claro;
gatilho definido;
parâmetro recomendado;
nível de risco coerente;
responsável por resposta;
critério de tratativa;
impacto entendido.
9. Dispositivos não homologados
Solicite avaliação quando o cliente pedir uso de sensor, smartwatch, celular ou equipamento diferente dos homologados atualmente.
Atualmente, os dispositivos homologados são:
Polar 360;
Polar Verity Sense;
smartwatch IS-SW1.1 da i.safe Mobile.
Outros dispositivos não devem ser prometidos como disponíveis sem validação formal da Dersalis.
10. Integrações e fluxos externos
Solicite avaliação quando o cliente pedir:
integração com sistema externo;
API;
envio de dados para terceiros;
integração com torre de controle externa;
dashboards específicos fora do padrão;
automações fora do fluxo atual;
relatórios customizados.
O parceiro não deve prometer integração sem validação técnica e comercial.
Como avaliar uma solicitação antes de enviar à Dersalis
Antes de encaminhar a solicitação, o parceiro deve entender:
qual problema o cliente quer resolver;
por que a configuração padrão não atende;
se o pedido é obrigatório ou apenas desejável;
se já houve primeiro uso;
se há dados reais sustentando a solicitação;
qual operação será afetada;
quais usuários serão afetados;
qual impacto esperado;
se a mudança afeta treinamento;
se a mudança afeta suporte;
se a mudança afeta interpretação dos alertas;
se a mudança precisa ser aplicada antes ou depois do início da operação.
Quanto mais clara for a solicitação, mais rápida será a avaliação.
Informações que devem ser enviadas à Dersalis
Ao solicitar customização, envie:
nome do cliente;
operação ou unidade envolvida;
monitoramento afetado;
cenário de risco afetado, se houver;
gatilho afetado, se houver;
configuração atual;
alteração solicitada;
motivo da solicitação;
problema que a mudança pretende resolver;
impacto esperado;
urgência;
se já houve primeiro uso;
evidências disponíveis;
responsável do cliente que solicitou;
responsável do parceiro;
prazo desejado.
Evite enviar solicitações genéricas como “cliente quer mudar o alerta” ou “cliente pediu algo mais sensível”. Explique exatamente o que precisa ser avaliado.
Como responder ao cliente enquanto a customização é avaliada
Use uma resposta clara e controlada:
Essa alteração precisa ser avaliada pela Dersalis antes de ser confirmada, porque pode impactar a geração de incidentes, a interpretação dos alertas e o suporte da operação. Vamos registrar a necessidade, validar tecnicamente e retornar com a orientação correta.
Evite dizer:
“Sim, conseguimos fazer.”
“É só configurar.”
“Isso é simples.”
“Podemos mudar depois sem problema.”
“A plataforma permite, então dá para fazer.”
Mesmo quando a plataforma permite uma alteração, isso não significa que ela deve ser aplicada.
Possíveis decisões da Dersalis
Após avaliação, a Dersalis pode:
aprovar a customização;
aprovar com ajustes;
recomendar manter o padrão;
recomendar aguardar primeiros ciclos de uso;
solicitar mais informações;
sugerir outra solução operacional;
negar a customização por risco técnico, operacional ou comercial.
A decisão deve ser registrada para evitar dúvidas futuras.
Depois que uma customização for aprovada
Se a customização for aprovada, o parceiro deve:
aplicar a alteração conforme orientação;
registrar o que foi alterado;
informar o cliente sobre o comportamento esperado;
ajustar treinamento, se necessário;
validar a configuração na plataforma;
acompanhar os primeiros usos após a mudança;
monitorar se a customização resolveu o problema;
registrar efeitos indesejados, se houver.
Para registrar a alteração, consulte Como documentar exceções do cliente [ADICIONAR LINK].
O que evitar
Evite:
prometer customização antes de validação;
aplicar alteração apenas por pressão comercial;
modificar gatilhos sem entender impacto;
criar cenários sem resposta operacional clara;
alterar intensidade para “reduzir ruído” sem análise;
ativar todos os recursos para impressionar o cliente;
tratar customização como correção de treinamento;
alterar regras sem registrar;
criar exceções que só uma pessoa entende;
não avisar suporte sobre mudanças aplicadas.
Checklist antes de solicitar customização
Antes de acionar a Dersalis, confirme:
a solicitação está clara;
o problema foi identificado;
o padrão foi testado ou justificada a impossibilidade de testar;
há impacto operacional real;
o cliente entende que a mudança depende de avaliação;
a operação afetada foi identificada;
o monitoramento ou cenário afetado foi identificado;
o impacto em treinamento e suporte foi considerado;
o pedido foi documentado;
há responsável do cliente pela solicitação.
Resultado esperado
Ao seguir este artigo, o parceiro deve saber quando uma solicitação deve ser encaminhada à Dersalis e quais informações precisam acompanhar o pedido.
O objetivo é evitar customizações improvisadas e garantir que alterações em monitoramentos, cenários, gatilhos, tratativas ou dispositivos sejam feitas com critério, registro e validação.
Próximo passo
Se uma customização for aprovada ou se uma exceção precisar ser registrada, siga para Como documentar exceções do cliente [ADICIONAR LINK].
Resumo
Customizações devem ser tratadas como decisões controladas, não como ajustes improvisados.
O parceiro deve solicitar apoio da Dersalis sempre que a mudança afetar lógica de risco, gatilhos, intensidades, agravamento, encerramento, tratativas, alertas, dispositivos, integrações ou interpretação dos dados.
A regra é: não prometa, não aplique e não improvise antes de validar.