Nossa equipe de suporte usa tickets para categorizar perguntas sobre serviço, recurso e bug. Você pode acompanhar esses tickets por meio da seguinte url:

https://app.camping.care/support

Neste artigo, queremos explicar o significado dos diferentes status dos tickets, como você pode criar um ticket e quando você pode esperar que seu ticket seja resolvido/pronto.

Como criar um ticket?

A melhor maneira de enviar um ticket é por meio do nosso portal de serviços. Pediremos todas as informações relevantes e, devido às diferentes categorias, podemos encaminhar seu ticket para a pessoa relevante. Isso nos poupa de processar seu e-mail e você obtém uma resposta mais rápida. O link para o portal de serviços é:

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

Dica: Você tem várias perguntas, melhorias ou outras solicitações de serviço? Em vez de criar um e-mail longo, crie tickets separados. Então não precisamos analisar todo o seu e-mail e separá-lo em tickets de serviço, bug ou recurso.

Bilhetes de destaque

Pendência

Cada solicitação de recurso começa com este status. Esses são recursos que precisam ser priorizados. A priorização de recursos será feita por um dos desenvolvedores

Em consideração

Inclui solicitações que achamos que agregarão valor significativo ao cliente e são um ajuste forte para nosso roteiro. Quando uma solicitação de recurso está sob consideração, há uma grande probabilidade de entregarmos o recurso em um futuro próximo. Manteremos você informado e forneceremos uma atualização dentro de alguns meses após sua solicitação. 

Consideração futura

Inclui solicitações que podem ser adições ao nosso roteiro de longo prazo. Uma vez por ano, reconsideraremos a solicitação e alteraremos o status, se necessário.

Não sendo considerado

Inclui solicitações que não conseguimos implementar. Embora apreciemos os benefícios potenciais de todas as solicitações, infelizmente não podemos implementar todas as excelentes sugestões que nossos clientes fazem. Não trabalharemos em solicitações neste status, mas as revisaremos após um ano e consideraremos alterar o status. Entendemos que pode ser decepcionante ver uma sugestão pela qual você se sente apaixonado ser encerrada ou triada para não ser considerada. No entanto, acreditamos que devemos aos nossos clientes maior transparência em solicitações de recursos e acreditamos que esse fluxo de trabalho nos ajudará a atingir nossa meta.

Para verificar

Quando atinge esse status, ele foi concluído pelo cessionário. Ele precisa ser verificado pelo relator. Em geral, isso acontece no ambiente de preparação. 

Feito

O recurso está concluído e verificado.

Bilhetes de insetos

Como toda empresa de software, temos um backlog com todos os bugs conhecidos. Temos 3 níveis de bugs e descreveremos como criar tickets para bugs.

Fluxo de trabalho de bug

O fluxo de trabalho do bug contém diferentes status do bug. 

Pendência

Cada relatório de bug começa no status 'To Do'. Esses são bugs que precisam ser priorizados. A priorização de bugs será feita por Roel ou Arjen. 

Backlog de curto prazo

Quando está nesse status, significa que o pegaremos no curto prazo. No entanto, isso não é uma garantia, curto prazo significa em geral: dentro dos próximos 3 meses. 

Atraso de longo prazo

Bugs que são muito complexos de resolver ou têm um impacto muito baixo no usuário têm esse status. Exemplo de bugs muito complexos: Um bug que só pode ser resolvido com uma grande mudança de software ou uma mudança na infraestrutura. 

Em andamento

Estamos trabalhando neste bug. 

Para verificar

Quando atinge esse status, ele foi concluído pelo cessionário. Ele precisa ser verificado pelo relator. Em geral, isso acontece no ambiente de preparação. 

Feito

O bug foi corrigido e verificado.

Quando meu pedido estará pronto?

É uma das perguntas mais feitas. Quando é feito? Uma pergunta simples com uma resposta complicada. Então, o que podemos dizer sobre isso? 

Quando há uma versão ampla anexada como 2025 Depois da Temporada dá uma indicação de quando um certo recurso/bug estará pronto. Isso é uma indicação, não uma promessa. 

Quando o ticket tem uma versão de lançamento, você pode restringi-lo mais. Se a versão atual for Backoffice 3.22.1 e a versão de lançamento do bilhete é Backoffice 3.23.1 você pode dizer com segurança que estará disponível no próximo mês. 

Se for um crítico bug será resolvido o mais rápido possível. Em vez de horas do que dias… 

Se o bug estiver no pendências de curto prazo a indicação é em algum lugar nos próximos 3 meses. 

Às vezes há um data de vencimento especificado com um ticket. Se houver um, é isso que você pode comunicar.