O suporte ao produto é onde os clientes criam a impressão duradoura sobre a sua empresa. Com a Trupeer, pode poupar horas na documentação de suporte começando com um modelo gratuito de SOP de suporte ao produto, personalizando-o com as suas diretrizes de marca e usando o nosso criador de SOP com IA para transformar cada procedimento num vídeo explicativo claro.

Para que é usado um modelo de SOP de suporte ao produto?

Uma SOP de suporte ao produto é o procedimento escrito para lidar com um tipo recorrente de contacto do cliente sobre um produto: o que perguntar, o que verificar, como resolver, quando escalar e o que dizer ao cliente.

Um modelo dá-lhe a estrutura reutilizável. Gatilho, pré-requisitos, passos, resolução, escalonamento, redação para o cliente.

Está intimamente relacionado com uma SOP de atendimento ao cliente e não é o mesmo documento, por uma razão que molda tudo nesta página. No suporte ao produto existe um produto, e o produto pode estar errado. Um procedimento de atendimento ao cliente lida com uma situação. Um procedimento de suporte ao produto lida frequentemente com uma falha, e o que faz com essa falha determina se o seu volume de contactos aumenta ou diminui nos próximos dois anos.

Quanto à estrutura geral, a nossa SOP template cobre-a, e a nossa IT SOP template cobre as operações técnicas internas. Esta página aborda o que muda quando aquilo que está a apoiar é um produto que outra pessoa consegue corrigir.

Cada procedimento de suporte tem duas saídas, não uma

Uma SOP de suporte é normalmente avaliada por uma coisa: resolve o contacto de forma rápida e consistente. É uma medida razoável e é metade do trabalho.

A outra metade é o sinal. O suporte está no único ponto da organização onde todas as falhas surgem, em volume, com evidência associada. Ninguém mais vê o padrão. A engenharia vê os bugs sobre os quais foi informada. O produto vê o roadmap. O suporte vê o que acontece realmente aos clientes, quatrocentas vezes por mês.

Por isso, cada procedimento tem duas saídas possíveis. A resolução para este cliente e o relatório para as pessoas que conseguem impedir que isso volte a acontecer.

Quase nenhuma SOP de suporte tem a segunda. Os passos terminam em “confirmar que o cliente está satisfeito e fechar o ticket”. Não existe um campo a dizer o que deve ser levantado, para quem, com que evidência, nem em que ponto uma resolução recorrente deve deixar de ser uma resolução e passar a ser um defeito.

Ao adicionar essa saída a cada procedimento, a função da biblioteca muda. Sem ela, o suporte torna-se um absorvedor muito eficiente de falhas, e a eficiência em absorver falhas é indistinguível de não as ter, até alguém olhar para o volume.

Como personalizar este modelo na Trupeer

Passo 1: Abrir a secção de Templates

Vá à secção Templates no menu principal.

Passo 2: Selecionar e abrir um template

Clique em qualquer template com que queira trabalhar para o abrir.

Passo 3: Expandir a visualização do template

Se necessário, expanda a visualização do template para ver o layout completo e os detalhes de forma clara.

Passo 4: Editar o template

Clique em Edit para começar a modificar o template selecionado.

No editor, pode:

• Adicionar novas secções

• Definir ou atualizar regras de formatação

• Adicionar um logótipo e ajustar a sua posição e definições relacionadas

Passo 5: Guardar o seu template personalizado

Depois de fazer todas as alterações necessárias, clique em Save para guardar o template atualizado como seu.

Passo 6: Pré-visualizar e afinar o template

Quando quiser ver como fica o seu template personalizado, abra a opção Preview.

No ecrã de pré-visualização, pode continuar a fazer ajustes diretamente, se necessário, garantindo que o template aparece exatamente como o quer.

Com um modelo de SOP de suporte ao produto pode:

• Poupar horas na escrita: Ignore a página em branco com uma estrutura criada para procedimentos de suporte.

• Uniformizar a qualidade do suporte: Cada agente lida com problemas comuns da mesma forma.

• Manter-se alinhado com a marca: Aplique o seu logótipo, tom e cores usando o kit de marca da Trupeer.

• Reduzir o tempo de resolução: Procedimentos claros ajudam os agentes a resolver problemas mais rapidamente.

• Onboarding de agentes mais rápido: Combine SOPs com vídeos explicativos para acelerar a integração de novos colaboradores.

• Aceder a equipas globais: Traduza SOPs de suporte para 65+ idiomas com um único clique.

A sua biblioteca de workaround é uma lista de bugs sem contagem

Aqui está a versão desse argumento sobre a qual pode agir esta semana.

Percorra os seus procedimentos de suporte e procure as frases que indicam um workaround. Como medida temporária. É um problema conhecido. Diga ao cliente para. Faça com que ele reinicie e tente novamente. Se não funcionar, tente.

Cada um desses casos é um defeito de produto com o qual alguém decidiu conviver. Não deliberadamente, na maioria dos casos. Alguém escreveu um bom procedimento para ajudar os colegas a lidar com um problema, o procedimento funcionou, os contactos foram tratados de forma eficiente e a falha deixou de gerar qualquer pressão para a corrigir.

Conte-os e terá uma lista de bugs que não existe em mais lado nenhum na organização. Faça a correspondência de cada um com o volume de contactos e o tempo de atendimento e terá essa lista classificada por custo, algo que a maioria das equipas de produto não tem para a sua lista real de pendências.

A perceção desconfortável é que escrever uma SOP de workaround muito boa atrasa ativamente a correção. Quanto melhor o procedimento, menos ruído a falha faz e mais tempo sobrevive.

Como encontrar os workarounds já nas suas SOPs

Um trabalho de uma tarde e não requer a cooperação de ninguém.

Procure na biblioteca de procedimentos as frases acima. Na maioria das bibliotecas, isto encontra entre quinze e trinta por cento dos procedimentos.

Para cada ocorrência, registe: qual é o procedimento, qual é a falha subjacente, quantos contactos gerou nos últimos doze meses, o tempo médio de atendimento e se alguma vez foi levantado como defeito.

A última coluna é a que surpreende as pessoas. Uma grande parte dos workarounds documentados nunca foi formalmente reportada, porque a pessoa que escreveu o procedimento resolveu o problema do modo que tinha disponível, que foi escrever um procedimento.

Multiplique contactos pelo tempo de atendimento para obter horas e multiplique as horas pelo seu custo total para obter um número. Ordene por ordem decrescente. Os cinco primeiros normalmente representam a maior parte do total e são os seus casos para o registo descrito abaixo.

Não apresente isto como uma falha da equipa de suporte. Eles fizeram o que estava ao alcance deles e fizeram-no bem.

O gatilho de recorrência que transforma uma correção num defeito

O mecanismo que impede esta recorrência é um limite escrito no próprio procedimento.

Os números devem ser definidos com base nos seus volumes. O que importa é que exista um limite e que, ao ultrapassá-lo, seja gerada uma ação que ninguém tenha de ter coragem de iniciar.

A última linha é a que muda o comportamento. Aceitar um workaround permanente é uma decisão legítima e deve ser feita explicitamente, por alguém com autoridade para o fazer, e registada. O que não é legítimo é essa decisão ser tomada por omissão, sem que ninguém a levante.

Modelo gratuito de SOP de suporte ao produto: a estrutura para copiar

Copie daqui. Os campos marcados com um asterisco são as adições a uma SOP standard.

Cabeçalho. Número e título do procedimento, escritos como o sintoma do cliente e não como a causa interna. Responsável. Data da última verificação. Produtos e versões afetados. Tempo estimado de atendimento. Referência do problema conhecido, quando existe.

Sintoma. Como o cliente o descreve, pelas suas palavras, incluindo as variações comuns. É isto que os agentes procuram.

Não use este procedimento se. As condições em que este é o procedimento errado, com uma indicação do procedimento correto.

Perguntas de diagnóstico. O que deve ser estabelecido antes de fazer qualquer coisa, pela ordem que elimina mais casos mais rapidamente.

Passos de resolução. Numerados, uma ação por passo, com o resultado esperado. Quando um passo for um workaround para uma falha conhecida, marque-o como tal em vez de o apresentar como o comportamento pretendido.

Redação para o cliente. O que dizer, incluindo o que não prometer. Esta é a secção que impede que doze agentes deem doze versões diferentes da mesma falha, e a nossa help desk response template cobre a camada de redação com mais profundidade.

Escalonamento. Para quem, em que ponto e com que informação anexada.

Rota do defeito. O que deve ser levantado com o produto ou a engenharia, em que formato e com a evidência necessária. Inclua o limite de recorrência que torna isto obrigatório em vez de opcional.

Verificação. Como confirmar que está efetivamente resolvido para o cliente, incluindo qualquer coisa que só se torna visível após um atraso.

Copie até aqui. Os dois campos que mais importam são a referência do problema conhecido e a rota do defeito, e são os dois que nenhum modelo geral de SOP lhe vai dar.

A empresa de áudio com trinta e um defeitos escondidos

A Vantree Audio produz colunas sem fios e auscultadores para consumidores. Cerca de noventa agentes de suporte, em dois locais, tratam aproximadamente catorze mil contactos por mês.

Por medidas convencionais, a função de suporte estava em bom estado. Cento e quarenta procedimentos documentados, bem mantidos, tempos de resolução dentro do objetivo, satisfação do cliente de quatro vírgula dois em cinco.

O número que não encaixava era o de contactos por unidade vendida, que tinha aumentado durante três anos consecutivos.

Alguém procurou na biblioteca de procedimentos linguagem de workaround. Trinta e um dos cento e quarenta procedimentos continham um workaround documentado para uma falha conhecida do produto.

Ao cruzar com o volume de tickets, esses trinta e um procedimentos representavam trinta e oito por cento de todos os contactos.

O maior, isoladamente, era uma falha de emparelhamento Bluetooth num modelo, em que o workaround era uma sequência de reinício em seis passos. Dois mil e novecentos contactos ao longo de doze meses, com um tempo médio de atendimento de onze minutos, o que equivale a cerca de quinhentas e trinta horas de agente numa única falha.

Esse procedimento tinha sido escrito no terceiro mês após o modelo ter sido lançado, por um agente sénior, para ajudar os colegas. Ainda estava na biblioteca vinte e seis meses depois. A engenharia nunca tinha sido informada, porque o procedimento funcionava. Os contactos eram tratados de forma eficiente e consistente, por isso a falha não gerava pressão em lado nenhum.

Dos trinta e um workarounds, dezanove nunca tinham sido levantados como defeito. Oito tinham sido levantados uma vez e nunca foram acompanhados. Quatro eram conhecidos pela engenharia e tinham sido adiados deliberadamente.

Em todos os trinta e um, o custo anual chegou a cerca de cinco mil e trezentas horas de agente, algures perto de cento e seis mil libras apenas no atendimento, antes de contar devoluções ou o impacto na satisfação.

Seguiram-se três mudanças. Cada procedimento ganhou uma rota do defeito. Foi escrito um gatilho de recorrência, para que qualquer procedimento que contivesse um workaround e fosse acionado mais de cinquenta vezes num trimestre gerasse automaticamente uma revisão de defeito. E foi criado um registo de workaround, revisto mensalmente com o produto e a engenharia, classificado por contactos multiplicados pelo tempo de atendimento.

A regra associada ao registo era a importante: um workaround pode existir durante dois trimestres, após os quais precisa ou de uma data de correção ou de uma decisão registada para o aceitar permanentemente.

Doze meses depois, onze dos trinta e um tinham sido corrigidos no produto ou no firmware. Os contactos nesses onze caíram cerca de setenta e quatro por cento. Os contactos por unidade vendida em toda a gama caíram dezanove por cento. O registo ficou com catorze workarounds em aberto, nove dos quais com datas de correção.

A falha de Bluetooth foi corrigida numa versão de firmware quatro meses depois de o registo ter começado, tendo sobrevivido vinte e seis meses a ser tratada bem.

Quais as SOPs de suporte ao produto a escrever primeiro

Não as complicadas. Escreva os procedimentos em que o volume é alto ou em que os agentes atualmente improvisam, porque são as duas áreas em que a consistência compensa.

Classifique as razões dos contactos por volume e escreva as dez principais. Na maioria das operações de suporte, as dez principais representam bem mais de metade de todos os contactos e, normalmente, não são “glamourosas”: configuração e primeira utilização, conectividade, conta e login, consultas de faturação, devoluções e garantia, atualizações de firmware ou software, questões de compatibilidade e as duas ou três falhas específicas dos seus produtos atuais.

Depois, adicione as que custam caro quando se faz mal, em vez de serem frequentes. Contactos relacionados com segurança, qualquer coisa que envolva uma recolha ou uma obrigação regulamentar, pedidos de dados ou de privacidade, e qualquer contacto em que a resposta errada crie um compromisso legal.

Para as referências curtas de que os agentes precisam no momento de uma chamada, em vez de um procedimento completo, um job aid costuma funcionar melhor do que alongar a SOP.

Dez a quinze procedimentos que cubram a sua lista de volume, mais os casos de alta consequência, é uma biblioteca funcional. Tentar fazer cento e quarenta a partir do zero é como estes projetos ficam bloqueados.

Como escrever uma SOP de suporte, passo a passo

Comece por contactos reais, em vez de começar pela documentação do produto. Leia os últimos vinte tickets sobre o tema e use as próprias palavras do cliente para o sintoma, porque é isso que os agentes vão procurar.

Escreva as perguntas de diagnóstico pela ordem que elimina mais casos mais rapidamente. A maioria dos procedimentos faz essas perguntas pela ordem em que o produto é construído, em vez da ordem que resolve mais depressa.

Escreva os passos a partir de ver alguém resolver um caso em direto, e não a partir de como deveria funcionar.

Marque cada workaround como workaround. Este hábito único é o que torna a auditoria acima possível mais tarde.

Escreva a redação para o cliente, incluindo o que não dizer, e obtenha aprovação de quem é responsável pela comunicação externa do produto.

Defina a rota do defeito e o limite de recorrência antes de publicar, em vez de o fazer como acompanhamento.

Depois, peça a alguém que não tenha tratado este tipo de contacto para resolver um caso real a partir do procedimento, enquanto você observa e não diz nada.

Escalonamento, severidade e quando parar a resolução de problemas

O outro campo que as SOPs de suporte normalmente não têm é uma regra de paragem.

Os agentes continuam a resolver problemas porque parar parece desistir e porque escalar tem um custo social na maioria das equipas de suporte. Assim, um contacto que deveria ter sido escalado após doze minutos recebe quarenta e o cliente experiencia tanto o atraso como a transferência final.

Escreva a regra de paragem no procedimento. Após um número definido de passos de diagnóstico, ou um tempo decorrido definido, ou com base numa descoberta específica, o procedimento termina e começa o escalonamento. Transforme-o numa instrução, em vez de um julgamento.

Associe-a a definições de severidade que sejam observáveis, e não descritivas. Não “alto impacto”, mas algo como: o cliente não consegue usar a função principal, ou é reportada uma preocupação de segurança, ou mais do que um cliente reportou hoje o mesmo sintoma.

E defina o que é enviado junto com o escalonamento. Um escalonamento sem histórico de diagnóstico anexado é devolvido, o que custa ao cliente mais um ciclo. A nossa ticket and resolution template cobre os campos que precisam de ser capturados para essa transferência funcionar.

SOP de suporte ao produto ou SOP de atendimento ao cliente?

Existem as duas, sobrepõem-se e a distinção vale a pena manter porque falham de formas diferentes.

Uma SOP de atendimento ao cliente trata da relação e da transação: encomendas, reclamações, reembolsos, alterações de conta, pedidos gerais. A variável é a situação do cliente e uma boa SOP produz um resultado consistente e justo.

Uma SOP de suporte ao produto trata um problema técnico com um produto. A variável é o comportamento do produto e uma boa SOP produz uma resolução e, quando o produto está na origem, um sinal.

A maioria das organizações de suporte precisa das duas e os procedimentos devem viver numa única biblioteca com um marcador claro para o tipo de cada uma, porque os agentes não vivenciam a distinção e não devem ter de a fazer.

Se a sua equipa não lida com falhas técnicas, a estrutura de atendimento ao cliente é a que pretende. Se a sua equipa documenta workarounds regularmente, esta página é a mais relevante e a auditoria de workarounds vale a pena ser feita esta semana.

Posso obter um modelo de SOP de suporte ao produto em Word ou Excel?

Word ou Google Docs para o próprio procedimento. É texto corrido com passos numerados e redação para o cliente, e é lido em vez de ser organizado.

Excel para duas coisas que importam mais do que o procedimento individual. O registo do procedimento, com a lista de cada SOP com responsável, data da última verificação, volume de contactos, tempo médio de atendimento e se contém um workaround. E o registo de workarounds, com a falha, os contactos, as horas, se um defeito foi levantado e a data de correção ou a decisão aceite.

Essa segunda folha é o artefacto que esta página inteira existe para produzir. Leva uma tarde a construir e é normalmente a primeira vez que alguém na empresa vê o custo das falhas não corrigidas num só lugar.

PDF para qualquer coisa partilhada fora da equipa de suporte, como um procedimento anexado a um acordo com parceiros ou apresentado durante uma auditoria.

Como manter os procedimentos de suporte atuais à medida que o produto é lançado

Os procedimentos de suporte ao produto ficam desatualizados mais depressa do que qualquer outro tipo, porque aquilo que descrevem muda no calendário de lançamentos de outra pessoa. Uma atualização de firmware altera um menu, um lançamento de software remove uma definição e quarenta procedimentos ficam subtilmente errados numa semana em que ninguém do suporte foi informado.

A consequência prática é que manter a biblioteca compete com o atendimento de contactos e, no atendimento de contactos, ganha sempre.

A Trupeer AI remove grande parte do custo. Um agente resolve o contacto uma vez com uma gravação em execução e o resultado é um procedimento escrito com os passos e os ecrãs já capturados, pronto para verificar em vez de compor. Atualizar quarenta procedimentos após um lançamento passa a ser um dia em vez de um projeto que ninguém começa.

Registe. Marque com a marca. Traduza. Trupeer.

A mesma gravação produz a versão para o cliente, que é normalmente necessária no mesmo momento e raramente é escrita, e os nossos modelos de artigos da base de conhecimento cobrem essa estrutura. O criador de SOP cobre os procedimentos internos e ambos vivem na sua base de conhecimento com uma marca consistente. As instruções de configuração estão no document template setup guide.

Perguntas Frequentes

Existe um modelo gratuito de SOP de suporte ao produto em Word?

A estrutura acima é colada diretamente no Word ou no Google Docs, incluindo os campos de referência do problema conhecido e da rota do defeito que os modelos gerais de SOP omitem. Não há download bloqueado e não há formulário. O campo que vale a pena adicionar primeiro a qualquer coisa que já use é um marcador em cada passo que seja um workaround.

Existe um modelo gratuito de SOP de suporte ao produto em Excel?

O Excel serve para os dois registos, em vez do procedimento. O registo do procedimento com volume e tempo de atendimento e o registo de workarounds com a falha, o seu custo e a data de correção. Construir o segundo é a tarde com maior retorno disponível para a maioria das funções de suporte.

Existe um modelo gratuito de SOP de suporte ao produto em PDF?

Exporte procedimentos para PDF para qualquer coisa partilhada fora da equipa e mantenha as versões de trabalho editáveis. Os procedimentos de suporte mudam com cada lançamento de produto, por isso uma biblioteca congelada fica errada mais depressa do que a maioria.

Onde posso encontrar um modelo geral de SOP em Word ou PDF?

Se quiser a estrutura standard sem os campos de suporte ao produto, a nossa SOP template cobre-a e a IT SOP template cobre as operações técnicas internas, incluindo como decidir quais os procedimentos que vale a pena escrever.

Quantas SOPs de suporte ao produto é que uma equipa precisa?

Dez a quinze que cubram as suas principais razões de contacto por volume, mais os casos de alta consequência independentemente do volume. Para além de cerca de quarenta, a manutenção torna-se a restrição determinante e uma biblioteca mais pequena que esteja genuinamente atualizada supera uma grande que os agentes aprenderam a não confiar.

Quem deve escrever SOPs de suporte ao produto?

Agentes experientes, editados por quem é responsável pela biblioteca, com o produto ou a engenharia a validar tudo o que descreva uma falha conhecida. Essa última revisão é o que transforma um workaround num defeito visível em vez de uma correção local, que é o argumento completo desta página.

Com que frequência devem ser revistas as SOPs de suporte?

Em lançamentos de produto, em vez de num calendário. Cada lançamento de firmware ou software deve desencadear uma verificação dos procedimentos que tocam no que mudou. Adicione uma revisão contínua das vinte principais por volume a cada trimestre e volte a verificar tudo o que tenha gerado um escalonamento.

SOP de suporte ou artigo da base de conhecimento: o que muda?

A SOP é interna e diz a um agente como lidar com o contacto, incluindo o que deve escalar e o que não deve prometer. O artigo é para o cliente e diz ao cliente como resolver o problema por si. Normalmente vêm da mesma investigação e devem ser escritos em conjunto, porque um bom artigo elimina o contacto por completo.