Gestão de Escalonamento

Os escalonamentos se enquadram em quatro categorias distintas que exigem respostas diferentes. Escalonamentos técnicos: bugs complexos ou problemas de integridade de dados que o suporte de Nível 2 não consegue resolver e que exigem investigação e correção de engenharia. Responsável pela resolução: Engenharia. Resposta: Relatório formal de bug com SLA, atualizações regulares de status para o CSM da conta. Escalonamentos de negócios: cliente ameaçando churn, expressando grave insatisfação ou solicitando explicitamente o envolvimento executivo. Responsável pela resolução: VP de CS ou VP de Conta. Resposta: Contato executivo em 24 horas, plano de resgate da conta. Escalonamentos de relacionamento: saída de um 'champion', reestruturação importante da conta ou um stakeholder chave expressando insatisfação pública (mídias sociais, sites de avaliação). Responsável pela resolução: Liderança de CS e Jurídico (se público). Resposta: contato proativo antes que a situação se agrave, plano de reconstrução do relacionamento. Escalonamentos de processo: problemas sistêmicos onde o mesmo tipo de problema afeta várias contas repetidamente, exigindo mudança de processo em vez de resolução individual. Responsável pela resolução: Product Ops ou Support Ops. Resposta: análise da causa raiz, redesenho do processo e comunicação às contas afetadas.

O design do protocolo de escalonamento deve equilibrar dois riscos concorrentes: sub-escalonamento (problemas que merecem atenção sênior nunca a alcançam, e a organização é pega de surpresa por um churn público ou post em site de avaliação) e super-escalonamento (todo e-mail de cliente insatisfeito aciona respostas executivas, criando fadiga de alerta e carga de trabalho executiva insustentável). A solução são limites de escalonamento em camadas baseados em critérios objetivos. Escalonar automaticamente imediatamente (sem necessidade de julgamento do CSM): qualquer contato do cliente com um executivo, qualquer ameaça de postar publicamente avaliações negativas, qualquer menção de rescisão pelo nome em um ticket de suporte, qualquer relatório de vulnerabilidade de segurança, qualquer evento de violação de dados. Escalonar em 24 horas com julgamento do CSM: uma conta empresarial (>$25k ACV) com uma queda na pontuação de saúde abaixo de 30 em uma única semana, uma mudança de stakeholder observada pelo CSM indicando perda de tomador de decisão, ou um terceiro QBR consecutivo perdido pelo cliente. Não escalonar: tickets de suporte padrão de clientes empresariais (lidar através da fila de prioridade normal), expressões individuais de frustração do usuário sobre um recurso específico (registrar no sistema VoC).

A confiança do cliente durante um escalonamento é protegida por dois princípios: velocidade e previsibilidade da comunicação. Clientes em uma situação difícil ficam mais ansiosos quando estão incertos sobre o que acontecerá a seguir. O prazo de resolução não precisa ser curto — ele precisa ser claramente comunicado e cumprido de forma confiável. Imediatamente após receber um escalonamento: reconhecer em 2 horas com uma pessoa nomeada assumindo a responsabilidade (não um genérico "estamos investigando isso" — a mensagem deve nomear a pessoa: "Sou Sarah, VP de Sucesso do Cliente. Assumi pessoalmente a responsabilidade pela sua conta e estou trabalhando com nosso líder de Engenharia nisso."). Fornecer um horário específico para a próxima comunicação (não "nós o atualizaremos em breve" — "Enviarei uma atualização de status até as 15h de hoje, tenhamos ou não uma resolução até lá"). Se o prazo das 15h se aproximar sem resolução, envie uma atualização às 15h de qualquer forma: "Aqui é onde estamos e aqui está a meta revisada." Essa previsibilidade — mesmo em situações difíceis — é o que transforma um escalonamento de um evento que destrói a confiança em um que a constrói.