Il nostro team di supporto utilizza i ticket per categorizzare le domande su servizi, funzionalità e bug. Puoi seguire quei ticket tramite il seguente URL:

https://app.camping.care/support

In questo articolo vogliamo spiegare il significato dei diversi stati dei ticket, come è possibile creare un ticket e quando è possibile aspettarsi che il ticket venga risolto/sia pronto.

Come creare un biglietto?

Il modo migliore per inviare un ticket è tramite il nostro portale di assistenza. Ti chiederemo tutte le informazioni rilevanti e, grazie alle diverse categorie, saremo in grado di inoltrare il tuo ticket alla persona interessata. Questo ci fa risparmiare tempo per elaborare la tua e-mail e tu hai una risposta più rapida. Il link al portale di assistenza è:

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

Mancia: Hai più domande, miglioramenti o altre richieste di servizio? Invece di creare una lunga e-mail, crea ticket separati. Così non dovremo analizzare l'intera e-mail e separarla in ticket di servizio, bug o funzionalità.

Biglietti speciali

Fare

Ogni richiesta di funzionalità inizia con questo stato. Queste sono funzionalità che devono essere prioritarie. La priorità delle funzionalità verrà assegnata da uno degli sviluppatori

In fase di valutazione

Include richieste che pensiamo aggiungeranno un valore significativo al cliente e che sono adatte alla nostra roadmap. Quando una richiesta di funzionalità è in fase di valutazione, è molto probabile che la forniremo nel prossimo futuro. Ti terremo informato e ti forniremo un aggiornamento entro pochi mesi dalla tua richiesta. 

Considerazione futura

Include richieste che potrebbero essere aggiunte alla nostra tabella di marcia a lungo termine. Una volta all'anno, riconsidereremo la richiesta e ne modificheremo lo stato, se necessario.

Non essere considerato

Include richieste che non siamo in grado di implementare. Sebbene apprezziamo i potenziali vantaggi di tutte le richieste, purtroppo non possiamo implementare tutti gli eccellenti suggerimenti dei nostri clienti. Non lavoreremo su richieste in questo stato, ma le esamineremo dopo un anno e prenderemo in considerazione la possibilità di modificarne lo stato. Comprendiamo che potrebbe essere deludente vedere un suggerimento che ti appassiona chiuso o classificato come non preso in considerazione. Tuttavia, crediamo di dover ai nostri clienti una maggiore trasparenza nelle richieste di funzionalità e crediamo che questo flusso di lavoro ci aiuterà a raggiungere il nostro obiettivo.

Per verificare

Quando raggiunge questo stato è stato completato dall'assegnatario. Deve essere verificato dal reporter. In genere questo avviene nell'ambiente di staging. 

Fatto

La funzionalità è completata e verificata.

Biglietti per bug

Come ogni azienda di software abbiamo un arretrato con tutti i bug noti. Abbiamo 3 livelli di bug e descriveremo come creare ticket per i bug.

Flusso di lavoro dei bug

Il flusso di lavoro dei bug contiene diversi stati del bug. 

Fare

Ogni segnalazione di bug inizia nello stato 'To Do'. Questi sono bug che devono essere prioritari. La priorità dei bug sarà assegnata a Roel o Arjen. 

Arretrati a breve termine

Quando si trova in questo stato, significa che lo riprenderemo nel breve termine. Tuttavia, questa non è una garanzia: a breve termine, in generale, significa entro i prossimi 3 mesi. 

Arretrati a lungo termine

I bug che sono molto complessi da risolvere o hanno un impatto molto basso sull'utente hanno questo stato. Esempio di bug molto complessi: un bug che può essere risolto solo con una modifica importante del software o una modifica dell'infrastruttura. 

In corso

Stiamo attualmente lavorando su questo bug. 

Per verificare

Quando raggiunge questo stato è stato completato dall'assegnatario. Deve essere verificato dal reporter. In genere questo avviene nell'ambiente di staging. 

Fatto

Il bug è stato risolto e verificato.

Quando sarà pronta la mia richiesta?

È una delle domande più frequenti. Quando si fa? Una domanda semplice con una risposta complicata. Quindi cosa possiamo dire a riguardo? 

Quando è allegata una versione ampia come 2025 Dopo la stagione fornisce un'indicazione di quando una certa funzionalità/bug sarà pronta. Questa è un'indicazione, non una promessa. 

Quando il ticket ha una versione di rilascio, puoi restringere ulteriormente il campo. Se la versione corrente è Backoffice 3.22.1 e la versione di rilascio del biglietto è Backoffice 3.23.1 si può tranquillamente affermare che sarà disponibile entro il mese prossimo. 

Se è un critico bug verrà risolto il prima possibile. Piuttosto ore che giorni... 

Se il bug è nel arretrati a breve termine l'indicazione è da qualche parte nei prossimi 3 mesi. 

A volte c'è un scadenza specificato con un ticket. Se ce n'è uno, questo è ciò che puoi comunicare.