En bref
La planification de la couverture du support repose sur trois décisions : sur quelles heures et quels canaux vous répondez, combien d'agents chaque heure demande, et ce qu'il advient des tickets qui arrivent quand personne n'est connecté. La plupart des équipes partent de l'horloge (« on fait les week-ends ? »). Je partirais plutôt du canal, parce que un client en chat attend quelques secondes et un client par e-mail attend des heures, et cette seule différence décide de l'essentiel de votre planning.
Faites le calcul avant d'embaucher. Sortez la carte de chaleur des tickets par heure de votre helpdesk, multipliez le volume par le temps de traitement, puis ajoutez 15-35 % de shrinkage, la fourchette que la propre documentation de gestion des effectifs de Zendesk qualifie de norme du secteur. Un poste staffé 24h/24 et 7j/7 représente environ 6 personnes, ce qui explique que presque aucune petite équipe ne devrait staffer les nuits avec des humains.
Pour les heures que vous ne pouvez pas couvrir, un coéquipier IA de helpdesk comme eesel répond aux tickets de routine dans votre helpdesk existant et laisse les plus difficiles étiquetés pour le matin. Les humains gardent le chat en direct, le téléphone et les pannes ; l'IA prend le « où est ma commande ? » de 2 h du matin.
Qu'est-ce que la planification de la couverture du support ?
La planification de la couverture du support consiste à faire coïncider les horaires de votre équipe avec les moments où les clients ont réellement besoin de vous. Elle répond à trois questions :
- Sur quelles heures et quels jours répondons-nous, par canal ? E-mail, chat, téléphone et réseaux sociaux n'ont pas besoin des mêmes horaires.
- Combien d'agents nous faut-il à chaque heure d'ouverture ? Pas par jour, par heure, parce que le volume n'est pas constant.
- Que se passe-t-il en dehors de ces heures ? Une réponse automatique, une personne d'astreinte, un partenaire ou un agent IA.
Je fais partie de l'équipe support d'eesel, donc je vis chaque jour avec les conséquences de ce plan. Et comme eesel met de l'IA sur des files de support en direct depuis des années, j'ai vu le même schéma chez beaucoup d'équipes : le plan de couverture a été décidé une fois, au feeling, quand l'équipe comptait trois personnes, et personne ne l'a revu quand le volume a triplé.
On le confond aussi avec des sujets voisins. La planification de la couverture décide quand vous êtes ouverts. Vos politiques de SLA décident de la rapidité de réponse promise pendant ces heures. Une passation de shift correspond à ce qui se passe aux jointures. Si la couverture est mauvaise, les deux autres ne peuvent pas vous sauver.
Étape 1 : Repérer quand les clients écrivent vraiment
Partez des données, pas des suppositions. Tous les grands helpdesks ont désormais un rapport qui montre le volume de tickets par heure et par jour, et il se lit en dix minutes environ.
| Helpdesk | Rapport à ouvrir | Ce qu'il montre | Formule |
|---|---|---|---|
| Gorgias | Busiest times | Carte de chaleur heure par jour avec vos horaires d'ouverture marqués ; tickets créés, répondus, fermés | Toutes les formules helpdesk |
| Front | Rapport Workload, Busiest times | Carte de chaleur des nouvelles conversations, messages et coéquipiers actifs ; 9 h-17 h par défaut, extensible à 24 heures | Toutes les formules actuelles |
| Help Scout | Rapport All Channels | Carte de chaleur « Busiest time of day » plus la mesure Busiest Day | Non précisé dans la documentation |
| Freshdesk | Ticket volume trends (Load Analysis) | Tickets créés, résolus, rouverts et non résolus par heure | Non précisé pour ce rapport |
| Zendesk | Recette Explore, tickets par heure de la journée | Rapport personnalisé sur « Ticket created - Hour », plus une recette des heures de pointe par canal | Suite Professional et au-dessus, ou Explore Professional |
Deux choses à repérer dans la carte de chaleur. D'abord l'évidence : où se trouvent les cases foncées. Ensuite, et c'est plus utile, les cases foncées en dehors de vos horaires actuels. La documentation de Gorgias le dit mieux que moi : « A dark cell outside your business hours is demand arriving when nobody is scheduled. »
Regardez ensuite créés contre résolus par heure, car les heures où les créés l'emportent sont celles où commence un retard de tickets. Load Analysis de Freshdesk est conçu pour cela, et sa documentation dit que si les créés dépassent les résolus sur une période, « you should add more agents during this time period. »
Utilisez des mois d'historique, pas des jours (l'outil de prévision de Zendesk part de six mois de tickets), et retirez les pics connus de la base. Une marque de livraison de fleurs qui a entraîné eesel sur ses anciens tickets a demandé à eesel d'exclure ses pics de la Saint-Valentin et de la fête des Mères pour la même raison : les semaines de pointe faussent l'allure d'un mardi normal. Planifiez d'abord la base, puis les pics séparément (étape 6).
Étape 2 : Décider de la couverture par canal, pas par horloge
Voici le changement de perspective que je défendrais le plus. « Est-on ouverts le samedi ? » est la mauvaise question. La bonne : combien de temps un client de ce canal attendra-t-il avant que le retard nous coûte quelque chose ?
| Canal | Temps d'attente des clients | Ce que couverture veut dire |
|---|---|---|
| Téléphone | Quelques secondes | Une personne en ligne, ou la ligne est fermée |
| Chat en direct | Une minute ou deux | Une personne en ligne, ou le chat bascule sur « laissez un message » |
| E-mail et formulaires web | Des heures | Quelqu'un répond dans la fenêtre annoncée, qui peut commencer le lendemain matin |
| DM sur les réseaux sociaux | Des heures, mais en public | Comme l'e-mail, avec une surveillance plus étroite des plaintes |
| Pannes et problèmes de sécurité | Des minutes, quel que soit le canal | Une personne d'astreinte, même quand tout le reste est fermé |
Le moteur de prévision de Zendesk traite lui-même les canaux ainsi. Sa documentation sur les prévisions explique que le volume d'e-mails arrivant en dehors des heures staffées est réparti « over the period of First Response Time », alors que le volume voix et chat hors horaires n'est pas reporté du tout. En clair : un e-mail à 23 h est le travail de demain, un appel manqué est perdu.
Cela donne un réglage par défaut raisonnable pour la plupart des équipes :
- Les canaux en direct ne tournent que sur les heures où vous pouvez les staffer correctement. En dehors, le chat bascule sur la collecte d'e-mail. Help Scout, Front et Zendesk le permettent, et mon guide sur la messagerie hors ligne de Zendesk couvre une configuration.
- L'e-mail reçoit une promesse de réponse (« sous 4 heures ouvrées ») plutôt qu'un staff 24h/24, ce qui est le cœur du support asynchrone, et vos minuteurs de SLA suivent le même planning.
- Les pannes ont une personne d'astreinte nommée, tous les jours, avec une courte liste d'alertes.
Un commentateur de Hacker News a formulé la version côté acheteur : pour du SaaS, « I'd be fine with business hour support. SaaS failures don't directly cost me money and/or reputation. » Vos clients peuvent être différents. Un produit de paiement ou un système hospitalier ne peut pas faire ce compromis. Soyez honnête sur ce que vous êtes.
Étape 3 : Calculer combien d'agents il vous faut chaque heure
Place à l'arithmétique. La version simple est un modèle de charge de travail :
Agents à planifier = (tickets de l'heure × minutes par ticket ÷ 60) ÷ occupation ÷ (1 − shrinkage)
Les minutes par ticket correspondent à votre temps de traitement moyen. Deux des autres termes demandent une définition, et le glossaire WFM de Zendesk en donne de nettes :
- L'occupation est le temps que les agents passent à traiter du travail divisé par leur temps de travail total. Personne ne tient 100 % ; l'exemple chiffré de Zendesk la plafonne à 90 %.
- Le shrinkage couvre « lunch breaks, training sessions, scheduled meetings » ainsi que « absenteeism, holiday, vacation, sick days, lateness, and leaving early. » Zendesk situe la norme du secteur à 15-35 %.
Entrez ici vos propres chiffres. Le calculateur vous donne les agents à planifier sur votre heure de pointe et l'effectif à temps plein pour couvrir une semaine d'heures d'ouverture.
Le modèle de charge de travail est un plancher, pas la réponse, pour les canaux en direct. Les clients du chat et du téléphone font la queue, et la formule que les outils d'effectifs utilisent pour dimensionner cette file est Erlang C, qui ajoute des agents pour qu'une part donnée des contacts soit traitée dans un délai cible. Zendesk WFM calcule les effectifs requis par intervalle de 15 minutes « based on a modified version of Erlang C. »
Erlang C a une particularité connue à faible volume. Le document de bonnes pratiques de Zendesk prévient que « for low-volume workstreams, the industry-standard Erlang C formula may result in slightly higher staffing recommendations. » Son exemple chiffré montre l'ampleur : 38 e-mails par jour à 210 secondes chacun représentent environ 2,2 heures de traitement, et pourtant le modèle arrive à « 1.5 agents per day », soit 12 heures de temps staffé. Cet écart est le coût de la garantie d'une réponse rapide sur une file calme, et c'est le meilleur argument pour ne pas staffer les heures calmes avec des personnes.
Ce que coûte vraiment un poste 24h/24 et 7j/7
C'est le chiffre qui met fin à la plupart des débats « passe-t-on en 24/7 ? ».
Une semaine compte 168 heures. Le glossaire de Zendesk compte un ETP à 40 heures par semaine. Cela fait 4,2 personnes pour garder une seule chaise occupée, avant que quiconque prenne des vacances. Ajoutez 30 % de shrinkage et cela fait 6 personnes, pour un seul poste. Si vous voulez deux agents la nuit, doublez.
Un commentateur de Hacker News qui est passé par là a résumé ce que le tableur oublie généralement :
"Still need enough staff at each site to handle rotation for covering weekends and for people to go on holiday and get sick or quit for new jobs etc."
Étape 4 : Choisir un modèle de couverture pour les heures que vous ne pouvez pas staffer
Une fois vos heures de pointe et vos effectifs connus, vous choisissez comment gérer le reste. Voici les six modèles que je vois le plus, avec ce que chacun vous coûte.
| Modèle | Comment ça marche | Idéal pour | Le revers |
|---|---|---|---|
| Heures ouvrées uniquement | Un planning, une promesse de réponse claire, réponse automatique hors horaires | SaaS B2B où un retard ne coûte pas d'argent au client | Retard du lundi matin |
| Shifts décalés | Heures de début étalées (7-15, 9-17, 11-19) pour étirer une équipe sur 12 heures | Équipes de 4 personnes et plus dans une région | Couverture mince aux extrémités |
| Rotation d'astreinte | Une personne porte un téléphone ou un bipeur pour les urgences hors horaires | Pannes, comptes VIP | Use les gens vite |
| Follow-the-sun | Des équipes dans 2-3 régions couvrent chacune leur journée | Clients mondiaux, 15 agents et plus | Passations, management en double |
| Hors horaires externalisé | Un partenaire répond la nuit et le week-end (guide de l'externalisation) | Support grand public à fort volume et très téléphonique | Transfert de connaissances et qualité |
| IA en première ligne plus heures humaines | L'IA répond aux tickets de routine 24h/24 ; les humains prennent le reste quand ils sont là | Équipes avec une grande part de routine | Demande une bonne base de connaissances et des limites claires |
Quelques notes d'équipes qui l'ont vécu.
Les astreintes coûtent moins cher que les shifts et plus qu'il n'y paraît. Être d'astreinte limite votre vie même les semaines calmes :
"We were a small team so rotation was weekly and you would be on support every 4 weeks or so. I couldn't go to the gym after work without worrying about a call coming in and ruined weekends for me."
Réservez les rotations aux vraies urgences, avec une courte définition écrite de ce qui en est une et un processus d'escalade clair derrière.
Les embauches dédiées viennent avant le 24/7, et il existe un déclencheur approximatif. La règle empirique d'un fondateur : si l'équipe passe 20 heures ou plus par semaine sur le support, « hire a dedicated support person or agency, even if they're part time », puis « schedule dedicated hours for each person to be on call. » C'est la question de la structure de l'équipe de support en une phrase.
Embaucher pour la journée ne règle pas les nuits. Un autre commentateur, dont l'équipe de 10 personnes a grandi vite, a décrit avoir embauché des personnes dédiées au support et constaté malgré tout que « after hours were an issue. » Si votre trou est la nuit, davantage d'embauches de jour ne le combleront pas.
C'est là qu'interviennent le support follow-the-sun, une équipe offshore ou une première ligne IA. J'ai comparé séparément le coût des équipes offshore et celui de l'IA.
Étape 5 : Construire le planning et configurer votre helpdesk
Un plan qui ne vit que dans un tableur s'écarte de la réalité en un mois. Mettez-le dans votre helpdesk, pour que minuteurs, routage et réponses automatiques le suivent. Voici ce que chacun sait faire et où se situent les limites par formule.
| Horaires d'ouverture | Plusieurs plannings (régions, canaux) | Shifts qui changent le statut de l'agent | |
|---|---|---|---|
| Zendesk | Un planning sur Suite Growth et Professional | Enterprise (document sur les plannings) | Non natif ; nécessite le module WFM |
| Freshdesk | Growth et au-dessus | Pro ($55/agent/mois en annuel) | Enterprise ($89), Agent Shifts |
| Help Scout | Plus ($45) et au-dessus, par boîte de réception | Par boîte de réception, Plus et au-dessus | Non disponible |
| Gorgias | Basic et au-dessus, par intégration | Par intégration | Non disponible |
| Front | Professional ($65), par boîte de réception | Par boîte de réception | Enterprise ($105), Shifts |
Le piège, c'est le statut. Le document sur les statuts d'agent de Zendesk dit « operating hours won't set an agent's status », donc un planning qui indique « fermé » n'empêche pas de router vers quelqu'un qui a oublié de se mettre hors ligne. Corrigez cela d'abord, car le routage intelligent vaut ce que valent les statuts qu'il lit.
Mes guides sur les horaires d'ouverture de Zendesk et les plannings de jours fériés couvrent la configuration, et les automatisations hors horaires gèrent ce qui arrive aux tickets qui tombent en dehors.
Sur Gorgias, les répondeurs automatiques planifiés font le même travail.
Quand passer à un logiciel de gestion des effectifs
Vous n'avez pas besoin d'un outil de gestion des effectifs (WFM) pour planifier la couverture d'une équipe de six. Vous en avez besoin dès que vous planifiez quelques dizaines de personnes sur plusieurs shifts et canaux, car l'outil fait des prévisions par intervalle et construit les plannings pour vous.
- Zendesk WFM prévoit le volume « for up to a year in the future » à partir de votre historique de tickets (il faut au moins un mois de données) et affiche les effectifs requis par intervalle de 15 minutes. Le prix public est celui du Workforce Engagement Bundle, WFM plus QA, à
$50par agent et par mois en paiement annuel sur la page de tarifs de Zendesk, et les modules sont achetés pour chaque agent du compte. - Assembled affiche Workforce Management à
$25,$45et$75par mois pour ses niveaux Core, Pro et Enterprise sur sa page de tarifs, sans préciser si c'est par agent. Sa page WFM dit que les plans d'effectifs « account for AI agent capacity alongside human resources », ce qui est la bonne façon d'y penser.
Étape 6 : Prévoir les pics, les jours fériés et les absences
Votre plan de base couvre une semaine normale. Trois choses le cassent.
Les pics saisonniers. Les équipes e-commerce connaissent les leurs : Black Friday, fêtes, semaines de lancement. Une marque de compléments alimentaires venue chez eesel traite environ 7 000 tickets par mois avec une haute saison de novembre à mai, et son équipe ne parvenait pas à suivre le volume seule. Planifiez la couverture des pics comme une couche distincte : personnel temporaire, heures supplémentaires, ou un agent IA qui prend la part répétitive grâce à la déflexion de tickets. Mon guide sur le support du Black Friday déroule la marche à suivre.
Les jours fériés. Ajoutez chaque jour férié de chaque région que vous servez au planning de votre helpdesk, pour que les horloges de SLA se mettent en pause et que les réponses automatiques disent la bonne chose. Vérifiez ensuite le jour suivant chacun, qui est généralement votre pire jour du mois.
Les absences et le turnover. C'est encore du shrinkage, et c'est là que les plans échouent en silence. Deux personnes absentes en même temps dans une équipe de six réduisent votre capacité d'un tiers. Perdre un agent senior fait encore plus mal, parce que son savoir part avec lui ; une société de services informatiques est venue chez eesel précisément pour capter les connaissances de deux agents seniors sur le départ avant qu'ils partent. Écrire des réponses dans votre base de connaissances fait aussi partie de la planification de la couverture.
Où l'IA s'insère dans un plan de couverture du support
C'est là que le plan devient moins cher. Si six personnes gardent un poste occupé la nuit, la question pour la plupart des équipes n'est pas « comment staffer les nuits ? », mais « quelle part de la nuit demande vraiment une personne ? ». Pour la plupart des files, la réponse est moins que vous ne le pensez, et c'est tout l'argument en faveur du support IA hors horaires.
La forme qui marche : votre équipe couvre les heures chargées de la semaine ; un agent IA couvre tout le reste en première ligne ; une personne est d'astreinte pour les pannes ; et tout ce dont l'IA n'est pas sûre attend, étiqueté et résumé, le prochain shift staffé. L'IA remplit les cases vides, pas les chargées.
Anytime Fitness est l'exemple le plus net que je puisse citer. Avant eesel, un membre qui posait une question à 22 h attendait jusqu'au matin ; aujourd'hui les questions courantes reçoivent une réponse à toute heure dans plus de 5 000 salles. Gridwise a vu eesel résoudre 73 % de ses tickets de niveau 1 dès le premier mois, d'après son témoignage sur la page agent IA de helpdesk d'eesel.
La règle qui rend l'IA hors horaires sûre est celle que les acheteurs réclament dans presque chaque appel. Un responsable CX d'une marque de compléments sur Gorgias, qui traite environ 7 000 tickets par mois, l'a dit sans détour :
"I need an AI who is only handling the tickets that it's confident to handle and all the other ones, leave them alone."
C'est le plan de couverture en miniature : l'IA prend la nuit la part dont elle est sûre, le reste atterrit dans la file du matin avec son contexte. La même idée anime le support 24h/24 et 7j/7 avec l'IA. Si vous voulez la mécanique, mon guide sur quand l'IA doit passer la main la couvre.
Une leçon qu'eesel a apprise à ses dépens : mettez vos horaires d'ouverture et vos règles de passation dans les propres réglages de planning et de routage du helpdesk, pas seulement dans les instructions de l'IA. L'IA d'un client s'est trompée sur la logique des fuseaux horaires malgré des instructions détaillées dans le prompt. Le planning du helpdesk est la source de vérité ; l'IA doit s'y référer.
Erreurs courantes de planification de la couverture du support
- Planifier par jour, pas par heure. Une équipe « au complet » le lundi peut quand même être débordée de 9 h à 11 h. Utilisez la carte de chaleur.
- Oublier le shrinkage. Un plan à shrinkage zéro est en sous-effectif chaque semaine. Partez de 30 % si vous ne connaissez pas le vôtre.
- Mêmes horaires pour tous les canaux. Ouvrir le chat en direct sur des heures que vous ne pouvez pas staffer transforme une bonne expérience e-mail en mauvaise expérience chat. Fermez le chat avant de le sous-staffer ; j'ai comparé séparément chatbots et chat en direct.
- Staffer les heures calmes avec des personnes. Erlang C gonfle les intervalles à faible volume, et les nuits sont surtout à faible volume. C'est la couverture la plus chère que vous puissiez acheter.
- Pas de responsable des pannes. Tout plan a besoin d'une personne d'astreinte nommée pour ce qui ne peut pas attendre, même si tout le reste est fermé.
- Ne jamais revoir le plan. Relancez la carte de chaleur chaque trimestre et après tout lancement important, à côté de vos autres KPI du service client. Suivez le temps de première réponse par heure de la journée ; s'il grimpe sur une tranche, c'est votre prochain creux.
eesel pour la planification de la couverture du support
Le coéquipier IA de helpdesk d'eesel remplit les cases de votre plan de couverture trop chères à staffer. Il rejoint le helpdesk que vous utilisez déjà, que ce soit Zendesk, Freshdesk, Gorgias, Help Scout ou Front, apprend de vos anciens tickets, de votre centre d'aide et de vos macros, et répond aux tickets de routine la nuit et le week-end. Tout ce dont il n'est pas sûr reste dans la file avec un résumé pour votre prochain shift.
Vous pouvez le faire tourner sur des centaines de vos anciens tickets avant qu'il touche un ticket en direct, et voir exactement quelle part de votre volume hors horaires il aurait traitée. Et il n'ajoute pas de postes pour l'équipe de nuit : le plan Teammate démarre à $299 par mois pour 500 crédits, un ticket ou un chat comptant pour un crédit.
Si votre carte de chaleur a des cases foncées après 18 h et que vous préférez ne pas embaucher six personnes pour les remplir, essayez eesel gratuitement sur votre propre file et voyez ce qu'il aurait traité le week-end dernier.
Comment calculer le nombre d'agents de support nécessaires par heure ?