Gfacility

Des demandes qui se traitent elles-mêmes

Publiez un catalogue dans lequel les gens peuvent vraiment commander, puis laissez des règles router, valider et clôturer les demandes de routine. Accès, matériel, onboarding, badge de parking, dans la même file que vos incidents.

Des demandes qui se traitent elles-mêmes

Demander une fois, sous la bonne forme

Un catalogue, pas un champ de texte vide

Services et produits sont publiés comme articles commandables, les gens choisissent donc au lieu de décrire. Moins de demandes reviennent pour précision parce que le formulaire a déjà posé les bonnes questions.

Des formulaires avec de vraies questions

Chaque type de demande porte ses propres questions, champs obligatoires et valeurs par défaut, pour qu'une demande de portable collecte le modèle et le centre de coûts, et une demande d'accès le système et le motif.

La validation comme étape, pas comme canal parallèle

La validation est un statut du workflow, avec le validateur, l'horodatage et le délai enregistrés sur la demande. Fini de courir après une décision qui dort dans une boîte mail.

Une demande, plusieurs tâches

Un onboarding n'est jamais un seul travail. Une demande se ramifie en autant de tâches que nécessaire, chacune vers son groupe de travail, et se clôture quand toutes sont faites.

Où passe réellement le temps

  • Routée au bon groupe par règle, pas par une permanence de tri
  • Validée dans le flux, avec le délai de validation mesuré
  • Les demandes traitées enregistrent l'actif qu'elles ont créé
  • Répondues depuis la base de connaissances quand aucun travail n'est nécessaire
  • Clôturées automatiquement dès que chaque tâche en dessous est faite
Voir l'automatisation des workflows

La même file que le reste du travail

Un seul backlog entre les lignes de service

Un badge de parking, un portable et un radiateur cassé arrivent dans le même système avec la même logique SLA, personne n'a donc besoin de savoir quel service possède quel formulaire.

Un SLA qui respecte votre calendrier

Les objectifs de demande tournent sur le même moteur SLA que les incidents, heures ouvrées et jours fériés compris, pour qu'une commande du vendredi après-midi ne soit pas en retard le lundi matin.

L'IA répond avant de créer

Quand la réponse existe déjà, l'IA la fournit et aucune demande n'est créée. Il ne reste que le travail qui exige vraiment une personne ou une commande.

Les coûts atterrissent au bon endroit

Parce que l'article de catalogue porte son prix et son centre de coûts, les demandes traitées alimentent directement la structure financière au lieu d'être reconstituées en fin de trimestre.

Questions sur le traitement des demandes

Traitement des demandes de service

Est-ce un produit distinct du service desk?

Non. Les demandes sont les mêmes enregistrements que vos incidents, avec leurs propres types, formulaires et workflows. Une file, un moteur SLA, un modèle de reporting.

Peut-on exiger une validation avant toute action?

Oui. La validation est un statut du workflow de la demande, vous décidez donc par type si elle est requise, et le validateur comme le délai sont enregistrés sur l'enregistrement.

Une demande peut-elle créer plusieurs travaux?

Oui. Des règles peuvent ramifier une demande en tâches, chacune avec son groupe de travail et son échéance, et la demande se clôture quand la dernière est faite. C'est ainsi que tourne l'onboarding.

Les utilisateurs finaux ont-ils besoin d'une licence?

Non. La tarification est par agent et les utilisateurs finaux sont illimités, ouvrir le catalogue à toute l'organisation ne change donc pas ce que vous payez.

Transformez vos formulaires en catalogue

Planifiez un premier échange et nous modéliserons deux de vos propres types de demande pendant la session.

Planifier un premier échange