Markin + Salesforce Service Cloud integration
Decisões de retenção e expansão na visualização do caso.
O que é um Salesforce Service Cloud Agente de IA?
Uma configuração Markin e Salesforce Service Cloud dá ao agente uma ação recomendada com a sua razão no momento do contacto, e lê o histórico de casos como sinal de churn e friction.
Os agentes recebem scripts, não decisões. Dar-lhes uma ação classificada com a razão anexada é mais fácil de seguir e, ao contrário de um script, mensurável em relação a um grupo de controlo.
O que a Markin lê
- Histórico de casos e resultados de resolução
- Dados de conta e elegibilidade
O que a Markin escreve de volta
- Uma única ação recomendada por caso, com razão e valor esperado.
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 Salesforce Service Cloud?
- Como mostro uma next best action aos agentes de serviço?
- Podem os casos do Service Cloud alimentar um modelo de churn?
- Como decido quando oferecer um desconto de retenção numa chamada?
- Como meço adequadamente as ofertas de retenção do agente?
O que Markin faz em Salesforce Service Cloud
- 01Ler casos, resoluções e histórico de escalamento.
- 02Ler estado de direito e contrato.
- 03Avalie o risco de churn e a receita em risco por conta.
- 04Sirva uma ação recomendada na consola do agente.
- 05Limitar a autoridade de desconto pelo valor esperado.
- 06Registe a escolha do agente contra a recomendação.
- 07Mantenha um controlo randomizado entre contas elegíveis.
- 08Reporte a receita poupada por ação e por equipa.
Âmbito do trabalho
O trabalho de growth por trás Salesforce Service Cloud
A lista acima é o que Markin toca em Salesforce Service Cloud. 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.
- Mapeie cada cliente, conta, subscrição e plano nos sistemas que você já executa.
- Reconstrua a baseline de receita a partir de pedidos, pagamentos, reembolsos e créditos.
Encontre onde a receita está a vazar
Normalmente uma análise aprofundada trimestral feita por um analista.
- Dimensionar cada descoberta em receita, não em pontos percentuais.
- Observe o ARPU por coorte, plano, mercado, canal e tempo de serviço para desvios que eliminem o ruído.
Explique porquê
Normalmente, uma investigação de duas semanas retirada do roadmap.
- Mostre a contraprova, não apenas o corte de apoio.
- Mantenha o rasto da query para que um analista possa reproduzir cada número.
Escreva hipóteses que valem a pena financiar
Normalmente, um workshop, limitado às ideias presentes na sala.
- Mantenha o portfólio completo visível, incluindo o que não foi deliberadamente financiado.
- Escreva hipóteses continuamente em marketing, produto, preços e saúde técnica.
Decidir por cliente
Normalmente, as regras de segmentação são atualizadas quando alguém tem tempo.
- Escolha o canal, o tempo e o nível de incentivo, não apenas a mensagem.
- Limitar o desconto e a exposição da margem ao nível acordado pelas finanças.
Execute nas ferramentas que você já usa
Normalmente um ticket, depois um lugar no calendário do próximo mês.
- Encaminhe ofertas, jogadas de retenção e fluxos de save para a superfície certa.
- Abra o trabalho como um rascunho para aprovação onde um ser humano deve assinar.
Comprovar que causou a receita
Normalmente discutido, raramente medido.
- Reporte a retenção, ARPU, margem e pressão de contacto lado a lado.
- Detete e desconte a canibalização entre ações concorrentes.
Retire, governe e transfira
Normalmente não é trabalho de ninguém, então nada é alguma vez desativado.
- Mantenha os dados pessoais nos seus sistemas e atue sobre eles no local.
- Mostre todo o rasto de decisões quando o departamento jurídico, financeiro ou um auditor o solicitar.
As equipas usam Salesforce Service Cloud juntamente com
Salesforce Service Cloud questions
- How does Markin connect to Salesforce Service Cloud?
- 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 Salesforce Service Cloud?
- Case history and resolution outcomes; Account and entitlement data.
- What does Markin write back into Salesforce Service Cloud?
- Uma única ação recomendada por caso, com razão e valor esperado.
- 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.