Aller au contenu
SuperScheduler

Interventions terrain

Répartir les techniciens terrain depuis un tableau partagé

Un dispatcheur attribue des interventions à des personnes déjà sur la route, avec des créneaux d’arrivée promis, des compétences requises et une journée qui se déroule rarement comme prévu. Le tableau doit rendre l’affectation rapide et la réaffectation sûre, tout en laissant le calcul des itinéraires et des temps de trajet aux systèmes qui connaissent la géographie.

Une file d’attente d’un côté, une journée en mouvement de l’autre

Le travail arrive en continu : une réparation de chaudière demandée la veille, une visite sous garantie, un appel d’urgence à 10 h 40. Chaque intervention a un client, une adresse, un créneau d’arrivée promis à ce client et un ensemble de compétences ou d’habilitations requises. Tant qu’elle n’est pas affectée, elle attend dans une file que le dispatcheur traite au fil de l’eau.

Les techniciens ne sont pas interchangeables. L’un est habilité gaz, un autre transporte les pièces d’un modèle précis, une installation lourde demande une équipe de deux, et chacun a son secteur. Pendant ce temps, des interventions s’éternisent, des camionnettes tombent en panne et des collègues se déclarent malades : l’après-midi est reconstruit plusieurs fois par jour.

Une frise est le bon outil pour savoir « qui fait quoi, et quand ». C’est le mauvais pour savoir « quel ordre de visites réduit le plus les kilomètres », et un tableau de dispatch doit être honnête sur cette différence.

Les arbitrages du dispatcheur

  1. 01

    Qui prend l’intervention

    Compétences, habilitations, secteur et pièces dans le véhicule réduisent la liste. Le dispatcheur choisit parmi les techniciens restants selon leur charge et l’endroit où ils se trouveront.

  2. 02

    Le créneau promis tient-il toujours ?

    Un créneau d’arrivée de 8 h à 12 h est un engagement. Placer une intervention à 11 h 30 après une longue installation peut sembler possible à l’écran et se traduire par un retard dans les faits.

  3. 03

    Combien de trajet prévoir

    Deux interventions aux deux bouts d’une ville ne s’enchaînent pas dans la réalité. Les dispatcheurs laissent des creux ou insèrent des blocs de trajet selon ce qu’ils savent de l’itinéraire.

  4. 04

    Que faire quand une intervention déborde

    Quand une installation prend deux heures de plus, le reste de la journée du technicien doit être décalé, confié à quelqu’un d’autre ou reprogrammé avec le client.

Modéliser le tableau de dispatch

Gardez le travail non affecté hors de la grille et le travail affecté dedans, et faites du dépôt de l’un vers l’autre le moment où votre backend enregistre une affectation.

Ressources
Les lignes sont les techniciens, éventuellement regroupés par équipe ou par région dans une arborescence de ressources, avec des colonnes pour le secteur, les compétences ou le véhicule. L’application restreint les lignes aux candidats avec rows.filter et onRowFilter.
Événements
Une intervention affectée est un événement sur la ligne d’un technicien, avec la référence client, le créneau d’arrivée et le statut comme champs personnalisés. Le trajet peut apparaître comme un événement verrouillé distinct, avec moveDisabled et resizeDisabled, que votre code crée et tient à jour.
Échelle de temps
Utilisez des cellules d’une heure pour le dispatch du jour et des cellules d’un jour pour la semaine à venir, sous forme de deux niveaux de zoom. Désactivez les cellules hors des horaires de service de chaque technicien pour qu’on ne puisse pas déposer d’intervention sur son temps de repos.
Règles
La liste des interventions non affectées utilise makeDraggable : déposer un élément sur un technicien crée un événement et déclenche onEventMoved avec args.external renseigné. Dans onEventMoving, refusez un dépôt sur un technicien qui n’a pas la compétence requise ou en dehors du créneau d’arrivée, avec un message qui dit pourquoi. Activez la sélection d’événements et allowMultiMove pour que plusieurs interventions puissent être décalées ensemble.

Le tableau de dispatch et le back-office

  • Glisser des interventions d’une liste externe vers un technicien et un horaire
  • Filtrage des lignes par compétence, région ou équipe
  • Sélection multiple et déplacement de plusieurs interventions à la fois
  • Refus avec message quand un dépôt enfreint votre règle
  • Cartes d’intervention et panneaux de détail rendus comme composants React
  • Optimisation des tournées, estimation des temps de trajet et cartographie : la bibliothèque ne planifie pas d’itinéraires
  • La prise en charge des demandes, la communication avec les clients et les créneaux d’arrivée que vous promettez
  • L’application mobile des techniciens et les mises à jour de statut depuis le terrain
  • Compétences, habilitations et secteurs sous forme de données, et les règles d’affectation
  • La synchronisation entre dispatcheurs et la résolution des conflits sur le serveur
  • La conversion de fuseaux horaires pour les équipes réparties sur plusieurs régions

Exemples fonctionnels

Les erreurs que répètent les tableaux de dispatch

Lire la frise comme une carte

Deux barres voisines ne disent rien de la distance. Sans blocs de trajet ni vérification par votre service d’itinéraires, une journée peut être libre à l’écran et impossible sur la route.

Retirer l’intervention de la file trop tôt

Ne retirez l’élément de la liste des interventions non affectées qu’une fois l’affectation confirmée par le backend. Un second dépôt avec un identifiant déjà chargé est ignoré avec un avertissement dans la console, ce qui peut masquer un vrai problème de doublon.

Mélanger les fuseaux horaires sur un même tableau

Les heures sont civiles et ne portent aucun fuseau. Une équipe répartie sur plusieurs fuseaux a besoin d’un fuseau d’affichage unique choisi par l’application, avec une conversion avant que les données n’atteignent la frise.

Ne valider que sur le tableau

Deux dispatcheurs peuvent attribuer au même technicien le même créneau au même instant. Le serveur tranche, et le tableau recharge le résultat.

Questions

SuperScheduler optimise-t-il les tournées des techniciens ?

Non. Il n’a ni moteur d’itinéraires, ni géocodage, ni calcul de temps de trajet. Il affiche le plan et permet aux dispatcheurs de le modifier ; votre application ou un service d’itinéraires propose l’ordre des visites et les temps de trajet estimés, que vous pouvez dessiner sous forme d’événements.

Comment glisser des interventions non affectées d’une liste vers le planning ?

Appelez SuperScheduler.Scheduler.makeDraggable sur chaque élément de la liste avec un identifiant, un texte et une durée. Le déposer sur une ligne crée un événement et déclenche onEventMoved avec args.external à true : c’est là que vous envoyez l’affectation à votre backend.

Puis-je n’afficher que les techniciens qui ont une compétence donnée ?

Oui. Stockez les compétences sur chaque ressource, appelez rows.filter avec la compétence choisie et décidez de la visibilité dans onRowFilter. Le filtrage change les lignes affichées, pas les personnes à qui l’on peut affecter une intervention : validez donc aussi les affectations sur le serveur.

Un dispatcheur peut-il déplacer plusieurs interventions à la fois ?

Oui. Avec la sélection d’événements et allowMultiMove activés, les interventions sélectionnées bougent ensemble quand on en fait glisser une, et le changement arrive par les handlers habituels pour que votre backend l’accepte ou le rejette.

Essayez la démo Fieldwork

Fieldwork, une entreprise de maintenance fictive, affecte à une équipe une intervention en attente dans une liste et vérifie la disponibilité sur le tableau. Elle ne prétend pas optimiser les tournées.

Exemples fonctionnels