Markin + Zendesk integration
Next Best Action sur l'écran de l'agent, avec sa justification.
Qu'est-ce qu'une Zendesk Agent IA ?
Une configuration Markin et Zendesk lit les tickets, les raisons et la satisfaction comme signal précoce de churn, et réécrit la valeur attendue de chaque client afin que la file d'attente puisse être priorisée par les revenus à risque plutôt que par l'âge du ticket seulement.
Un contact de service est le moment où un client t'accorde le plus d'attention tout au long de l'année. Décider quoi en faire mérite la même rigueur qu'une campagne, et c'est mesurable par agent.
Ce que Markin lit
- Volume de tickets, codes de motif et CSAT
- Historique des contacts par client
Ce que Markin renvoie
- Une action suggérée par contact, affichée dans la vue de l'agent avec sa raison
Comment la connexion fonctionne
| Pattern | Ce que cela signifie ici |
|---|---|
| API de Décision | La surface demande à Markin une décision au moment du rendu et reçoit une action plus sa raison, avec un mécanisme de secours défini. |
| Lecture seule | Markin lit le signal de ce système. Rien n'est réécrit et aucun schéma n'est modifié. |
Que peux-tu demander à Markin de faire dans Zendesk?
- Comment prioriser les tickets de support par valeur client ?
- Les tickets de support peuvent-ils prédire le churn ?
- Comment donner aux agents une next best action lors d'un appel d'annulation ?
- Comment mesurer l'impact sur les revenus du support ?
Ce que Markin fait en Zendesk
- 01Lis les tickets, les raisons, les tags et les temps de résolution.
- 02Lis les scores de satisfaction et les taux de réouverture.
- 03Détecter les schémas de tickets qui précèdent l'annulation.
- 04Évalue les revenus à risque par ticket ouvert.
- 05Écris le score et l'action suggérée sur le ticket.
- 06Sers une next best action orientée agent avec sa raison.
- 07Maintiens un holdout randomisé afin que l'offre de sauvegarde puisse être mesurée.
- 08Rapporte les revenus retenus attribuables aux actions de support.
Étendue des travaux
Le travail de growth derrière Zendesk
La liste ci-dessus est ce que Markin couvre en Zendesk. Un connecteur n'est que la surface. En dessous se trouve le travail lui-même : ce qu'un analyste, un lifecycle manager, un data scientist et un responsable de l'expérimentation feraient entre eux, fonctionnant en continu sur tes propres données.
Lis le patrimoine
Normalement un ingénieur de données, une fois, puis jamais actualisé.
- Réconcilier le même client à travers les identités de facturation, de CRM, de produit et de support.
- Lis l'état du consentement, de l'abonnement et de l'éligibilité aux canaux avant toute autre chose.
Trouve où les revenus s'échappent
Normalement une analyse approfondie trimestrielle par un analyste.
- Détecter le churn involontaire dû aux paiements échoués, à l'expiration de la carte et au comportement de nouvelle tentative.
- Repère les étapes d'onboarding où l'activation chute et les revenus ne démarrent jamais.
Explique pourquoi
Normalement une investigation de deux semaines retirée de la roadmap.
- Sépare les effets de mix des changements de comportement réels.
- Classe les facteurs par leur contribution au mouvement.
Écris des hypothèses qui méritent d'être financées
Normalement un atelier, limité aux idées présentes dans la pièce.
- Joins les preuves et l'hypothèse dont chacune dépend.
- Classe le portefeuille par valeur attendue, et non par ancienneté.
Décider par client
Normalement les règles de segmentation sont rafraîchies quand quelqu'un a le temps.
- Supprime une action plutôt que d'en envoyer une faible, et enregistre la raison.
- Choisis la next best action pour chaque client, à chaque instant.
Exécute dans les outils que tu utilises déjà
Normalement un ticket, puis un créneau dans le calendrier du mois suivant.
- Annule proprement un lot de décision quand quelque chose semble erroné.
- Laisse le patrimoine exactement tel qu'il était si Markin cesse d'écrire.
Prouver que cela a généré du chiffre d'affaires
Normalement discuté, rarement mesuré.
- Refuse de considérer comme un résultat ce qui n'a pas atteint le standard de preuve.
- Publie le rapport au même endroit pour chaque expérimentation.
Retire, gouverne et transfère.
Normalement le travail de personne, donc rien n'est jamais désactivé.
- Retire automatiquement les programmes lorsqu'ils ne battent plus le contrôle.
- Re-tester les hypothèses qui se dégradent, telles que la sensibilité aux prix et la saisonnalité.
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?
- Une action suggérée par contact, affichée dans la vue de l'agent avec sa raison
- Devons-nous déplacer nos données vers Markin ?
- Non. Markin lit depuis ton entrepôt de données, tes événements produits et tes systèmes opérationnels en place, sur tes ressources de calcul, sous les règles d'accès que ton équipe de données a déjà définies. Rien n'est copié dans une base clients séparée et il n'y a pas de magasin de profils côté fournisseur à migrer ultérieurement.
- Markin remplace-t-il notre plateforme d'engagement ou notre CDP ?
- Non, et cela ne devrait pas l'être. Ta plateforme d'engagement conserve le canal, les modèles, la délivrabilité et la gouvernance. Ton CDP conserve l'identité et le consentement. Markin ajoute la couche qu'aucune n'a : décider quelle action mérite d'exister pour chaque client, et le prouver contre un holdout.
- Et si le système que nous utilisons n'est pas répertorié ?
- Les quatre modèles d'activation couvrent presque tout : l'écriture d'attributs, l'événement déclenché, l'API de décision et le rendu de surface direct. Tout système qui expose une API, accepte un tableau, ou peut lire une colonne d'entrepôt peut recevoir des décisions. Les nouveaux connecteurs sont construits pendant le déploiement, généralement en quelques jours.