Ensuite, tu parles du support client (genre le support d'un éditeur logiciel), alors que je parle du support interne (eg, ton département info).
Je perle en tant que product owner, donc de support sur le produit. Interne ou externe ça m'est égal. Et ça tombe bien en ce moment je suis sur une mission ou le support est un point chaud, point chaud qui a été atténué par la mise en place d'un système de tickets. Après que les tickets soient ouverts par une cellule que tu appelles ou par l'utilisateur de ton produit je dirais que c'est pas mon problème : je n'ai pas les ressources nécessaire pour avoir une personne à plein temps (voire plus) par jour qui entegistre des appels de support, du coup les utilisateurs (qui sont des utilisateurs internes ou partenaires ) ouvrent des tickets.
forcer les gens à ouvrir un ticket avant de leur répondre, pas d'avoir un ticket. EG, l'acte précis de dire "maintenant, on ne parle que si il y a un ticket avant".
C'est une phaser par laquelle on doit parfois passer lorsque les gens abusent. Après ça dépend des circonstances. Parce que sinon tu as des équipes qui passent les 2/3 de leur temps à faire du support alors qu'elles ne sont pas là pour ça à la base (ou que la charge de support doit être moindre), parce que des gens par facilité contactent directement les personnes alors que ça ne doit pas être le cas.
C'est principalement pour le bénéfice de la boite. Je ne vais pas être cynique de bon matin et dire que c'est utiliser les clients comme testeurs, car ça serait une énorme simplification trompeuse, mais on peut se poser la question du travail gratuit.
Non. Pas du tout. Une demande de support ce n'est pas simplement un ticket pour corriger des bugs. Ca peut être une demande d'informations sur ton produit, des choses que tu aurais pu oublier dans une doc, un accompagnement à l'utilisation de telle ou telle fonctionnalité. Le support peut englober pas mal de choses.
Mais le scope du support doit être cadré, ce qui n'est pas souvent le cas (et c'est bienb souvent ça la base du problème). Je pourrais te citer des tas d'exemples de demandes de support faites à un service, demandes qui n'ont rien à voir avec le produit mais qui y sont envoyés parce que la personne ne sait pas ou le faire (en gros des tickets du style "ma box ne marche pas ), j'ai plus de courant électrique, pouvez-vous me la faire remarcher ?" auprès d'un FAI ...).
ça rajoute de la latence (comme les mails), latence qui coûte de l'argent à la boite.
Euh ... Non. Ca c'est ne voir qu'un aspect du problème. Pour ma part le fait de répondre "on demand" à des gens comme tu le suggère me ferait passer 100% de temps de l'équipe à faire du support, et empêcherait de réaiser les fonctionnalités attendues par la boite ce qui couterait plus cher encore, surtout lorsque les clients abusent.
À savoir que si j'ai un souci sur le produit, je passe mon temps avec le support pour indiquer comment le résoudre, mais que le bénéfice principal retombe sur l'éditeur qui a un meilleur produit sur la base du support, support que les clients payent.
Faut savoir ... Tu parles de support interne ou de support aux utilisateurs ? Parce que si je reste sur le cadre d'utilisateurs "internes", le fait qu'il n'y ait pas de facturation est un "pousse au crime" à l'abus de sollicitation de support. J'ai eu des utilisateurs qui ont appelé parce qu'ils n'arrivent pas à se connecter à leur base de données, ou parce qu'ils ne savent pas utiiser vi, alors que le produit sur lequel je travaillais était du déploiement via CI/CD ..... Pour quantifier ce genre d'appel, si tu n'as pas de système de ticket c'est mort ... Et si tu ne peux pas le quantifier pour prendre les mesures adéquates, c'est l'ensemble des clients de ton produit qui en paye les conséquences.
Snon les utilisateurs peuvent appeler le support parce que le produit ne marche as comme attendu Donc ça peut vouloir dire que le produit est bugge (dans ce cas il fgaut corriger, et c'est rarement de la correction "online" avec l'utilisateur). Un ticket permet de faire en sorte que l'équipe de dev prenne en compte la demande (que ce soit dans l'immédiat ou un peu plus tard), et au client de suivre lui-même la situation de résolution e son problème. Mais ça peut vouloir dire également que la doc associée n'est pas claire (c'est pas évident d'avir une doc qui répond à tout), qu'une comm n'a pas été bien faite ou que le produit devient trop complexe pour qu'on le donne tel quel à l'utilisdateur et qu'il faut mettre en place des sessions de formation .... Sans suivi, les problèmes sous-jacents aux incidents passent "sous le tapis" et au final, c'est l'utilisateur qui à long terme en paye les conséquences. Ca peut vouloir dire également que le roduit ou la fonctionnalité ne couvre oas un use case qui n'a pas été identifié, donc ça te fait une nouvelle user story dans ton backlog ... Ca peut vouloir dire plein de choses qu'il est plus efficace de traiter avec des tickets ...
Un système de ticket va avoir tendance à subtilement inciter à passer par le système de ticket plutôt que de se retrouver ensemble pour résoudre le probléme .
L'un n'empêche pas l'autre. Sauf que le lendemain une autre personne risque de te recontacter pour le même problème tu vas passer 15 mn encore avec ... et ainsi de suite sans que le problème de fond ne soit résolu Alors je t'accorde pour ça qu'il est nécessaire de faire de la revue de tickets pour que ça puisse marcher, et que c'est loin d'être toujours le cas (chez nous il y en a une, ça aide beaucoup, bien que je vois encore des choses à améliorer pour qu'elles soient plus productivesmais ça aide beaucoup pour la prise en compte des besoins clients).
Au support interne, c'était l'inverse (et mon chef m'avait explicitement interdit d'utiliser le script que j'avais fait pour ouvrir le ticket rapidement).
Nous on a mis en place des interfaces simplifiées ... En gros on a partagé l'équivalent de ton script pour tout le monde sur une interface accessible à l'utilisateur qui n'a qu'a remplir le composant sur lequel il a un problème ou un besoin, le type de problème qu'il a et une description. Je trouve ça plus efficace ... Et en pratique je demande aux équipes de ne pas ouvrir les tickets à la place des gens parce que sinon ils ne font que ça, et que c'est la porte ouverte aux abus de toute sorte.
Des cas de ce genre existent, mais mêmes les personnes que tu qualifies de feignasses doivent avoir du support, et la seule raison de ne pas leur donner, c'est le coût (eg, on veut pas embaucher 2 personnes pour faire le travail d'une).
Non. C'estaussi le érimètre et le cadre de ton produit et de ton support.
Si tu fournis un outil sans mode d'emploi, effectivement. C'est à toi d'assumer le fait que tu ne fournis pas les instructions nécessaires à la bonne utilisation du produit. Maintenant, si ton outil est documenté et que la pertsonne a la flemme de lire cette doc, elle peut demander du support mais dans ce cas elle paye. Et enfin il y a des gens qui ne te demande pas du support sur l'outil mais de faire le travail à leur place avec l'outil, (potentiellement parce qu'ils ne sont pas non plus bien formés à leur métier ... ou qui passent leur temps à demander aux autres pour chercher à leur place), ce qui de mon avis n'est pas du ressort du support.
On pourrait prendre l'exemple d'une pelleteuse : est-ce au constructeur de former les utilisateurs à la conduite d'engin de travaux ? Non, c'est la charge de l'employeur de recruter du personnel formé à ça. Est-ce au support du constructeur d'utiliser l'outil pour creuser ? Non, c'est l'employé qui est censé être formé pour ça. Par contre rien n'empêche le constructeur de mettre en place des sessions de présentation/formation à son matériel, que les utilisateurs pourront choisir de suivre ou non, et qu'il fera payer (ou non) .... Mais en aucun cas ce n'est au support du constructeur constructeur de faire le trou ....
Et comme le but est de réduire les coûts, tu te retrouve avec les gens qui ont le moins de qualifications spécialisées en première ligne (car c'est moins cher), qui vont parfois avoir du mal à piger les tickets (j'ai plusieurs fois du aller moi même dans le backend et contourner l'agent pour mes propres tickets). Parce que les incitations sont de traiter X tickets par jour, donc forcement, tu pousses à passer moins de temps.
Ce n'est pas qu'un problème de cout c'est aussi du au fait que des personnes qualifiées ne voudront pas passer leurs journées à faire ce genre de travail. Dans une boite ou j'ai travaillé, une solution simple était de faire e sorte que les personnes qui développaient/mettaient en place les solutions passent 1/2 à 1 journée par semaine à faire du support, et 1/2 à 1 journée par semaine à traiter les taches récurrentes. Ca marchait plutôt bien, par contre ça n'enlevait pas à l'utilisateurt la respoinsabilité d'ouvrir un ticket (et en général quand c'était la première fois on les accompagnait ...).
J'ai eu quelqu'un qui est venu me voir parce que le site de la banque n'était pas fonctionnel et il fallait uploader un document pour un plan pour les salariés. Je n'ai aucun contrôle dessus, mais clairement, la personne était en panique à cause d'une deadline, et même si c'est pas mon scope, je pense que c'est mon devoir d'aider, parce que ça rends quand même l'ambiance plus sympa au travail.
Ce n'est as mon point de vue : occasionnellement pourquoi pas, mais il arrive un moment ou ce genre d'attitude ne fait que cacher la poussière sous le tapis ... De plus tu ne peux pas non plus prendre tous es malheurs du monde. Un support c'est une quantité de ressource limités pour un scope défini. Le hors scope ça peut se faire de temps en temps mais faut pas que ce soit une habitude. Enfin quand tu traites des choses hors-scope tu prend le risque de te mettre toi et ton équipe dans des situations très inconfortables (du vécu de ma part).
Et malhereusement, ce que j'ai vu depuis plus de 20 ans que je bosse, c'est que les mauvaises habitudes se prennent vite, mais que curieusement elles mettent beaucoup de temps à disparaître.
Et tout ça, pour moi, ça rentre aussi dans l'ambiance que tu veux à ton travail. Si tu veux une ambiance ou les gens se soutiennent et que les gens se sentent bien, c'est mieux de ne pas mettre de barrières à l'entraide.
C'est typiquement le gere d'attitude qui fait que toi et ton équipe risquent de passer 50% de son temps à faire le boulot des autres au détriment de son propre boulot. Parce que "faut aider", "faut une bonne ambiance", etc .... et les managers et les directions comptent sur ça (c'est une autre façon d'avoir "une personne qui fait le boulot à la pace de deux" que tu citais plus tôt).
[^] # Re: Je trouve le sujet souvent caricatural
Posté par totof2000 . En réponse au journal Je veux pas y retourner. Évalué à 3.
Je perle en tant que product owner, donc de support sur le produit. Interne ou externe ça m'est égal. Et ça tombe bien en ce moment je suis sur une mission ou le support est un point chaud, point chaud qui a été atténué par la mise en place d'un système de tickets. Après que les tickets soient ouverts par une cellule que tu appelles ou par l'utilisateur de ton produit je dirais que c'est pas mon problème : je n'ai pas les ressources nécessaire pour avoir une personne à plein temps (voire plus) par jour qui entegistre des appels de support, du coup les utilisateurs (qui sont des utilisateurs internes ou partenaires ) ouvrent des tickets.
C'est une phaser par laquelle on doit parfois passer lorsque les gens abusent. Après ça dépend des circonstances. Parce que sinon tu as des équipes qui passent les 2/3 de leur temps à faire du support alors qu'elles ne sont pas là pour ça à la base (ou que la charge de support doit être moindre), parce que des gens par facilité contactent directement les personnes alors que ça ne doit pas être le cas.
Non. Pas du tout. Une demande de support ce n'est pas simplement un ticket pour corriger des bugs. Ca peut être une demande d'informations sur ton produit, des choses que tu aurais pu oublier dans une doc, un accompagnement à l'utilisation de telle ou telle fonctionnalité. Le support peut englober pas mal de choses.
Mais le scope du support doit être cadré, ce qui n'est pas souvent le cas (et c'est bienb souvent ça la base du problème). Je pourrais te citer des tas d'exemples de demandes de support faites à un service, demandes qui n'ont rien à voir avec le produit mais qui y sont envoyés parce que la personne ne sait pas ou le faire (en gros des tickets du style "ma box ne marche pas ), j'ai plus de courant électrique, pouvez-vous me la faire remarcher ?" auprès d'un FAI ...).
Euh ... Non. Ca c'est ne voir qu'un aspect du problème. Pour ma part le fait de répondre "on demand" à des gens comme tu le suggère me ferait passer 100% de temps de l'équipe à faire du support, et empêcherait de réaiser les fonctionnalités attendues par la boite ce qui couterait plus cher encore, surtout lorsque les clients abusent.
Faut savoir ... Tu parles de support interne ou de support aux utilisateurs ? Parce que si je reste sur le cadre d'utilisateurs "internes", le fait qu'il n'y ait pas de facturation est un "pousse au crime" à l'abus de sollicitation de support. J'ai eu des utilisateurs qui ont appelé parce qu'ils n'arrivent pas à se connecter à leur base de données, ou parce qu'ils ne savent pas utiiser vi, alors que le produit sur lequel je travaillais était du déploiement via CI/CD ..... Pour quantifier ce genre d'appel, si tu n'as pas de système de ticket c'est mort ... Et si tu ne peux pas le quantifier pour prendre les mesures adéquates, c'est l'ensemble des clients de ton produit qui en paye les conséquences.
Snon les utilisateurs peuvent appeler le support parce que le produit ne marche as comme attendu Donc ça peut vouloir dire que le produit est bugge (dans ce cas il fgaut corriger, et c'est rarement de la correction "online" avec l'utilisateur). Un ticket permet de faire en sorte que l'équipe de dev prenne en compte la demande (que ce soit dans l'immédiat ou un peu plus tard), et au client de suivre lui-même la situation de résolution e son problème. Mais ça peut vouloir dire également que la doc associée n'est pas claire (c'est pas évident d'avir une doc qui répond à tout), qu'une comm n'a pas été bien faite ou que le produit devient trop complexe pour qu'on le donne tel quel à l'utilisdateur et qu'il faut mettre en place des sessions de formation .... Sans suivi, les problèmes sous-jacents aux incidents passent "sous le tapis" et au final, c'est l'utilisateur qui à long terme en paye les conséquences. Ca peut vouloir dire également que le roduit ou la fonctionnalité ne couvre oas un use case qui n'a pas été identifié, donc ça te fait une nouvelle user story dans ton backlog ... Ca peut vouloir dire plein de choses qu'il est plus efficace de traiter avec des tickets ...
L'un n'empêche pas l'autre. Sauf que le lendemain une autre personne risque de te recontacter pour le même problème tu vas passer 15 mn encore avec ... et ainsi de suite sans que le problème de fond ne soit résolu Alors je t'accorde pour ça qu'il est nécessaire de faire de la revue de tickets pour que ça puisse marcher, et que c'est loin d'être toujours le cas (chez nous il y en a une, ça aide beaucoup, bien que je vois encore des choses à améliorer pour qu'elles soient plus productivesmais ça aide beaucoup pour la prise en compte des besoins clients).
Nous on a mis en place des interfaces simplifiées ... En gros on a partagé l'équivalent de ton script pour tout le monde sur une interface accessible à l'utilisateur qui n'a qu'a remplir le composant sur lequel il a un problème ou un besoin, le type de problème qu'il a et une description. Je trouve ça plus efficace ... Et en pratique je demande aux équipes de ne pas ouvrir les tickets à la place des gens parce que sinon ils ne font que ça, et que c'est la porte ouverte aux abus de toute sorte.
Non. C'estaussi le érimètre et le cadre de ton produit et de ton support.
Si tu fournis un outil sans mode d'emploi, effectivement. C'est à toi d'assumer le fait que tu ne fournis pas les instructions nécessaires à la bonne utilisation du produit. Maintenant, si ton outil est documenté et que la pertsonne a la flemme de lire cette doc, elle peut demander du support mais dans ce cas elle paye. Et enfin il y a des gens qui ne te demande pas du support sur l'outil mais de faire le travail à leur place avec l'outil, (potentiellement parce qu'ils ne sont pas non plus bien formés à leur métier ... ou qui passent leur temps à demander aux autres pour chercher à leur place), ce qui de mon avis n'est pas du ressort du support.
On pourrait prendre l'exemple d'une pelleteuse : est-ce au constructeur de former les utilisateurs à la conduite d'engin de travaux ? Non, c'est la charge de l'employeur de recruter du personnel formé à ça. Est-ce au support du constructeur d'utiliser l'outil pour creuser ? Non, c'est l'employé qui est censé être formé pour ça. Par contre rien n'empêche le constructeur de mettre en place des sessions de présentation/formation à son matériel, que les utilisateurs pourront choisir de suivre ou non, et qu'il fera payer (ou non) .... Mais en aucun cas ce n'est au support du constructeur constructeur de faire le trou ....
Ce n'est pas qu'un problème de cout c'est aussi du au fait que des personnes qualifiées ne voudront pas passer leurs journées à faire ce genre de travail. Dans une boite ou j'ai travaillé, une solution simple était de faire e sorte que les personnes qui développaient/mettaient en place les solutions passent 1/2 à 1 journée par semaine à faire du support, et 1/2 à 1 journée par semaine à traiter les taches récurrentes. Ca marchait plutôt bien, par contre ça n'enlevait pas à l'utilisateurt la respoinsabilité d'ouvrir un ticket (et en général quand c'était la première fois on les accompagnait ...).
Ce n'est as mon point de vue : occasionnellement pourquoi pas, mais il arrive un moment ou ce genre d'attitude ne fait que cacher la poussière sous le tapis ... De plus tu ne peux pas non plus prendre tous es malheurs du monde. Un support c'est une quantité de ressource limités pour un scope défini. Le hors scope ça peut se faire de temps en temps mais faut pas que ce soit une habitude. Enfin quand tu traites des choses hors-scope tu prend le risque de te mettre toi et ton équipe dans des situations très inconfortables (du vécu de ma part).
Et malhereusement, ce que j'ai vu depuis plus de 20 ans que je bosse, c'est que les mauvaises habitudes se prennent vite, mais que curieusement elles mettent beaucoup de temps à disparaître.
C'est typiquement le gere d'attitude qui fait que toi et ton équipe risquent de passer 50% de son temps à faire le boulot des autres au détriment de son propre boulot. Parce que "faut aider", "faut une bonne ambiance", etc .... et les managers et les directions comptent sur ça (c'est une autre façon d'avoir "une personne qui fait le boulot à la pace de deux" que tu citais plus tôt).