Markin + Zendesk integration
Next Best Action no ecrã do agente, com a sua razão.
O que é um Zendesk Agente de IA?
Uma configuração Markin e Zendesk lê tickets, razões e satisfação como sinal precoce de churn, e grava de volta o expected value de cada cliente para que a fila possa ser priorizada por receita em risco, em vez de apenas pela idade do ticket.
Um contacto de serviço é o momento de maior atenção que um cliente lhe dá durante todo o ano. Decidir o que fazer com ele merece o mesmo rigor de uma campanha, e é mensurável por agente.
O que a Markin lê
- Volume de tickets, códigos de motivo e CSAT
- Histórico de contacto por cliente
O que a Markin escreve de volta
- Uma ação sugerida por contacto, mostrada na vista do agente com o seu motivo
Como a conexão funciona
| Padrão | O que significa aqui |
|---|---|
| Decision API | A superfície pede a Markin uma decisão no momento da renderização e recebe uma ação mais o seu motivo, com um fallback definido. |
| Somente leitura | A Markin lê o sinal deste sistema. Nada é reescrito e nenhum esquema é alterado. |
O que você pode pedir para Markin fazer em Zendesk?
- Como priorizo os tickets de suporte por valor do cliente?
- Podem os tickets de suporte prever churn?
- Como dou aos agentes uma next best action durante uma chamada de cancelamento?
- Como meço o impacto na receita do suporte?
O que Markin faz em Zendesk
- 01Ler tickets, motivos, tags e tempos de resolução.
- 02Ler pontuações de satisfação e taxas de reabertura.
- 03Detete padrões de tickets que precedem o cancelamento.
- 04Avalie a receita em risco por ticket aberto.
- 05Escreva a pontuação e a ação sugerida no ticket.
- 06Sirva uma next best action orientada para o agente com a sua razão.
- 07Mantenha um holdout aleatório para que a oferta de save possa ser medida.
- 08Reporte a receita retida atribuível às ações de suporte.
Âmbito do trabalho
O trabalho de growth por trás Zendesk
A lista acima é o que Markin toca em Zendesk. Um conector é apenas a superfície. Abaixo está o trabalho em si: o que um analista, um lifecycle manager, um data scientist e um experimentation lead fariam entre si, correndo continuamente contra os seus próprios dados.
Ler o património
Normalmente um engenheiro de dados, uma vez, depois nunca mais atualizado.
- Confronte o mesmo cliente através de identidades de faturação, CRM, produto e suporte.
- Ler estado de consentimento, subscrição e elegibilidade do canal antes de mais nada.
Encontre onde a receita está a vazar
Normalmente uma análise aprofundada trimestral feita por um analista.
- Detete churn involuntário de pagamentos falhados, expiração de cartão e comportamento de nova tentativa.
- Identifique passos do onboarding onde a ativação diminui e a receita nunca começa.
Explique porquê
Normalmente, uma investigação de duas semanas retirada do roadmap.
- Separe os efeitos de mix da mudança real de comportamento.
- Classifique os drivers por quanto movimento cada um explica.
Escreva hipóteses que valem a pena financiar
Normalmente, um workshop, limitado às ideias presentes na sala.
- Anexe a evidência e a suposição de que cada uma depende.
- Classifique o portfólio por valor esperado, não por antiguidade.
Decidir por cliente
Normalmente, as regras de segmentação são atualizadas quando alguém tem tempo.
- Suprima uma ação em vez de enviar uma fraca e registe o porquê.
- Escolher a next best action para cada cliente, a cada momento.
Execute nas ferramentas que você já usa
Normalmente um ticket, depois um lugar no calendário do próximo mês.
- Reverta um lote de decisão de forma limpa quando algo parecer errado.
- Deixe o ambiente exatamente como estava se a Markin parar de escrever.
Comprovar que causou a receita
Normalmente discutido, raramente medido.
- Recusar-se a chamar de resultado algo que não atingiu o padrão de evidência.
- Publique a leitura no mesmo local para cada experimento.
Retire, governe e transfira
Normalmente não é trabalho de ninguém, então nada é alguma vez desativado.
- Retire programas automaticamente quando deixam de superar o controle.
- Volte a testar pressupostos que decaem, como a sensibilidade ao preço e a sazonalidade.
Zendesk questions
- How does Markin connect to Zendesk?
- Decision API, Read only. The surface asks Markin for a decision at render time and receives one action plus its reason, with a defined fallback.
- What does Markin read from Zendesk?
- Ticket volume, reason codes and CSAT; Contact history per customer.
- What does Markin write back into Zendesk?
- Uma ação sugerida por contacto, mostrada na vista do agente com o seu motivo
- Temos de mover os nossos dados para Markin?
- Não. Markin lê do seu warehouse, eventos de produto e sistemas operacionais em uso, no seu ambiente de computação, sob as regras de acesso que a sua equipa de dados já estabeleceu. Nada é copiado para uma base de clientes separada e não existe um store de perfis por parte do fornecedor para migrar mais tarde.
- Markin substitui a nossa plataforma de engagement ou CDP?
- Não, e não deveria. A sua engagement platform mantém o canal, os templates, a deliverability e a governance. O seu CDP mantém a identidade e o consentimento. A Markin adiciona a camada que nenhuma delas tem: decidir qual ação merece existir para cada cliente e prová-la contra um holdout.
- E se o sistema que usamos não estiver listado?
- Os quatro padrões de ativação cobrem quase tudo: gravação de atributos, evento acionado, API de decisão e renderização direta da superfície. Qualquer sistema que exponha uma API, aceite uma tabela ou possa ler uma coluna de warehouse pode receber decisões. Novos conectores são construídos durante a implementação, geralmente em dias.