Pedir ayuda al equipo de Runia

Cuando algo no funciona como esperás, tenés una duda concreta, querés pedir un cambio, o un cliente final tuyo te pasó un problema que necesita que lo veamos del lado de Runia, abrís un ticket de soporte desde el panel. El equipo lo recibe, lo resuelve, y vos vas viendo el estado en la misma pantalla, sin tener que mandar emails ni escribirle a nadie por WhatsApp.

Dónde está

En el sidebar, sección Soporte → Soporte.

Ahí ves la lista de todos los tickets que abriste, con su estado actual. Si todavía no abriste ninguno, te aparece un botón grande + Abrir mi primer ticket. Si ya abriste, el botón pasa a la esquina superior derecha como + Nuevo ticket.

Abrir un ticket

Tocás + Nuevo ticket y se abre un formulario con tres campos.

Categoría

Cinco opciones:

• Pregunta: tenés una duda sobre cómo funciona algo. "¿Cómo configuro X?", "¿Esto es un bug o lo estoy usando mal?".
• Bug: algo no anda. "El simulador no me devuelve respuesta cuando el agente usa la tool X".
• Pedido de feature: querés algo que hoy no está. "Estaría bueno poder filtrar contactos por fecha de último mensaje".
• Problema con cliente: un cliente final tuyo (la empresa que estás implementando) tiene un problema y querés que lo veamos. "A Fudy se le cayeron las plantillas, dice que no le llegan las respuestas a clientes".
• Otro: para todo lo que no entra arriba.

Elegir bien la categoría ayuda al equipo a priorizar. Un bug que rompe producción se ve antes que una pregunta general.

Título

Una línea que resuma de qué se trata. El placeholder dice "Resumí el problema en una línea" y eso es exactamente lo que conviene.

Buenos títulos:

• "Bug: el agente no responde después de un audio"
• "Pregunta: cómo conectar dos canales al mismo canvas"
• "Cliente Fudy: las campañas quedan en estado 'queuing' y no salen"

Malos títulos:

• "hola"
• "problema"
• "no anda"

Pensalo como el subject de un mail al equipo. Si lo lee solo, ¿se entiende qué pasa?

Descripción

Acá va el detalle. Cuanto más claro, más rápido se resuelve. El placeholder ya te orienta:

"Qué pasa, qué esperabas, pasos para reproducir, links o capturas si tenés."

Para un bug, lo más útil:

1. Qué hiciste (pasos exactos para reproducir).
2. Qué pasó (lo que viste).
3. Qué esperabas que pase.
4. Cuándo empezó (siempre fue así o de un momento a otro dejó de funcionar).
5. Si afecta a un cliente específico, mencioná cuál.
6. Capturas o links si tenés. Por ejemplo, link al canvas en cuestión, captura del error, ID de un mensaje específico.

Para una pregunta:

• Qué querés lograr (el objetivo, no solo el cómo).
• Qué probaste hasta ahora.
• Dónde te trabaste.

Para un pedido de feature:

• Qué problema te resolvería.
• Cómo lo estás resolviendo hoy (workaround).
• Cuántos clientes tuyos lo necesitan (ayuda a priorizar).

Tocás Crear ticket y queda registrado.

Estados de un ticket

A medida que el equipo lo trabaja, el ticket cambia de estado:

• Abierto: lo recibimos, todavía no lo asignamos a nadie.
• En progreso: alguien del equipo lo está trabajando.
• Resuelto: el equipo cree que está resuelto. Si no estás de acuerdo, contestá en el ticket y vuelve a Abierto.
• Cerrado: confirmaste que se resolvió, o pasó tiempo suficiente sin novedades.

Vas a ver el estado actual al lado del título de cada ticket en la lista.

Buenas prácticas

• Un problema por ticket. No mezclés "el agente no responde" con "y de paso, ¿se puede agregar X feature?". Abrí dos tickets separados, así cada uno avanza por su lado.
• Reportá rápido. Si algo se rompió, abrir el ticket apenas lo notás vale más que esperar a tener "todo el detalle". Mientras lo escribís, el equipo ya está al tanto. Después podés sumar info en la conversación del ticket.
• No abras tickets para cosas que un cliente final puede resolver solo. Si tu cliente te pregunta cómo conectar un número de WhatsApp y la respuesta está en la doc, mandale el link de la doc. Los tickets son para cosas que requieren intervención del equipo de Runia.
• Adjuntá contexto del cliente. Si el ticket es por un cliente específico, decí cuál (nombre o ID de empresa). Sin ese dato, el equipo tiene que preguntártelo y se demora.
• No cerrés un ticket abierto por silencio. Si pasaron días sin novedades, contestá el ticket pidiendo update en lugar de abrir uno nuevo. El equipo necesita continuidad para no perder el hilo.

Casos donde un ticket NO es la vía

• Caída total de producción: si el panel está abajo o algo crítico está roto para muchos clientes a la vez, el ticket llega pero capaz nosotros ya estamos trabajando en eso. Avisanos también por el canal de comunicación directo del partner.
• Decisión comercial: precios, descuentos, condiciones del contrato. Eso va por el contacto comercial, no por soporte técnico.
• Pregunta cubierta en la doc: antes de abrir un ticket de "cómo X", buscá en docs.runia.ar. Si la respuesta no está, abrí el ticket; eso también nos ayuda a saber qué falta documentar.