Sept raisons pour lesquelles votre appli RH flanche dans un centre de contact multiclient

1. Elle présume une seule entreprise. Vous en gérez vingt.

Chaque champ, chaque politique, chaque rapport d'une appli RH générique pend d'un seul employeur. Un manuel. Un organigramme. Un ensemble de règles de paie. Dans un centre multiclient, un agent vit à l'intérieur de plusieurs d'entre eux à la fois : la politique de présence de ce client-ci, la règle d'heures supplémentaires de ce client-là, le calendrier de congés d'un troisième. L'outil a une seule case pour chacun, alors vous vous rabattez sur une valeur par défaut globale et vous suivez les exceptions dans la tête de quelqu'un ou dans un tableur. Les exceptions, c'est là que vivent les erreurs.

2. Il n'y a pas de mur entre les clients.

Un seul employeur signifie une seule hiérarchie de permissions. Ça va, jusqu'à ce que le concurrent du client A soit le client B et que les deux soient sur votre plancher. Une appli RH générique peut masquer des champs avec des rôles et de la configuration, mais elle ne peut pas vous donner une garantie structurelle que les données d'un client ne pourront jamais atteindre un autre, ni qu'un client qui se connecte à un portail ne pourra jamais voir que ses propres gens. Dans un métier que vous gagnez et gardez sur la confiance, « on filtre dans l'application et on fait attention » n'est pas la même promesse que « la base de données ne retournera pas les lignes de l'autre client ». La différence, c'est exactement celle que l'équipe de sécurité de votre prospect vous pose.

3. Elle ne peut pas vous dire quel client fait de l'argent.

La marge agrégée cache vos comptes problématiques. Une appli RH générique détient le coût de la main-d'oeuvre, mais elle ne rattache pas ce coût à un client et à une ligne d'affaires, alors la marge réelle par client est un tableur que vous bâtissez après la clôture du trimestre, si vous le bâtissez. Vous découvrez qu'un compte était déficitaire quand les finances le réconcilient enfin, ce qui est justement trop tard pour faire quoi que ce soit au sujet du taux. Le coût caché d'exploiter chaque client dans son propre outil met des chiffres sur ce que ça coûte discrètement.

4. L'horaire que vous avez facturé est irreproductible.

Le registre à partir duquel vous facturez et payez réellement n'est pas le dossier d'emploi. C'est l'horaire : à quel client chaque agent était affecté, à quel taux, quel jour. Ce registre vit entre votre appli RH et votre outil de GME, et ni l'un ni l'autre ne le versionne correctement. Alors quand une réaffectation est rétrodatée après qu'une facture a déjà été produite, la base de cette facture change discrètement, et vous ne pouvez plus montrer la version à partir de laquelle vous avez facturé. Votre SIRH se souvient des salaires. Se souvient-il de l'horaire que vous avez facturé ? est la version longue de pourquoi celle-ci est pire qu'elle en a l'air.

5. Un agent, deux clients, un horaire qu'elle ne comprend pas.

La polyvalence, c'est ainsi que vous gardez de bons agents occupés d'un compte à l'autre. Mais si l'affectation client simultanée n'est pas une idée de première classe dans le système, le même agent peut être inscrit à la pointe du lundi du client A et à la formation du lundi du client B à la même heure, et rien ne l'attrape jusqu'à ce que quelqu'un s'absente. Le conflit se manifeste comme un manquement au niveau de service ou un remplacement au taux d'heures supplémentaires, et il se manifeste sur le plancher, pas dans l'outil.

6. La conformité est par territoire et par client, pas globale.

Les périodes de repos, les plafonds d'heures supplémentaires et les règles de pause varient selon la province, l'État et le pays, et dans une exploitation en délocalisation proche ou multipays, les règles d'un agent dépendent d'où il est assis. En plus de cela, les clients individuels portent leurs propres régimes : un client de paiements traîne la portée PCI sur les agents qui touchent à son travail, un client de la santé apporte ses propres exigences de confidentialité. Un seul ensemble de règles global se trompe sur au moins l'un d'entre eux, et « se tromper » ici veut dire une plainte en droit du travail ou un audit client échoué.

7. Les rapports font le cumul ou le détail, pas les deux.

Vous avez besoin de deux vues des mêmes données. Le chef de l'exploitation a besoin d'un cumul sur tous les clients pour gérer l'entreprise. Chaque client a besoin d'un détail limité à son seul programme pour la revue trimestrielle. Une appli RH générique présume un seul modèle dimensionnel, alors vous obtenez l'une des deux proprement et vous rebâtissez l'autre à la main à chaque cycle de rapports. Celle bâtie à la main est celle qui est fausse la semaine où vous êtes trop occupé pour la vérifier.

Deux autres, une fois que vous les sentez

Deux qui méritent la liste dès qu'elles commencent à vous coûter. Les compétences et l'admissibilité qui ne sont pas cadrées par client, de sorte que « qui est réellement autorisé à prendre les appels de ce client aujourd'hui » vit dans le savoir tacite plutôt que dans le registre. Et l'intégration qui traite un démarrage de 150 agents pour un nouveau client comme un lot ordinaire, alors que c'est en réalité un projet, avec les vérifications, les certifications, l'équipement et les accès de ce client rattachés.

Le fil conducteur

Le motif dans tout cela est le même. Le logiciel RH générique n'est pas un mauvais logiciel. C'est un logiciel bâti pour une entreprise qui a un seul de chaque chose, vendu à un exploitant qui en a plusieurs de chaque chose. Les lacunes ne sont pas des bogues. Ce sont l'hypothèse qui transparaît.

FrontLine est bâti à l'envers de cela. Chaque enregistrement est cadré au tenant, au client et à la ligne d'affaires, appliqué dans la base de données plutôt que dans du code applicatif que quelqu'un peut oublier de vérifier. L'historique des affectations est à dates d'effet. Le coût se rattache au client. La piste d'audit est immuable. Ce n'est pas que FrontLine soit le seul système RH doté d'une mémoire ou d'un modèle de permissions. C'est que le cas multiclient est ici l'hypothèse de départ au lieu du cas limite. L'Atlas est la façon la plus rapide de voir à quoi ça ressemble sur l'ensemble de la plateforme.

Si vous gérez un seul client, une appli RH générique fait l'affaire. Si vous en gérez plusieurs, la question n'est pas de savoir si ces lacunes existent dans votre pile. C'est laquelle vous mord la prochaine.