wiki/Soporte y fiabilidad/Tickets de soporte y adjuntos: dele pistas a soporte, no una novela
01Soporte y fiabilidadLectura mínima 2

Tickets de soporte y adjuntos: dele pistas a soporte, no una novela

Cómo los tickets del tenant, los tickets creados por la plataforma, las respuestas y los adjuntos mantienen el diagnóstico pegado a la organización correcta.

El soporte funciona mejor cuando el problema llega con contexto. “Está roto” es emocionalmente honesto, pero operativamente poco generoso. Los tickets de soporte de ReVend OS mantienen ruta, tenant, solicitante, estado, respuestas y adjuntos en un mismo sitio.

Tickets del tenant

/support permite a los usuarios del tenant abrir y seguir sus propios tickets. Un ticket nuevo lleva un asunto, una categoría —Pregunta general, Facturación, Informe de error, Solicitud de función, Cuenta / iniciar sesión u Otro—, una prioridad de Bajo, Normal o Alto, y una descripción en Markdown para pasos, IDs y mensajes de error. Urgente no está en el menú del tenant: es una prioridad de escalado del operador, que fija la gente que puede actuar sobre ella. Una vez creado, el ticket recibe un número TIC-YYYY-NNNNN y arranca en Abierto. Las respuestas mantienen la conversación en el registro en vez de repartir la solución entre buzones, capturas y un mensaje heroico de Slack que luego nadie encuentra.

Adjuntos

Los tickets nuevos y las respuestas tienen un clip. Los archivos van a un área de almacenamiento privada ticket-attachments, nunca a un bucket público, con un límite de 25 MB por adjunto y cinco adjuntos por mensaje. El mensaje se guarda primero y los archivos suben después, así que una subida fallida deja el mensaje en pie con aviso para reintentar, en vez de comerse la respuesta entera. Abrir un adjunto crea un enlace de descarga firmado de vida corta, y la descarga se registra como acceso a documento: los archivos de soporte llevan facturas, capturas y seriales, y nada de eso debería acabar decorando el pasillo.

Tickets creados por la plataforma

Los propietarios y el personal de plataforma pueden abrir un caso para un tenant con “Nuevo ticket de cliente” en /admin/support: se elige una organización activa, el correo de quien lo solicita y su nombre opcional, asunto, categoría, prioridad y descripción. Los objetivos de SLA siguen a la prioridad, exactamente igual que en un ticket abierto por el tenant. Eso permite a soporte abrir un caso después de una llamada o de una sesión de onboarding sin suplantar a nadie, y el audit trail deja claro que lo empezó la plataforma. Cuando soporte abre un ticket mientras la plataforma tiene puntos de atención activos, se le puede adjuntar automáticamente una nota interna de salud de plataforma y refrescarla desde el detalle del ticket: interna, y nunca con secretos ni payloads en crudo de proveedores.

Buenos tickets

Un buen ticket dice qué pasó, dónde pasó, qué se esperaba y si bloquea el trabajo. Una captura puede ayudar. Doce capturas sin la ruta pueden convertirse en un folioscopio de confusión.