Fuseaux horaires et interfaces de calendrier
Je suis un administrateur système qui planifie l'ouverture d'un centre d'appels pour prendre les appels des hôpitaux.
Nous avons 3 éléments:
- Administrateur système (Ohio - ET)
- Centre d'appels (Denver - MT)
- Hôpital (Californie - PT)
Comme vous pouvez le voir, 3 fuseaux horaires:
- Est ( ET )
- Montagne ( MT )
- Pacifique ( PT )
Exemple de scénario:
- L'hôpital appelle le centre d'appels et dit:
"Hé, nous avons besoin d'une assistance téléphonique supplémentaire pour les heures de 8a à 6p (PT)."
- Le centre d'appels appelle l'administrateur système pour planifier l'assistance supplémentaire.
Ainsi, comme vous pouvez le voir, l'administrateur des systèmes de fuseau horaire ET planifie les heures de couverture hospitalière du fuseau horaire PT pour un centre d'appels de fuseau horaire MT).
Il y a une confusion fréquente car l'administrateur système ne sait pas s'ils ajoutent des blocs horaires dans leur fuseau horaire, le fuseau horaire du centre d'appels ou le fuseau horaire de l'hôpital.
Remarque: l'interface change, cela fait partie de ce que je fais ici.
Je viens de capturer l'interface telle qu'elle existe aujourd'hui:
L'initiateur de la demande et le consommateur final du service est un hôpital. Il est donc préférable d'utiliser l'heure locale de l'hôpital pour la délestage dans le système.
Le centre d'appels fonctionne sur un autre fuseau horaire, vous avez donc besoin d'un outil de cartographie facile pour définir la demande de l'hôpital dans l'heure du centre d'appels.
Le temps administrateur a un peu de sens dans le système, c'est plus la source d'erreurs.
Comme la correspondance entre le temps de l'hôpital et du centre d'appels nécessite une certaine conversion, il est préférable d'inclure l'outil approprié dans le système, plutôt dans une tête humaine.
Je pense que vous pourriez utiliser un système de planification avec un outil de cartographie du temps intégré, qui fournit un support visuel solide pour éliminer les erreurs. Regardez la photo, je pense que c'est assez clair:
Je pense aussi qu'il y a un lien excessif dans l'interaction. Pourquoi un hôpital ne pouvait pas laisser la demande à un administrateur sans déranger le centre d'appels?
Il doit être plus clair quel fuseau horaire présente votre interface. Vous pouvez ajouter un avertissement important indiquant "toutes les heures sont locales", ou avoir la possibilité de changer le fuseau horaire présenté.
En outre, le fuseau horaire doit être une option explicite lors de l'ajout de nouvelles entrées à la planification. Les utilisateurs devraient pouvoir ajouter des blocs de temps dans un fuseau horaire donné; ce serait ma préférence si je devais ajouter fréquemment des blocs dans plusieurs fuseaux horaires. Quelque chose comme ça pourrait fonctionner:
télécharger la source bmml - Wireframes créés avec Balsamiq Mockups
En fin de compte, il vous suffit de clarifier le cadre de référence pour l'utilisateur - s'il va ajouter un bloc à la planification, pour quel fuseau horaire saisit-il ce bloc? S'ils sont invités à fournir ces informations, l'administrateur ajustera probablement son processus pour exiger ces informations aux personnes qui souhaitent que des entrées soient ajoutées à la planification.
Edit: Il semble logique que l'horaire présenté soit dans le fuseau horaire local du centre d'appels (puisque c'est lui qui utilise l'horaire); il serait toujours logique de saisir des entrées dans le calendrier avec les informations de fuseau horaire (c'est-à-dire que je suis un hôpital sur la côte est et que je veux une assistance de 2 à 4 HE).