← Tenderely BPM
MÓDULO

Help desk e tickets de suporte num só fluxo

Enquanto o suporte chega por e-mail, faltam sempre duas coisas: quem é responsável pelo pedido e quanto tempo esperou. Uma caixa de entrada não é uma fila. O Tenderely BPM transforma o pedido em registo, atribui-lhe um responsável e deixa o sistema contar o tempo.

Ilustração isométrica de um centro de atendimento ao cliente

O que é que um processo de suporte repete?

01
Receber o pedido
Seja como chegar, tem de entrar numa forma única; uma mensagem em texto livre não pode ser priorizada.
02
Classificação e prioridade
Nada pode ser atribuído antes de o assunto e a urgência estarem definidos; 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
Acompanhamento 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 solução anterior tem de ser localizável.
06
Feedback
A pergunta de satisfação após o encerramento é o único dado que mostra se o serviço realmente melhorou.

Onde é que isto falha hoje?

Os tickets vivem numa caixa de entrada
E-mail para um endereço partilhado não forma uma fila; porque ninguém sabe quem está no quê, alguns são respondidos duas vezes e outros nenhuma.
Nada é medido
"Respondemos em quatro horas" é dito, mas nunca medido, por isso quanto tempo realmente demora é desconhecido.
A mesma pergunta é resolvida duas vezes
Um problema resolvido no mês passado é investigado novamente este mês, porque a solução ficou na cabeça de alguém.
A carga de trabalho é invisível
Quem está com quantos tickets, e quem está a afogar-se, só pode ser descoberto perguntando.

O que muda com o Tenderely BPM

01
O ticket é dados estruturados
Um formulário público coloca cada pedido numa forma única, com assunto, urgência e anexos como campos que podem ser ordenados.
02
O sistema conta o SLA
Os passos têm prazos, e os tickets prestes a violar ficam separados dos que já violaram.
03
Cada ticket tem um responsável
É atribuído a um papel ou a uma pessoa, nunca órfão, e move-se com o seu historial quando transferido.
04
O historial é pesquisável
Os tickets encerrados mantêm-se no registo, por isso um problema similar encontra a resolução anterior.
05
Os solicitantes acompanham o seu próprio
Um cliente ou colaborador 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, coleciona pedidos numa forma única e coloca-os directamente no seu processo. Os webhooks de entrada também podem abrir tickets a partir de um sistema externo.

O SLA pode depender do assunto?

+
Sim. A ramificação condicional define prazos diferentes por urgência ou tipo de cliente, e um ticket prestes a violar levanta um aviso automaticamente.

Podemos usá-lo para suporte interno?

+
Sim. A mesma estrutura funciona como uma secretaria interna para IT, RH ou instalações, e as permissões por unidade e papel decidem qual a equipa que vê quais pedidos.