Reprise du message précédent :
Clairement chiant comme méthode. un commercial m'avait expliqué une fois, il avait un prix de départ à 150k, tant qu'il était au dessus de 90k, il avait son bonus maximal, et le niveau en dessous duquel il refusait la vente du logiciel c'était 60k parce que pas rentable en exploitation ensuite.
 
Mais au final : microsoft qui vend ses licences end user à 100€ l'année sauf au black friday à 50€, c'est exactement le même ordre de grandeur.

 
En l'occurence c'est des trucs sans support donc non... Pour le coup j'imagine plutôt que la cause c'est qu'à un moment, des acheteurs ont reçu par leur management des objectifs chiffrés en termes de pourcentage de rabais à obtenir, et que la loi de campbell a fait le reste (l'acheteur achète seulement s'il a un gros rabais affiché => le fournisseur lui met le chiffre qu'il demande puisque pour le fournisseur ça change rien => inflation du prix de base qui devient fictif).

Le bonheur
 

Faut pas s'arrêter à un détail comme le prix
 
Je +1 avec toi, quand je veux acheter un truc, si j'ai pas accès rapidement au prix ca me gonfle
Et quand t'as un commercial qui te sort une tarification "sur mesure" qui tient sur plusieurs pages

Test dans une VM dans mon homelab : Zammad fonctionne bien. Ça a l'air de faire pas mal de truc sans être trop chiant à gérer.

Maintenant install dans une VM propre en prod, on va tester ça de manière plus poussée (intégration LDAP, portail client etc.)

Tellement Quand avec un fournisseur X tu dois demander une offre sur un formulaire ou par email, donner ton nom/prénom/date de naissance/rôle dans la boite/nom de ton chien, puis attendre 3 jours une réponse voire relancer car le commercial est en vacances ou sur un gros projet alors qu'avec un fournisseur concurrent Y, il y a un prix public affiché qui sans forcément être génial n'est pas non plus abusé, de quoi acheter par carte/paypal/virement/facture, traité automatiquement...

 
Tu as Regardé Bugzilla ?  
 
Nous on avait un Bugzilla en DMZ, et ensuite on avait un gros Bugzilla avec une synchro bi-directionnelle avec des filtres pour par tout montrer au client (surtout quand on dit que le PB est entre la chaise et le clavier )

 
En fait je voudrai limiter le taff sur la partie « espace client » à juste renvoyer avec une création de l'user auto dans la plate forme de support (comme ça le client va dans un Dashboard spécial support mais il a pas l'impression d'être vraiment passé sur autre chose ni d'avoir eu à faire un effort pour créer un ticket de support)

C'est l'essentiel du métier dans ma boite, la production de gros bouquins rouges qu'on voit à la télé (pub gratuite) dès qu'il est question de justice ou de loi...
 
A+,

Ta boite est helvète ?

Non. Le fondateur était Jurassien.
Ma boite englobe en fait celle qui publie les gros bouquins rouges et d'autres, toujours spécialisées sur les textes juridiques, administratifs, etc, et n'est pas limitée à l'hexagone.
Mais on fait pas que du papier, on publie aussi directement sur le web, avec un système d'abonnement, des sites d'actualités spécialisés.
A+,

https://msrc-blog.microsoft.com/202 [...] r-attacks/
 
malware implémenté directement dans le code source de solarwind  depuis le mois de mars    18000 clients concernés      

 
Notre Cogip est peu regardante sur le budget tant que ça fonctionne.
 
Et pourtant on a pris Papercut.
 
Faut dire que la GUI custom qui apparaît sur les écrans des printers est très luser proof.  

 
Same difference      

 
Service Now  

 
J'ai mis en place Request Tracker à une époque, ça marchait bien, et y'a une API.

 
ça tombe bien, notre monitoring c'est du full Solarwinds Orion.    

Donc la plupart des softs de support sont centré sur les emails. Les emails putain

Même en mode portail web, ya quasi jamais de support de Markdown, et on sent que c'est toujours « tordu » comparé à du ticket Github/Gitlab qui répond bien à mon besoin pourtant.

Tin mais sérieux, on est au temps des applis web depuis 10 ans+ et on parle encore d'utiliser l'email pour des tickets de support. Bordel Desfois j'ai pas l'impression de vivre dans le même monde que certains éditeurs de software.

Mais c'est quoi le problème avec l'email ?

c'est d'la merde  

C’est chiant à nettoyer.

 
Bah c'est de la merde pour faire du support
 
1. Si tu as un portail web pour tes tickets, ça te fait 2 points d'entrée. Aussi, tu peux pas contrôler/pre-trier depuis les emails quelle partie du support est concernée (genre dans un form web, tu pourrai choisir : produit 1, produit 2, support commercial etc et directement adresser les bonnes équipes). Ou alors faut créer des boîtes séparées (boitemailsupportproduit1@toto.com boitemailsupportproduit2@toto.com et encore, ça te fait vite une chiée de boîte, en laissant l'user choisir des email dans une liste pour communiquer, c'est qui est excessivement débile par rapport à simple form avec un select)
2. Si tu as pas de portail web et que les emails : les problèmes du 1 mais en plus aucun dashboard pour suivre tous tes tickets à un seul endroit.
 
C'est comme faire du dev open source avec des mailing lists : c'est nul à chier et pas pratique mais les dev historiques sont habitués alors ils veulent pas changer.
 
À aucun moment je vois un côté positif pour le front office de support avec des mails (en tant qu'éditeur soft multi produits et services).
 

Bah, tu peux prendre request-tracker, mais sans mettre les mails en point d'entrée, juste un formulaire.
 
Et via l'api, tu peux tout garder via le web.

Chez mon client actuel, c'est GLPI.

Ca se coince avec les filets (flemme de trouver un meilleur jeu de mot).
 
Je comprend bien le problème de traiter les incidents par mail. Ca te pollue ta boite mail alors que ca te concerne pas forcément, ou si t'es absent. Plus simple d'avoir tout l'historique avec un outil web, plutôt que de lire 45 mails de réponses ping pong client/support. Enfin j'imagine qu'il doit y avoir d'autres raisons pour plam.

Ah non cette GUI des enfers  

Par exemple, je teste Zammad : le back office est au top, ya plus de truc ultra avancés de ouf (trigger, règles auto, escalade de ticket, notifications etc.)

Mais pour juste échanger au sein de l'inteface web, tu as une pauvre conversation avec, enfin plutôt sans :
1. Pas de support du Markdown
2. Pas de raccourci pour envoyer (Ctrl+Entrée ne marche pas)
3. Pas d'accès rapide aux tags ni assez de contexte

Pourtant je trouve que c'est le putain de cœur d'une appli de support avec tes users : une belle mise en forme pour que la conversation se fasse de manière fluide. J'arrive pas à comprendre comment c'est possible d'oublier ça.

Parce que les users sont teubés, et que déja s'ils savent envoyer un email c'est bien
 
et que quand tu traites un incident, c'est bien d'avoir un email que tu peux forward aux gens concernés/pour te couvrir
et que si y'a du markdown tu vas etre baisé
et puis quand t'as tout dans gmail pour un search historique de bourrin c'est pratique

J'aime aussi.

Plam qui pivote dans le ticketing, dans 5 ans Atlassian rachète Vates pour 1 million par employé.

Ok, donc vous êtes passés de Gespage à Papercut à cause de ça ? Vous n'avez que du Ricoh ? Ça donnait quoi sur les autres marques ?
Bon après, je n'ai pas de Ricoh. C'est du full Kyocera pour le moment.

Au boulot on a Bugzilla, JIRA, Salesforce, Helpnow... et surement d'autres outils dans des départements lointains et inconnus

T'inquiètes pas que les users ils savent créer des tickets de support On utilise déjà massivement du Markdown dans notre UI et ça va parfaitement bien (au pire on édite le post du client pour utiliser la bonne syntaxe).

Ça fait quoi, 5 ans qu'on utilise notre solution (frontoffice dans l'espace client, backoffice/backend dans Gitlab) et jusque là rien à redire.

Par contre, avec l'agrandissement du support et l'apparition de nouveaux produits, je préfèrerai qu'on arrête les devs customs et qu'on prenne des outils génériques (bordel une UI web de création de ticket ça parait pas la mer à boire pourtant !).

Et franchement, notre hack qui marche depuis 5 ans reste globalement mieux sur le cœur du problème (l'échange avec le client) Alors certes on a pas les triggers ni les trucs comme ça, mais franchement le niveau moyen c'est genre support@toto.fr pour dire « j'arrive pas à commande tel produit » et faire suivre aux équipes commerciales. On est pas du tout au niveau pour faire du putain de support sur un software

A quand le repacking de l'offre et la vente ?

suivant les boites, les truc de support peuvent être intégrés à des application métier, etc...
 
au final, oui le markdown c'est joli, mais c'est pas forcément ce qui va donner de la valeur fonctionnelle à un systeme de ticketing

Sinon il y a System Center Service Manager

T'as des alias pour ça.
Et ensuite tu peux faire de la création automatique de ticket catégorisé en fonction de l'alias sur lequel ça a été envoyé.

Sinon il y a l'ITSM dans Teams maintenant

Bah écoute, ce qui donne la valeur à l'heure actuelle c'est que le support soit capable de lire des stacktrace et ça arrive assez souvent. Donc sans support du Markdown, bon courage

Okay mettons que je fais 36 alias de boîtes : il va tout de même falloir que je « présente » ça dans le frontoffice de la zone client, de manière plus ou moins transparente. J'imagine pas avoir une liste : « Pour le support commercial, envoyer à truc. Pour le support XCP-ng Enterprise, machin. XCP-ng Standard, bidule etc.. L'avantage d'un form avec un select c'est qu'on peut afficher (ou griser) certains types de tickets (genre CRITICAL grisé pour XCP-ng car tu as pas de support Enterprise).

Si ça me coûte d'écrire moi-même une partie du front office au lieu d'avoir juste un putain de form/select c'est tout de même bien dommage…

Tu veux pas tester Dynamics 365 ?