Our support team uses tickets to categorise service, feature and bug questions. You can follow those tickets via the following url:

https://app.camping.care/support

In this article we want to explain the meaning of the different ticket statusses, how you can create a ticket and when you can expect your ticket to be solved/ ready.

How to create a ticket?

The best way to submit a ticket is via our service portal. We will ask you for all the relevant information and due to the different categories we are able to route your ticket to the relevant person. This saves us to to process your e-mail and you got a faster answer. The link to the service portal is:

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

Tip: Do you have multiple questions, improvements or other service requests? Instead of creating one long e-mail. Create separate tickets. Then we don’t have to analyse your whole e-mail and separate it in service, bug or feature tickets.

Feature tickets

Todo

Every feature request starts with this status. These are features that need to be prioritized. Prioritization of features will be done by one of the developers

Under consideration

Includes requests we think will add significant customer value and are a strong fit for our roadmap. When a feature request is under consideration, there’s a high likelihood we will deliver the feature in the near future. We’ll keep you in the loop and provide an update within a few months of your request. 

Future consideration

Includes requests that could be additions to our longer-term roadmap. Once a year, we’ll reconsider the request and alter the status if needed.

Not being considered

Includes requests that we are unable to implement. While we appreciate the potential benefits of all requests, we unfortunately cannot implement all of the excellent suggestions our customers make. We won’t work on requests in this status, but we will review them after one year and consider altering the status. We understand it may be disappointing to see a suggestion you feel passionately about either closed or triaged into not being considered. However, we believe that we owe our customers greater transparency into feature requests, and we believe this workflow will help us accomplish our goal.

To verify

When it reaches this status it has been completed by the assignee. It needs to be verified by the reporter. In general this happens in the staging environment. 

Done

The feature is completed and verified.

Bug tickets

As every software company we have a backlog with all known bugs. We have 3 levels of bugs and we will describe how to create tickets for bugs.

Bug workflow

The bug workflow contains different statuses of the bug. 

To do

Every bug report starts in the ‘To Do’ status. These are bugs that need to be prioritized. Prioritization of bugs will be done by Roel or Arjen. 

Short term backlog

When it is in this status, it means that we pick it up in the short term.. However this is not a guarantee, short term means in general: within the next 3 months. 

Long term backlog

Bugs that are very complex to solve or have a very low impact on the user have this status. Example of very complex bugs: A bug that only can be solved with a major software change or a change in infrastructure. 

In progress

We are currently working on this bug. 

To verify

When it reaches this status it has been completed by the assignee. It needs to be verified by the reporter. In general this happens in the staging environment. 

Done

The bug is fixed and verified.

When will my request be ready?

It’s one of the most asked questions.. When is it done? A simple question with a complicated answer. So what can we say about it? 

When there is a broad version attached like 2025 After Season it gives an indication of when a certain feature / bug will be ready. This is an indication, not a promise. 

When the ticket has a release version you are able to narrow it down more. If the current version is Backoffice 3.22.1 and the release version of the ticket is Backoffice 3.23.1 you can safely say that it will be available within the next month. 

If it is a critical bug it will be solved ASAP. Rather hours than days… 

If the bug is in the short term backlog the indication is somewhere in the next 3 months. 

Sometimes there is a due date specified with a ticket. If there is one, this is what you can communicate.