Soporte que resuelve antes de que tengas que preguntar

OhMySupport es una utilidad incluida en todas las empresas: aparece en la tarjeta de cada una con la etiqueta «Incluido» y sin precio. Al entrar por primera vez se crea tu espacio con calendario laboral, 4 políticas de SLA, un equipo con su cola, el árbol de categorías, 5 respuestas tipo, 4 automatizaciones y ~16 artículos de ayuda.

Razón social y NIF (salen en los correos), zona horaria, prefijo de numeración de tickets, retención de datos y la pregunta de la encuesta de satisfacción.

Por defecto, de lunes a viernes de 09:00 a 18:00 con los festivos nacionales. Añade los festivos de tu comunidad o de tu empresa: son los que deciden cuándo vence un ticket.

Los usuarios entran como solicitantes. Desde Equipo se les da rol (agente N1, N2, supervisor o administrador), equipo y capacidad máxima de tickets abiertos.

El árbol de categorías es el vocabulario que usa el triaje automático: si no refleja tu negocio, la clasificación será peor. Las reglas y macros sembradas son un punto de partida sensato.

Activa el portal si vas a atender a clientes externos y crea el primer enlace. Crea una clave de API solo si tienes integraciones que abrirán tickets.

El botón flota en la esquina inferior derecha. El atajo Alt+S (⌥S en Mac) lo abre y lo cierra desde cualquier pantalla; Escape también lo cierra.

Artículos relacionados con el módulo y la ruta actuales, incidencias conocidas en curso y novedades que aún no has leído. Es la pestaña que más tickets evita.

Al abrirla, el formulario llega con el módulo, la pantalla, la versión y los errores de consola ya puestos. Solo escribes qué pasaba y, si quieres, adjuntas la captura.

Tus tickets abiertos con su estado, la última respuesta y el aviso de si el equipo te está esperando a ti.

Artículo, pregunta frecuente, guía paso a paso, resolución de problemas, novedad e incidencia conocida. Cada uno se muestra de forma distinta al usuario: una guía, por ejemplo, se convierte en pasos numerados con su botón «Llévame ahí».

Los artículos públicos los ve el cliente en el portal y en el widget; los internos solo el equipo. Un procedimiento con datos internos debe ser interno siempre.

Cada paso puede declarar su pantalla de destino, y eso es lo que habilita el botón que lleva al usuario exactamente allí. Es la diferencia entre explicar y acompañar.

Combina tres cosas: coincidencia de términos y de sus raíces —así «ficho» encuentra «fichaje» y «olvido» encuentra «olvidado»—, tolerancia a erratas por similitud de trigramas («fichge» también llega) y peso del título, para que el artículo que se llama como tu problema gane al que solo lo menciona de pasada. Si además hay proveedor de embeddings, se suma la búsqueda semántica con pgvector.

Cuando algo se rompe para muchos, se publica una incidencia conocida: aparece en el widget de todos y evita decenas de tickets idénticos. Las novedades avisan de lo nuevo que afecta al usuario.

Si el asistente lo resuelve, no hay ticket: es el mejor resultado posible. Si no, ofrece un botón para abrirlo con toda la conversación ya adjunta como contexto.

El asunto en una línea; la descripción, con lo que esperabas y lo que pasó. No hace falta que sea perfecto: el triaje lo clasifica y un agente lo reescribe si conviene.

Dos preguntas sencillas: a cuánta gente afecta (impacto) y cuánto corre prisa (urgencia). La prioridad la calcula la matriz a partir de esas dos respuestas, nunca la elige el usuario ni la inventa el modelo.

El formulario ya trae la pantalla, el módulo y los errores de consola. Añade la captura con la pestaña de adjuntos o directamente desde el widget.

El ticket recibe su número, entra en la cola y dispara el triaje automático: categoría, prioridad, etiquetas y un resumen para el agente. Todo eso es editable por la persona que lo atienda.

Todo lo que no está cerrado ni esperando al cliente, ordenado por lo que corre más prisa. Filtra por equipo, cola, prioridad, categoría o agente. El reparto automático asigna por carga real (tickets abiertos frente a capacidad), no a ciegas.

A la izquierda, toda la conversación con sus adjuntos y su cronología. A la derecha, los datos: estado, prioridad, categoría, agente, participantes y relaciones con otros tickets.

Derivar exige motivo y deja el traspaso estructurado: qué has comprobado, qué has descartado y qué queda por hacer. Sin eso, el ticket rebota y el cliente lo nota.

La nota interna solo la ve el equipo; la respuesta la ve el cliente. La distinción está en el servidor: el cliente nunca recibe una nota interna, ni siquiera por error.

Si el mismo síntoma llega veinte veces, agrúpalos en una incidencia y contéstalos de una vez. Los tickets relacionados y los duplicados mantienen su trazabilidad individual.

Respuestas tipo con variables (número de ticket, nombre del cliente, nombre del agente…). Las que no se puedan resolver se avisan en el propio listado: preferimos que se vean a enviar un hueco en blanco.

No se simula una respuesta de IA ni se deja la burbuja en blanco: el asistente avisa de que no hay proveedor y responde con lo que sí ha encontrado en la base de conocimiento, artículo por artículo. Ojo al detalle: tener un modelo configurado no basta si falta la clave de API — el módulo lo comprueba antes de prometer un asistente que no podría contestar, y lo publica en /api/health como iaCredencial.

Con SOPORTE_IA_ENVIAR_CUERPO=0, el texto de los tickets no sale de la instalación: el asistente trabaja con la base de conocimiento y los datos de contexto. Para sectores con datos sensibles.

Solo se mandan al proveedor si alguien lo pide expresamente para una captura concreta, y queda registrado en el historial de IA.

Cada llamada deja fila con la acción, el modelo, la versión del prompt, los tokens, la latencia y las fuentes citadas. Cada vez que un humano corrige el triaje, queda la medida real de acierto.

Primera respuesta, siguiente respuesta y resolución. Se cumplen por separado: un ticket puede responder rápido y tardar en resolverse, y eso hay que poder verlo.

En esperando al cliente, esperando a un tercero y en propuesta de solución, el tiempo no corre. Si no, el SLA castigaría al equipo por la lentitud del cliente.

Cada umbral avisa una única vez y escala al nivel que diga la política. No hay tormenta de correos repitiendo lo mismo cada cinco minutos.

El calendario trabaja con zona horaria IANA y con los festivos que tú cargues. Un P1 abierto el viernes a las 17:50 con objetivo de 30 minutos vence el lunes a las 09:20, no el viernes a las 18:20.

Propuesta significa: «esto es lo que había y esto es lo que hice». Al pasar a propuesta, el reloj del SLA se detiene y el cliente recibe el aviso.

El cliente puede dar la solución por buena, responder que no funcionó, o simplemente cerrar el ticket. Cualquiera de las tres cosas es información útil, y las tres quedan registradas.

El cierre por el cliente es el camino principal y queda marcado como tal: en los informes se distingue del cierre por el equipo, y esa diferencia es la mejor medida de si el soporte sirve.

Dentro de los días configurados (14 por defecto), el cliente puede reabrir el mismo ticket conservando todo el contexto. Fuera de esa ventana, solo supervisores y administradores, y con motivo escrito.

Tras el cierre se envía una encuesta breve con la pregunta que hayas configurado. La respuesta alimenta los informes sin molestar a quien ya está contento.

Nombre, correo, PIN opcional, permisos y caducidad. Si lo dejas sin PIN, el enlace por sí solo da acceso: úsalo solo cuando el correo sea de confianza.

El token se guarda en claro precisamente para que puedas reenviarlo cuando el cliente pierda el correo. No es un descuido: es la función.

Y ver sus propios tickets. Nunca ve notas internas ni toca prioridad, categoría, asignación o estado interno: la restricción está en el servidor, no en la interfaz.

El acceso se revalida en cada petición, así que revocar invalida todas las sesiones abiertas sin esperar a que caduque el token.

Se evalúan en orden, en cascada, y cada aplicación queda registrada. Admite una prueba en seco contra un ticket real: evalúa la regla y te dice qué haría, sin tocar nada.

Plantillas con número de ticket, nombre del cliente y del agente. Las variables que no se puedan resolver se avisan antes de enviar.

El módulo indexa cada 15 minutos los artículos publicados cuyo texto ha cambiado. Publicar indexa; despublicar desindexa. Si no hay proveedor de embeddings, la búsqueda sigue funcionando en modo léxico.

Volumen y evolución, cumplimiento de SLA por prioridad y por agente, tiempo hasta la primera respuesta, reaperturas, satisfacción y los tickets que más se repiten. Es la lista de la compra de la próxima mejora.

Quién cambió qué configuración y cuándo, y la verificación de la cadena de integridad de cada ticket. Si algo no cuadra, se señala en rojo el eslabón exacto.

La clave se muestra una sola vez. Empieza por sup_test_ para probar sin miedo, y usa sup_live_ en producción. Cada clave lleva sus permisos (leer tickets, escribir tickets, escribir mensajes, ver consumo).

Listar y crear tickets, consultar y modificar un ticket, añadir mensajes y consultar el consumo. La descripción OpenAPI 3.1 está en /api/soporte/v1/openapi.

Idempotencia con la cabecera Idempotency-Key (24 horas): si tu sistema reintenta, no se duplica el ticket. Y paginación por cursor con has_more y next, para recorrer listados largos sin perder filas.

Un módulo puede abrir un ticket con x-internal-key y una referenciaExterna. Con dedupe activo, un worker que reintenta cada cinco minutos no genera 288 tickets al día.

Los eventos salen firmados con HMAC usando el secreto del endpoint y se reintentan con backoff. Por seguridad, los destinos internos están bloqueados salvo que se habiliten expresamente.

Pasado el plazo (3 años por defecto, nunca menos de 1), se destruyen los datos personales y se conserva la estadística y la prueba de que el hecho existió. El RGPD exige destruir los datos, no la prueba.

Si hay una reclamación o una inspección en marcha, se marca el ticket o el adjunto concreto y la purga se detiene mientras dure. Todo queda registrado.

Cada fichero guarda su hash. Si el contenido no cuadra con lo que se subió, se rechaza en lugar de servirse: preferimos un error visible a servir algo manipulado.