# Escalar y desescalar con un sistema de tickets
**URL:** https://meta.discourse.org/t/escalating-and-deescalating-w-a-ticket-system/129661
**Category:** Community Building
**Created:** [27 Septiembre, 2019 13:25 UTC](https://meta.discourse.org/t/escalating-and-deescalating-w-a-ticket-system/129661 "2019-09-27T13:25:47Z")
**Posts on this page:** 2
**Page:** 1
### Author:  [@Daquantics](https://meta.discourse.org/u/Daquantics)
#### Post date: [27 Septiembre, 2019 13:25 UTC](https://meta.discourse.org/t/escalating-and-deescalating-w-a-ticket-system/129661/1 "2019-09-27T13:25:47Z")
Durante los últimos años, hemos gestionado todo nuestro soporte en Discourse, excepto la facturación, que se realiza por correo electrónico. Ha sido un gran éxito para nosotros, y los clientes suelen ayudarse mutuamente sin la intervención de nuestro personal, que solo interviene cuando se necesita una resolución más profunda de problemas, para ocultar temas sensibles, etc.
Sin embargo, a medida que nuestra empresa ha crecido, estamos considerando una estrategia más amplia para la gestión de relaciones con clientes (CRM), principalmente para agilizar cómo nos comunicamos con el mundo exterior en otras áreas de la empresa. Para el soporte, estamos pensando en adoptar un modelo donde la atención inicial se realice en Discourse, pero los problemas técnicos más complejos y el seguimiento prolongado puedan escalarse a un sistema de tickets como Zendesk.
El complemento de Zendesk parece que nos ayudará con ese proceso de escalado, pero a veces los problemas de soporte siguen llegando por el método incorrecto, ya sea por correo electrónico, formulario de contacto del sitio web, mensajes de Facebook, etc.
Por lo tanto, lo que realmente necesitamos es una forma de _desescalar_ los problemas que llegan a Zendesk y devolverlos a Discourse.
Mi preferencia sería que estos casos se reenvíen a una bandeja de entrada del personal en la Comunidad, quienes puedan explicar a los usuarios cómo gestionamos el soporte y confirmar antes de hacer pública la pregunta. No estoy convencido de que podamos hacerlo de manera fluida, pero me gustaría asegurar que el soporte se realice en el lugar adecuado siempre que sea posible. Nuestra comunidad es lo suficientemente activa como para que muchas preguntas de “cómo hacer” reciban excelentes respuestas de otros usuarios si logro transferirlas de manera eficiente.
¡Cualquier idea sobre cómo lograr esto es bienvenido!
---
### Author:  [@tobiaseigen](https://meta.discourse.org/u/tobiaseigen)
#### Post date: [27 Septiembre, 2019 17:15 UTC](https://meta.discourse.org/t/escalating-and-deescalating-w-a-ticket-system/129661/2 "2019-09-27T17:15:05Z")
¿Ya has echado un vistazo a [Tickets Plugin 🎟](https://meta.discourse.org/t/tickets-plugin/97914?u=tobiaseigen)? Utilizo Discourse como sistema de tickets y, en esencia, es bastante sólido y se integra bien con la funcionalidad central de Discourse, como etiquetas, asignaciones y mensajería. Aún es necesario crear un panel de control funcional para supervisar la resolución de tickets y asegurarse de que nada se olvide.
Más información aquí:
> [@Using discourse as ticket system, so no balls are dropped woman\_juggling](https://meta.discourse.org/t/using-discourse-as-ticket-system-so-no-balls-are-dropped-woman-juggling/82698?u=tobiaseigen):
>
> I know there are other topics here floating around about using discourse as a ticket system, but I thought I’d start a fresh one to give a fairly complete picture of how we think discourse can be used with the current functionality, known issues, and what fixes/new functionality might help. This might also be faq material. Would be psyched to discuss with others trying to do the same thing and any workarounds you’ve found that I am missing so far. Also quite pleased to discover a whole genre of…