Help desk e tickets de suporte num único fluxo.
Enquanto o suporte chega por e-mail, duas coisas faltam sempre: quem é responsável pelo pedido e há quanto tempo aguarda. Uma caixa de entrada não é uma fila. Tenderely BPM transforma o pedido num registo, atribui-lhe um responsável e deixa o sistema contar o tempo.
O que é que um processo de suporte repete?
01
Receber o pedido
Independentemente de como chega, tem de ter uma forma única; uma mensagem de texto livre não pode ser priorizada.
02
Classificação e prioridade
Nada pode ser atribuído antes de definir o assunto e a urgência; uma fila onde tudo é urgente não é uma fila.
03
Atribuição
Um ticket precisa de um responsável. Um deixado para « alguém » torna-se responsabilidade de ninguém.
04
Rastreamento de SLA
Se os tempos de primeira resposta e resolução são contratuais, têm de ser medidos; uma promessa não medida não é cumprida.
05
Resolução e conhecimento
Quando o mesmo problema volta, a correção anterior tem de ser localizável.
06
Feedback
A pergunta de satisfação após encerramento é o único dado que mostra se o serviço melhorou de facto.
Onde é que isto falha atualmente?
Tickets vivem numa caixa de entrada
E-mail para um endereço partilhado não forma uma fila; porque ninguém sabe quem está em quê, alguns são respondidos duas vezes e outros nenhuma.
Nada é medido
« Respondemos em quatro horas » diz-se, mas nunca é medido, portanto quanto tempo leva de facto é desconhecido.
A mesma pergunta é resolvida duas vezes
Um problema corrigido no mês passado é pesquisado de novo este mês, porque a correção ficou na cabeça de alguém.
A carga de trabalho é invisível
Quem tem quantos tickets e quem está sobrecarregado só pode ser descoberto perguntando.
O que muda com Tenderely BPM
01
O ticket é dados estruturados
Um formulário público coloca cada pedido numa forma única, com assunto, anexos e impacto comercial (processo afectado, quantos utilizadores, solução alternativa, prazo comercial) como campos. A IA define a prioridade a partir destas respostas; se tiver dúvida, o gestor escolhe.
02
O sistema conta o SLA
Os passos têm prazos e tickets prestes a ultrapassar ficam separados dos que já ultrapassaram. Um lembrete é enviado um dia antes do prazo comercial.
03
Cada ticket tem um responsável
É atribuído a um papel ou pessoa, nunca órfão, e move-se com o seu histórico quando transferido.
04
O histórico é pesquisável
Tickets encerrados mantêm-se no registo, assim um problema semelhante encontra a resolução anterior.
05
Solicitantes rastreiam os seus
Um cliente ou funcionário conecta-se como utilizador externo ligado e vê apenas o seu ticket, sendo notificado por e-mail conforme se move.
PERGUNTAS FREQUENTES
Os pedidos ainda podem chegar por e-mail?
+
Uma ligação de formulário público ou um formulário incorporado no seu site recolhe pedidos numa forma única e coloca-os directamente no seu processo. Webhooks de entrada podem também abrir tickets a partir de um sistema externo.
O SLA pode depender do assunto?
+
Sim. Ramificação condicional define prazos diferentes por urgência ou tipo de cliente, e um ticket prestes a ultrapassar levanta um aviso por si próprio.
Podemos usá-lo para suporte interno?
+
Sim. A mesma estrutura funciona como um balcão interno para TI, RH ou instalações, e permissões ao nível de unidade e papel decidem qual equipa vê quais pedidos.