Quando um pedido de suporte é também uma transação
As questões dos comerciantes são quase sempre sobre uma transação, payout ou fatura específica. Num helpdesk genérico que funciona fora do painel de pagamentos, o pedido começa como uma conversa em branco, e o agente tem de copiar referências de transação, IDs de comerciante e datas entre dois sistemas antes de poder sequer analisar o que o comerciante está a perguntar.
Abrir um pedido onde o registo já existe
Em vez disso, o comerciante pode abrir um pedido diretamente a partir da transação, fatura ou carteira que está a consultar, de forma que a referência acompanha a conversa em vez de ser colada nela. O operador que responde ao pedido está a ver o registo real, não uma captura de ecrã ou um identificador copiado.
Uma única fila, as mesmas permissões
Os gestores de tenant tratam a fila de suporte dentro do seu próprio painel, sob o mesmo controlo de acesso baseado em funções que rege o resto do seu acesso. A equipa de suporte não precisa de permissões mais amplas só para responder a uma pergunta, e não existe um segundo login, uma segunda configuração de SSO nem um segundo local onde os dados pessoais dos comerciantes são armazenados.
Armazenamento partilhado em vez de um segundo sistema de ficheiros
Anexos como recibos e comprovativos utilizam o mesmo armazenamento de documentos e as mesmas rotas de download que as provas de contestação (disputes). Nada precisa de ser duplicado num segundo sistema, e nada se perde entre um anexo e o registo que deveria sustentar.
O que isto muda no dia a dia
Como os pedidos são delimitados por tenant e geridos em fila dentro da plataforma, os relatórios de tempo de resposta são uma propriedade da plataforma, em vez de algo reconstruído a posteriori a partir de dois sistemas. E como os pedidos abrem a partir do contexto, há uma categoria de erro a menos: a referência de transação errada copiada para a conversa errada.
Uma camada opcional, e o lugar das contestações
Sobre a caixa de entrada de suporte, um módulo separado pode fazer a triagem dos pedidos recebidos e redigir respostas sugeridas com base no mesmo contexto de transação e de comerciante que o operador já vê — o operador continua a editar e a enviar, e nada chega ao comerciante automaticamente. Isto funciona ao lado do próprio fluxo de contestações da plataforma, onde um comerciante pode abrir uma contestação sobre um pagamento ou payout com um motivo e até cinco ficheiros de prova, e um gestor resolve-a com os saldos repostos e novamente lançados automaticamente — mantendo a conversa de suporte e a eventual contestação resultante no mesmo lugar.
