Nuestro equipo de soporte utiliza tickets para clasificar preguntas sobre servicios, funciones y errores. Puede seguir esos tickets a través de la siguiente URL:

https://app.camping.care/support

En este artículo queremos explicar el significado de los diferentes estados de los tickets, cómo puedes crear un ticket y cuándo puedes esperar que tu ticket esté resuelto/listo.

¿Cómo crear un ticket?

La mejor manera de enviar un ticket es a través de nuestro portal de servicio. Le solicitaremos toda la información relevante y, debido a las diferentes categorías, podremos enviar su ticket a la persona correspondiente. Esto nos ahorra el tiempo de procesar su correo electrónico y usted recibe una respuesta más rápida. El enlace al portal de servicio es:

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

Consejo: ¿Tiene varias preguntas, mejoras u otras solicitudes de servicio? En lugar de crear un único y extenso correo electrónico, cree tickets separados. De esta manera, no tendremos que analizar todo el correo electrónico y dividirlo en tickets de servicio, de error o de función.

Entradas destacadas

Hacer

Cada solicitud de función comienza con este estado. Se trata de funciones que deben priorizarse. La priorización de funciones la realizará uno de los desarrolladores.

Está siendo considerado

Incluye solicitudes que creemos que agregarán un valor significativo al cliente y que se adaptan perfectamente a nuestra hoja de ruta. Cuando se está considerando una solicitud de función, existe una gran probabilidad de que la implementemos en un futuro cercano. Lo mantendremos informado y le brindaremos una actualización dentro de unos meses de su solicitud. 

Consideración futura

Incluye solicitudes que podrían ser agregadas a nuestra hoja de ruta a largo plazo. Una vez al año, reconsideraremos la solicitud y modificaremos el estado si es necesario.

No siendo considerado

Incluye las solicitudes que no podemos implementar. Si bien valoramos los posibles beneficios de todas las solicitudes, lamentablemente no podemos implementar todas las excelentes sugerencias que hacen nuestros clientes. No trabajaremos en solicitudes en este estado, pero las revisaremos después de un año y consideraremos modificar el estado. Entendemos que puede ser decepcionante ver que una sugerencia que le apasiona se cierra o se descarta. Sin embargo, creemos que debemos a nuestros clientes una mayor transparencia en las solicitudes de funciones y creemos que este flujo de trabajo nos ayudará a lograr nuestro objetivo.

Para verificar

Cuando alcanza este estado, el asignado lo ha completado. El notificador debe verificarlo. En general, esto sucede en el entorno de prueba. 

Hecho

La función está completa y verificada.

Tickets de errores

Como todas las empresas de software, tenemos una lista de errores conocidos. Tenemos tres niveles de errores y describiremos cómo crear tickets para errores.

Flujo de trabajo de errores

El flujo de trabajo de errores contiene diferentes estados del error. 

Hacer

Todos los informes de errores comienzan con el estado "Por hacer". Se trata de errores que deben priorizarse. La priorización de errores la realizará Roel o Arjen. 

Atraso a corto plazo

Cuando está en ese estado significa que lo retomamos en el corto plazo. Sin embargo esto no es una garantía, corto plazo significa en general: dentro de los próximos 3 meses. 

Atraso a largo plazo

Los errores que son muy complejos de resolver o que tienen un impacto muy bajo en el usuario tienen este estado. Ejemplo de errores muy complejos: Un error que solo se puede resolver con un cambio importante de software o un cambio en la infraestructura. 

En curso

Actualmente estamos trabajando en este error. 

Para verificar

Cuando alcanza este estado, el asignado lo ha completado. El notificador debe verificarlo. En general, esto sucede en el entorno de prueba. 

Hecho

El error está corregido y verificado.

¿Cuando estará lista mi solicitud?

Es una de las preguntas más frecuentes: ¿cuándo se hace? Una pregunta sencilla con una respuesta complicada. ¿Qué podemos decir al respecto? 

Cuando hay una versión amplia adjunta como 2025 Después de la temporada Da una indicación de cuándo estará lista una determinada característica o error. Es una indicación, no una promesa. 

Cuando el ticket tiene una versión de lanzamiento, puede limitarlo más. Si la versión actual es Oficina administrativa 3.22.1 y la versión de lanzamiento del billete es Oficina administrativa 3.23.1 Se puede decir con seguridad que estará disponible dentro del próximo mes. 

Si es un crítico El error se solucionará lo antes posible. En lugar de días, en cuestión de horas… 

Si el error está en el atraso a corto plazo La indicación está en algún momento de los próximos 3 meses. 

A veces hay una fecha de vencimiento Se especifica con un ticket. Si lo hay, esto es lo que puedes comunicar.