Notre équipe d'assistance utilise des tickets pour classer les questions relatives aux services, aux fonctionnalités et aux bugs. Vous pouvez suivre ces tickets via l'URL suivante :

https://app.camping.care/support

Dans cet article, nous souhaitons expliquer la signification des différents statuts des tickets, comment vous pouvez créer un ticket et quand vous pouvez vous attendre à ce que votre ticket soit résolu/prêt.

Comment créer un ticket ?

La meilleure façon de soumettre un ticket est via notre portail de service. Nous vous demanderons toutes les informations pertinentes et, grâce aux différentes catégories, nous pourrons acheminer votre ticket à la personne concernée. Cela nous évite de devoir traiter votre e-mail et vous obtiendrez une réponse plus rapide. Le lien vers le portail de service est le suivant :

https://campingcare.atlassian.net/servicedesk/customer/portal/2/group/-1

Conseil: Vous avez plusieurs questions, améliorations ou autres demandes de service ? Au lieu de créer un long e-mail, créez des tickets séparés. Nous n'aurons alors pas besoin d'analyser l'intégralité de votre e-mail et de le séparer en tickets de service, de bug ou de fonctionnalité.

Billets vedettes

Faire

Chaque demande de fonctionnalité commence avec ce statut. Il s'agit de fonctionnalités qui doivent être priorisées. La priorisation des fonctionnalités sera effectuée par l'un des développeurs

À l'étude

Comprend les demandes qui, selon nous, ajouteront une valeur significative au client et qui correspondent parfaitement à notre feuille de route. Lorsqu'une demande de fonctionnalité est à l'étude, il y a de fortes chances que nous la fournissions dans un avenir proche. Nous vous tiendrons au courant et vous fournirons une mise à jour dans les quelques mois suivant votre demande. 

Considérations futures

Comprend les demandes qui pourraient être ajoutées à notre feuille de route à plus long terme. Une fois par an, nous réexaminerons la demande et modifierons le statut si nécessaire.

Ne pas être pris en considération

Cela inclut les demandes que nous ne sommes pas en mesure de mettre en œuvre. Bien que nous apprécions les avantages potentiels de toutes les demandes, nous ne pouvons malheureusement pas mettre en œuvre toutes les excellentes suggestions de nos clients. Nous ne travaillerons pas sur les demandes ayant ce statut, mais nous les examinerons après un an et envisagerons de modifier le statut. Nous comprenons qu'il peut être décevant de voir une suggestion qui vous tient à cœur être clôturée ou classée sans suite. Cependant, nous pensons que nous devons à nos clients une plus grande transparence sur les demandes de fonctionnalités, et nous pensons que ce flux de travail nous aidera à atteindre notre objectif.

Pour vérifier

Lorsque ce statut est atteint, le travail est terminé par le cessionnaire. Il doit être vérifié par le rapporteur. En général, cela se produit dans l'environnement de préparation. 

Fait

La fonctionnalité est terminée et vérifiée.

Billets de bugs

Comme toute société de logiciels, nous disposons d'un backlog contenant tous les bugs connus. Nous avons 3 niveaux de bugs et nous allons décrire comment créer des tickets pour les bugs.

Flux de travail des bogues

Le flux de travail du bogue contient différents statuts du bogue. 

Faire

Chaque rapport de bug commence avec le statut « À faire ». Il s'agit de bugs qui doivent être priorisés. La priorisation des bugs sera effectuée par Roel ou Arjen. 

Arriéré à court terme

Quand il est dans cet état, cela signifie que nous le récupérons à court terme. Cependant, ce n'est pas une garantie, court terme signifie en général : dans les 3 prochains mois. 

Arriéré à long terme

Les bugs qui sont très complexes à résoudre ou qui ont un impact très faible sur l'utilisateur ont ce statut. Exemple de bugs très complexes : Un bug qui ne peut être résolu qu'avec un changement logiciel majeur ou un changement d'infrastructure. 

En cours

Nous travaillons actuellement sur ce bug. 

Pour vérifier

Lorsque ce statut est atteint, le travail est terminé par le cessionnaire. Il doit être vérifié par le rapporteur. En général, cela se produit dans l'environnement de préparation. 

Fait

Le bug est corrigé et vérifié.

Quand ma demande sera-t-elle prête ?

C'est l'une des questions les plus fréquemment posées. Quand est-ce que c'est fait ? Une question simple avec une réponse compliquée. Alors que pouvons-nous en dire ? 

Lorsqu'il y a une version large jointe comme 2025 après la saison Cela donne une indication sur le moment où une certaine fonctionnalité/un certain bug sera prêt. Il s'agit d'une indication, pas d'une promesse. 

Lorsque le ticket comporte une version de publication, vous pouvez le restreindre davantage. Si la version actuelle est Backoffice 3.22.1 et la version de sortie du ticket est Backoffice 3.23.1 on peut dire en toute sécurité qu'il sera disponible dans le mois prochain. 

Si c'est un critique bug qui sera résolu au plus vite. Plutôt des heures que des jours… 

Si le bug est dans le arriéré à court terme l'indication est quelque part dans les 3 prochains mois. 

Parfois, il y a un date d'échéance spécifié avec un ticket. S'il y en a un, c'est ce que vous pouvez communiquer.