Central de tickets · la consola de atención

La Central de tickets es la consola donde tu equipo trabaja los casos: cola con vistas guardadas, conversación con el cliente en el centro y contexto con relojes de SLA e IA a la derecha. Aquí están también el correo de entrada, las macros, el enrutamiento, las automatizaciones, los incidentes, la base de conocimiento y las métricas del equipo.

La Central de tickets es la consola de atención de SellioCRM: un solo lugar para trabajar los casos en cola, desde el primer correo del cliente hasta la encuesta de satisfacción. Usa el mismo objeto Ticket del CRM, así que todo lo que ya anotas (asunto, empresa, contacto, categoría, canal) sigue valiendo y aparece en la vista 360º del cliente.

Ábrela desde el menú lateral, en el grupo Atención, en Central de tickets. El objeto Tickets sigue en el mismo grupo para quien prefiere el alta en formulario, el tablero por estado y las vistas de lista.

Diseño en tres paneles

La consola abre en tres paneles, pensada para quien atiende todo el día: a la izquierda las vistas y colas con contadores, en el centro la conversación con el cliente, a la derecha el contexto del caso. En el móvil el panel de vistas se convierte en un selector arriba de la lista, para no ocupar espacio.

La cola y las vistas guardadas

• La columna de la izquierda trae vistas listas con el número de casos en cada una: Abiertos, Sin asignar, Míos, Pendientes (esperando al cliente o a un tercero) y Resueltos hoy.
• Vistas guardadas: crea un filtro con nombre por estado, prioridad, asignación y grupo, por ejemplo Urgentes del equipo de soporte. Aparece en la lista con su propio contador.
• Encima de la cola están la búsqueda (por asunto o solicitante), el filtro de prioridad y la ordenación: más recientes, más antiguos, por prioridad o por plazo de SLA.
• Cada fila muestra el asunto, el solicitante, el estado, la prioridad, el responsable y el estado del SLA, con sellos de color para leerlo rápido.
• Acciones masivas: marca la casilla de arriba para seleccionar varios casos y aplicarles el estado o el responsable de una vez.

La consola del agente

Al abrir un caso, la conversación aparece en el centro en orden cronológico y las propiedades quedan a la derecha: solicitante, canal de entrada, etiquetas, estado, prioridad, categoría, responsable y grupo. Cambiar cualquier propiedad guarda al momento.

1. En el redactor, elige Respuesta al cliente para escribir algo que el cliente verá, o Nota interna para anotar algo visible solo para el equipo.
2. La nota interna aparece destacada en otro color, para no confundirla con lo que se le dijo al cliente.
3. Haz clic en Adjuntar para subir archivos junto con el mensaje (hasta 25 MB cada uno). En una respuesta pública, los enlaces de los adjuntos van también en el cuerpo del correo enviado al cliente.
4. Escribe y haz clic en Enviar (o Añadir nota).

• Número de caso: todo caso recibe un número secuencial por organización, con el formato #000123. Es inmutable, aparece en la cola, arriba en el caso y en el correo de respuesta.
• Línea de tiempo: la pestaña Línea de tiempo funde, en orden, los mensajes públicos e internos y los eventos de cambio (creación, estado, prioridad, responsable y otras propiedades).
• Menciones y seguidores: en una nota interna, usa Mencionar para llamar a un compañero. Recibe una notificación y pasa a seguir el caso. Cualquier persona puede seguirlo o dejar de seguirlo desde el panel de propiedades y recibe aviso en cada actualización.

Macros y variables

1. Haz clic en Gestionar macros para crear respuestas predefinidas con título y cuerpo.
2. De forma opcional, la macro define el estado y la prioridad que se aplicarán al usarla.
3. En el redactor, selecciona la macro en Aplicar macro: el cuerpo entra en el campo de respuesta y, si está configurado, se aplican el estado y la prioridad.

Las macros y las respuestas aceptan variables entre llaves dobles, que se rellenan en el envío: {{protocol}}, {{ticket_subject}}, {{requester_name}}, {{agent_name}} y {{org_name}}, entre otras. En Canales y enrutamiento defines una Firma de atención, que se añade a las respuestas públicas; la firma personal del agente, cuando existe, tiene prioridad.

SLA: plazos, pausa, horario y festivos

El estado del SLA aparece en la cola y en el caso: En plazo o SLA incumplido mientras está abierto, y Resuelto en plazo o Resuelto fuera de plazo una vez resuelto. A la derecha, los relojes de primera respuesta, próxima respuesta y resolución hacen la cuenta atrás y cambian de color: verde, amarillo cerca del plazo y rojo cuando vence. Al cambiar el estado a Resuelto o Cerrado, la fecha de resolución se sella de forma automática.

• Pausa automática: al mover el caso a Esperando al cliente o Esperando a un tercero, el reloj de resolución se pausa y aparece un sello SLA en pausa. Al volver a un estado activo, el reloj se reanuda. El tiempo en espera no cuenta contra tu objetivo ni en las métricas.
• Próxima respuesta: cada política puede tener un objetivo de próxima respuesta. El reloj empieza cuando el cliente responde y se reinicia con cada respuesta pública nueva del agente.
• Horario laboral: en la pestaña SLA y horario defines los días, las horas y el huso (indica un huso como America/Sao_Paulo para respetar el horario de verano). Desactiva la restricción para contar tiempo corrido (atención 24x7).
• Festivos: da de alta los festivos por fecha. Esos días se considera el horario cerrado y el plazo se empuja al siguiente día hábil.
• Políticas: cada política encaja por prioridad, grupo o categoría (en blanco significa cualquiera) y define objetivos en minutos hábiles. Se evalúan en el orden de la lista y vale la primera activa que encaje. Si no encaja ninguna política, valen las horas por prioridad de Configuración, Atención.
• Riesgo de incumplimiento: una barra estimada indica si el caso tiene un riesgo bajo, medio o alto de pasarse del plazo, con el motivo.

Correo de entrada: el correo se convierte en caso

1. Abre la Central de tickets y ve a la pestaña Canales y enrutamiento.
2. Haz clic en Generar dirección de soporte. El CRM muestra una dirección con el formato support+tu-codigo@dominio.
3. En tu proveedor de correo, reenvía el buzón de soporte a esa dirección.
4. Listo: los correos nuevos abren casos y las respuestas del cliente entran en la misma conversación.

El remitente se asocia a un Contacto por el correo; la primera vez el Contacto se crea, y el canal del caso queda como Correo. Toda respuesta enviada al cliente lleva el código del caso en el asunto, con el formato [#XXXXXXXX]. Cuando el cliente responde manteniendo el código, el mensaje entra en la misma conversación en lugar de abrir un caso nuevo; si el caso estaba resuelto o cerrado, se reabre.

Acuse de recibo automático: en Canales y enrutamiento, activa el Acuse de recibo y escribe el texto con las variables. Cuando un correo abre un caso nuevo, el solicitante recibe al instante el acuse con el número de caso. Nace desactivado.

Fusionar casos y conversaciones paralelas

Cuando el mismo asunto se convirtió en dos casos, abre el que quedará como principal y haz clic en Fusionar. Los mensajes del otro pasan al principal y este se cierra con un aviso que apunta a dónde fue a parar.

¿Necesitas hablar con un proveedor o con otro equipo sin que el cliente lo vea? Usa las Conversaciones paralelas, justo debajo de la conversación principal: indica un asunto y los participantes por correo, escribe el mensaje y el CRM lo envía. Todo queda anotado en el caso, separado de la conversación con el cliente.

Asignación automática y automatizaciones

En Canales y enrutamiento, define para cada equipo cómo se reparten los casos al entrar en el grupo: Rotación (alterna entre los agentes) o Por carga (primero el agente con menos casos abiertos). Déjalo en Desactivada para asignar siempre a mano.

En la pestaña Automatizaciones creas reglas del tipo cuando algo cambia, entonces actúa. Cada regla tiene un evento (el caso se crea, o una propiedad cambia), condiciones opcionales de estado, prioridad, categoría, grupo y responsable, y una o más acciones.

• Acciones: definir el estado, la prioridad o la categoría; asignar a un agente o a un grupo; aplicar una macro; notificar al responsable; notificar al grupo entero; enviar la encuesta de satisfacción.
• Las reglas se ejecutan en el momento exacto de la creación o del cambio, en cualquier lugar del CRM: consola, edición del registro o integración.
• Arrastra por el asa que hay a la izquierda del nombre para reordenarlas; se evalúan de arriba abajo.
• Automatizaciones por tiempo: se ejecutan solas cada cierto tiempo y actúan según el plazo, por ejemplo escalar un caso sin primera respuesta desde hace X horas hábiles, avisar cuando el plazo está a punto de vencer o cerrar los resueltos hace N días. Cada una actúa como mucho una vez por caso.
• Webhooks de salida: en Canales y enrutamiento, avisa a sistemas externos en cada evento del caso (creado, actualizado, resuelto, mensaje nuevo), enviándolo a una URL firmada o a los canales de mensajería ya conectados en el hub de Integraciones.

Inteligencia artificial del caso

Con la IA activa, el panel de la derecha analiza el caso y sugiere: categoría y urgencia, sentimiento del cliente con una nota de 0 a 100, resumen del historial, casos similares y artículos de la base de conocimiento. En el redactor, el botón Sugerir respuesta (IA) redacta un borrador a partir de la conversación, en el idioma de tu interfaz. La IA nunca le envía nada al cliente por su cuenta: tú revisas, editas y decides.

Base de conocimiento y centro de ayuda

Tu base de conocimiento alimenta un portal público de autoservicio con búsqueda por título, contenido y etiquetas. Al final de la página, el formulario de sigo necesitando ayuda sugiere artículos relacionados mientras la persona escribe (deflexión) y, si aun así hace falta, abre un caso directamente en tu CRM.

• En Marketing, Base de conocimiento, la pestaña Artículos permite escribir, editar y enviar a revisión; la pestaña Revisión es la cola de aprobación (Aprobar y publicar o Rechazar con motivo); la pestaña Importar crea un borrador a partir de una URL; la pestaña Feedback muestra los artículos más útiles y los que necesitan atención según los votos de los lectores.
• Cada guardado conserva un historial y puedes restaurar una versión anterior.
• Cada artículo tiene un idioma, y la búsqueda pública puede filtrar por el idioma del lector.
• En la pestaña SLA y horario armas los formularios de apertura del portal: además del nombre, el correo, el asunto y el mensaje, añade campos propios de texto, lista o correo, con visualización condicional. Marca uno como predeterminado para que lo use el centro de ayuda.

Incidentes y página de estado

1. Abre la pestaña Incidentes de la consola y crea un incidente con título y severidad.
2. Vincula los casos afectados por el mismo evento.
3. Publica actualizaciones en la línea de tiempo del incidente y comunícaselo a todos los afectados de una vez, por correo a los solicitantes de los casos vinculados.
4. Al resolverlo, anota la causa raíz y el post-mortem.
5. Márcalo como público para exponer una página de estado abierta a tus clientes.

Satisfacción y métricas

Al resolver o cerrar un caso, el CRM envía de forma automática una encuesta de satisfacción por correo al solicitante, con una nota de 1 a 5 y un comentario. Es una sola vez por caso. Cuando el cliente responde, la nota aparece en el bloque Satisfacción de la consola y se guarda en los campos del propio caso. Actívala o desactívala en Automatizaciones, Encuesta de satisfacción, y usa Reenviar encuesta cuando quieras volver a pedirla.

En la pestaña Métricas sigues el período de 7, 30 o 90 días: casos creados, resueltos y abiertos, tiempo medio de primera respuesta, tiempo medio de resolución, porcentaje dentro del SLA, satisfacción media con la tasa de respuesta, backlog, resolución en el primer contacto, tasa de reapertura y carga por equipo, con segmentación por canal y por categoría y una tabla por agente. Los indicadores muestran la variación respecto al período anterior y un minigráfico diario, y los informes se pueden exportar en PDF o XLSX.

Preguntas frecuentes

• El envío de la encuesta depende del correo del solicitante, del campo del caso o del Contacto vinculado, y de que el envío de correo esté configurado.
• Al exportar o anonimizar los datos de un titular en Configuración, Privacidad, el contenido de los mensajes y de las valoraciones de ese solicitante también se incluye o se anonimiza.
• Las integraciones con help desks externos crean casos en el CRM de forma automática; una vez creados, los trabajas aquí como cualquier otro.
• En la aplicación móvil también sigues la cola, abres un caso, respondes y cambias el estado.
• Para que el cliente siga por su cuenta sus propios casos, responda y los reabra, mira el artículo del portal del cliente.

Casos padre e hijo, reglas de respuesta automática y mapeo de canal

Un caso ahora puede depender de otro. Defines el padre en el caso y los hijos aparecen en una lista, con una guarda que rechaza bucles o cadenas demasiado profundas, y un aviso cuando intentas cerrar un padre que todavía tiene hijos abiertos. La respuesta automática pasó a ser **reglas** en vez de un texto fijo: cada regla tiene sus condiciones (canal, categoría, prioridad, horario comercial, solo el primer mensaje, palabras clave) y su mensaje, y gana la primera que coincide. La guarda anti-bucle no se puede desactivar, a propósito: responder a un buzón automático es como dos contestadores hablando para siempre. Y el canal del caso ahora viene de una **tabla de mapeo** que tú controlas, así el caso que llegó por teléfono a tu help desk deja de registrarse como "portal" y tus informes por canal dejan de mentir.

Dónde están: el padre y los hijos aparecen en el propio ticket, en el panel **Casos relacionados**. Las reglas están en **Configuración → Respuestas automáticas**, y el mapeo en **Configuración → Canales de ticket**; ambos son para quien administra la cuenta.

El ticket tiene una tercera pestaña, **Contexto**, y es ahí donde la consola dejó de mandarte a otra pantalla. Trae los campos del propio ticket (incluidos los que creaste), los registros relacionados, las actividades y tareas, los archivos, los casos padre e hijos, y los otros tickets abiertos del mismo cliente. Si diseñaste un Canvas para el objeto Ticket, ese diseño manda también aquí, así no dibujas lo mismo dos veces.

Cerrar un ticket con un código de resultado

Resolver un ticket era escribir texto libre en el campo Resolución. Eso describe lo que pasó, pero no lo clasifica: dos agentes escriben el mismo resultado de diez maneras, y nadie puede responder cuántos tickets del mes pasado fueron un defecto del producto y cuántos un error de configuración. El campo Categoría tampoco ayuda, porque clasifica el asunto cuando el ticket se abre, no el resultado cuando se cierra.

Por eso el resultado ahora es una lista corta que tú controlas, en **Configuración → Códigos de resultado**. Cada código tiene una etiqueta, un ámbito y una opción que define si elegirlo exige una explicación (usa esa opción en "Otro", que por sí solo no explica nada). La misma lista sirve para tickets y para llamadas telefónicas, así mantienes un solo vocabulario en vez de dos que dicen lo mismo.

1. Abre Configuración → Códigos de resultado y haz clic en Generar la lista por defecto, o escribe tu propia lista.
2. Activa "Exigir un resultado al resolver" si quieres que la regla se aplique.
3. En la consola, elige el resultado en el cuadro Cierre, a la derecha, antes de resolver el ticket.

Tres comportamientos que conviene conocer, porque son deliberados:

• **Activar la exigencia antes de tener códigos no bloquea nada.** De lo contrario congelaría todos los tickets de la empresa el día en que alguien marcara la casilla, sin nada disponible para elegir.
• **Quien exige es el servidor, no la pantalla.** Cerrar desde la lista, desde una macro, desde la API o desde la terminal pasa por la misma comprobación.
• **Un código que ya se usó no se puede eliminar, solo desactivar.** Eliminarlo quitaría el significado de cada ticket cerrado con él, y tus informes antiguos empezarían a mentir en silencio.

Texto rápido: frases listas detrás de un atajo que escribes

Hasta ahora el único texto listo de la consola era la macro, y la macro también aplica un estado y una prioridad: insertar una frase cambiaba el ticket sin que nadie lo pidiera. El texto rápido no escribe nada más que el texto. Por eso puede ser ligero, personal y alcanzable con un atajo que escribes.

1. En el compositor, escribe :: seguido del comienzo de un atajo, por ejemplo ::hi.
2. Sigue escribiendo para acotar la lista, o escribe solo :: para ver la biblioteca entera.
3. Elige una frase de la lista, o termina el atajo y confirma para insertar la que coincide exactamente.
4. Lee el texto antes de enviar: las variables entre llaves dobles, como {{protocol}}, {{ticket_subject}}, {{requester_name}}, {{agent_name}} y {{org_name}}, se completan al enviar la respuesta, igual que en las macros.

Hay tres bibliotecas: **personal** (solo la ves tú), **del equipo** (quien esté en ese equipo) y **de la empresa** (todo el que atiende). El mismo atajo puede existir en más de una, y gana la más cercana a ti: tu frase personal gana a la del equipo, y la del equipo gana a la de la empresa. Así mantienes tu versión de ::hi sin pedirle a nadie que cambie el estándar de la casa.

• **El atajo no lleva espacios ni dos puntos**, y admite hasta 40 caracteres. Un atajo con espacio nunca podría escribirse después de ::, así que se rechaza al guardar en vez de convertirse en una frase que jamás aparece.
• **El atajo es único dentro de su propia biblioteca.** El mismo ::hi puede existir como frase personal y como frase de la empresa; dos de la empresa no.
• **La búsqueda ignora mayúsculas y acentos** y mira el atajo, después el título, después la carpeta. El cuerpo nunca se busca: una palabra común coincidiría con media biblioteca y el atajo perdería su sentido.
• **El orden es siempre el mismo**: atajo que empieza por lo que escribiste, después atajo que lo contiene, después título, después carpeta. Una lista que cambiara de orden entre dos aperturas te haría elegir la frase equivocada por memoria muscular.
• **La carpeta es texto libre** y solo agrupa la biblioteca en pantalla. No hay un catálogo de categorías aparte que mantener.

Tus frases personales son tuyas para crear, editar y eliminar, sin pedir permiso a nadie. Las frases del equipo y de la empresa son estándar de la casa, porque cambian lo que todo el mundo enviará al cliente mañana, así que son de quien administra la configuración. Nadie edita la frase personal de otra persona, ni siquiera quien administra.

Correos del ticket: texto propio por evento, idioma, categoría y cola

Cinco momentos del ticket pueden llevar un texto tuyo: **abierto**, **actualizado**, **resuelto**, **encuesta** y **cierre**. Cada plantilla se escribe en un idioma y puede, si quieres, quedar restringida a una categoría, a una cola, o a las dos.

La elección sigue un orden declarado, y se lee mejor en dos mitades: el sistema decide primero **qué decir** y solo después **en qué idioma decirlo**. Las familias se visitan de la más específica a la más genérica: cola y categoría, después cola, después categoría, después la genérica. La cola pesa más que la categoría porque la cola es el equipo que responde y el texto es su voz; la categoría es solo el asunto.

• **Filtro vacío es comodín, filtro relleno tiene que coincidir.** Una plantilla sin categoría sirve para cualquier categoría. Una plantilla con categoría sirve solo para esa, y nunca hace de texto genérico.
• **Idioma, dentro de la familia elegida**: primero el exacto (pt-BR), después la misma lengua base (pt-PT sirve para pt-BR), después el idioma de reserva, que es el inglés mientras no digas otro.
• **La familia que no tiene ninguno de esos tres idiomas se salta**, y se intenta la siguiente, menos específica. Enviar el texto genérico en el idioma de quien lee es mejor que enviar el texto correcto en un idioma que esa persona no lee.
• **La especificidad va antes que el idioma.** Si la familia de Facturación solo existe en inglés y la genérica existe en portugués, quien escribe en portugués recibe el texto de Facturación en inglés. El arreglo es añadir la línea en portugués de la misma familia, que es justo lo que la tabla te pide.

El idioma que cuenta es el de **quien abrió el ticket**, la persona que lee el correo, no el del agente. Asunto y cuerpo aceptan las mismas variables que las macros y los textos rápidos, y la vista previa muestra qué plantilla ganó y en qué idioma antes de que salga nada.

Swarm: llamar gente a un caso difícil y dejar por escrito lo que salió de ahí

La sesión de swarm registra el ritual que hasta ahora vivía disperso en notas internas: a quién se llamó, en qué papel, para responder qué pregunta, hasta cuándo, y qué se concluyó. **Registra la sesión; no abre un canal de Slack ni inicia una videollamada.** La conversación sigue ocurriendo donde ya ocurre (nota interna, mención, seguidores, chat interno); lo que pasa a existir es su memoria.

1. En el ticket, abre un swarm y escribe el motivo. El plazo es opcional, y no puede estar en el pasado.
2. Quien abre la sesión es el **relator**, y pasa a seguir el ticket.
3. Llama a las personas que necesites como **especialista** (sin límite) o como **escribano** (asiento único). A quien es llamado le llega un aviso con el motivo y pasa a seguir el ticket.
4. Cierra la sesión con el **resultado**. Vuelve al ticket como nota interna, para que el siguiente agente que tome el caso lo lea sin abrir nada más.

• **Una sesión abierta por ticket.** Dos partirían la atención en dos, y el resultado no tendría una única casa.
• **Relator y escribano son asientos únicos mientras están ocupados**; especialista no tiene tope, porque llamar gente es justamente para lo que existe el swarm.
• **El relator no sale de la sesión.** La salida es cerrarla diciendo qué se concluyó, aunque sea 'no se concluyó nada'.
• **Cerrar exige el resultado**, y termina la participación de todos, para que los minutos de gente dejen de crecer solos.
• **Quien salió sigue apareciendo en el registro.** Quién participó tiene que seguir siendo verdad mañana.

Seguimiento programado y recordatorio personal

Dos acciones parecidas que no son lo mismo. El **seguimiento** es una tarea sobre el ticket: puede quedar en manos de otra persona y aparece en la lista del día como cualquier tarea. El **recordatorio** es siempre tuyo, y suena a la hora que pediste, no en el resumen del final del día.

1. En el ticket, elige Programar seguimiento o Recuérdamelo.
2. Escribe cuándo, con tus palabras: mañana 9h, en 2 horas, viernes, la próxima semana, o una fecha como 2026-09-10 14:30. Se entienden los diez idiomas del producto.
3. En el seguimiento, elige el tipo (tarea, llamada, correo o reunión) y, si quieres, la persona que se queda con él. El recordatorio siempre es tarea, y siempre tuyo.

• **Un día sin hora se convierte en las 09:00** en la zona horaria de la organización, el mismo valor por defecto que usa el resto del producto.
• **Una duración conserva la hora actual**, porque la duración ya la lleva dentro. Minutos y horas cuentan en tiempo real; días y semanas caminan por el calendario, así que el horario de verano no los mueve.
• **Una hora que ya pasó se va al día siguiente**, como hace cualquier aplicación de recordatorios. Un día en el pasado, en cambio, se rechaza en vez de adivinarse: adivinar qué día quisiste decir sería inventar.
• **Más allá de 365 días se rechaza.** Es el filtro del dedo equivocado, el 2027 escrito en 2026 que nadie llegaría a ver.

La pantalla repite la hora que realmente se **guardó**, y no las palabras que escribiste, siempre que se asumieron las 09:00 por ti o la hora se empujó al día siguiente. Dos respuestas distintas a 'cuándo vence esto' es justo la confusión que ese eco existe para evitar.

Pestañas de trabajo: varios casos abiertos a la vez

La consola abría un caso cada vez, y elegir otro sustituía al anterior. Quien atiende en volumen lleva tres o cuatro casos en marcha (uno esperando al cliente, uno esperando a ingeniería, uno que se está escribiendo), y cada cambio perdía el borrador y el punto del desplazamiento. La barra de pestañas de trabajo está encima de la conversación, y aparece en cuanto hay una segunda cosa abierta.

• **Un clic simple abre una pestaña de vista previa**, mostrada en cursiva, y la siguiente vista previa ocupa su lugar. Escribir en ella, o fijarla, la vuelve definitiva. Sin eso, recorrer una cola de veinte casos abriría veinte pestañas.
• **El mismo caso nunca se abre dos veces.** Volver a hacer clic solo activa la pestaña, con el borrador y la subpestaña que dejaste ahí.
• **El punto azul avisa de que hay una respuesta escrita y sin enviar** en esa pestaña. Es lo que necesitas ver antes de cerrarla, no después.
• **Cada pestaña recuerda su subpestaña** (Conversación, Cronología o Contexto), así vuelves donde estabas y no al principio.
• **Hasta ocho pestañas.** Por encima sale la pestaña más antigua sin borrador; si todas tienen borrador, el tope cede, porque perder trabajo escrito es peor que una barra larga.
• **Cerrar la pestaña activa activa la vecina de la derecha**, y la de la izquierda cuando no hay derecha, como hace un navegador.

**Cerrar las guardadas** cierra todas las pestañas sin borrador y conserva las que lo tienen: la limpieza nunca se lleva trabajo escrito por delante. Las pestañas viven en tu propio navegador, en este dispositivo, así que son tuyas y no del equipo.

Contexto del cliente: salud, valor, plan e historial de atención

La pestaña Contexto del caso abre con un bloque que responde, antes de que escribas una sola línea, si este cliente está bien, cuánto vale, en qué plan está y cuántas veces ya fue mal atendido. Nada de eso lo escribe una persona: todo se compone de lo que el producto ya guarda sobre esa cuenta.

• **Salud** muestra la nota y, más importante, **los factores que la forman**. El número solo no dice nada sobre lo que hacer; los factores dicen si el problema es uso, atención, dinero o relación.
• **Valor** trae los ingresos ganados, los ingresos recurrentes y el último movimiento, para que una expansión el mes pasado y una reducción el mes pasado no parezcan lo mismo.
• **Plan** dice qué plan, desde cuándo y cuándo renueva, y avisa cuando la renovación ya está marcada en riesgo.
• **Historial de atención** cuenta los casos anteriores, cuántos incumplieron el SLA, la satisfacción de este cliente y si hay un caso crítico abierto ahora.

Debajo del bloque, toda la conversación con ese contacto aparece en una sola línea, sea cual sea el canal: chat, SMS, WhatsApp, correo y casos juntos, en orden. Es el mismo historial que muestra la ficha del contacto, traído al consola para que nadie cambie de pantalla solo para recordar lo que ya se dijo.

Supervisión: la misma operación, vista por quien coordina

El console responde "¿qué hago ahora?" a quien atiende. La supervisión responde otra pregunta, para otra persona: si la operación está dando abasto en este momento. Es una pantalla aparte, hecha para quedar abierta en un televisor, y se actualiza sola.

• **¿La operación da abasto?** Elementos abiertos por cola, cuántos están sin responsable, cuántos esperan por nosotros y cuántos van a incumplir el plazo en la próxima hora. Saber qué va a incumplir no es lo mismo que saber qué ya incumplió, y el panel mantiene ambos separados.
• **¿Quién está sobrecargado y quién está libre?** Elementos abiertos por persona frente a su tope, quién salió de la rotación y quién lidera la cola.
• **¿Dónde está el cuello de botella?** La cola con más espera, el canal que más entrada trae, y la cola de la que nadie puede tomar nada, porque exige una habilidad que nadie del equipo tiene.
• **¿Qué pasó en la última hora?** El registro de asignación ya es solo de adición, así que el panel simplemente lo muestra.

La supervisión es para quien administra, y es deliberado: muestra la carga de cada persona y quién está fuera de la rotación. Monitorear personas es un acto de gestión declarado, no un efecto colateral de abrir una pantalla. El panel es de lectura, así que nada en él reasigna ni repriorizar: señala, y el trabajo se hace donde ya vive.

Catálogo de servicios: una vitrina en lugar del caso en blanco

Quien necesita algo interno hoy abre un caso vacío y escribe lo que recuerda. El catálogo cambia eso por una vitrina: una lista de lo que se puede pedir, cada elemento con su formulario, su cola y su prioridad. El pedido abre un caso de verdad, ya rellenado.

1. En Configuración, Catálogo de servicios, quien administra arma el catálogo: categorías, elementos y las preguntas de cada elemento.
2. Cualquier persona abre la misma pantalla, elige un servicio y rellena su formulario.
3. El sistema abre un caso en la cola del elemento, con su prioridad y las respuestas dentro, en el mismo formato que ya usa el portal.
4. Si el elemento exige aprobación, el caso se abre de inmediato y la aprobación pendiente bloquea su resolución: nadie lo cierra antes de que alguien decida.

• **Desactivar un elemento no cancela lo que ya se pidió.** Desactivar significa "no pidas más esto", nunca "cancela lo que está en curso": los casos abiertos siguen abiertos, con la misma cola y el mismo plazo.
• **Un elemento ya pedido no se puede eliminar, solo desactivar.** Eliminarlo haría que el historial mintiera sobre lo que se pidió.
• **El pedido congela una foto del formulario.** Si las preguntas cambian después, el pedido antiguo sigue mostrando las preguntas que esa persona realmente respondió.
• **El estado del pedido no es una copia.** Se lee de la propia aprobación en cada consulta, así que nunca se aparta de lo que el motor de aprobación decidió en otro lugar.

Catálogo de servicios · cumplimiento del pedido

Un elemento del catálogo puede tener un plan de cumplimiento: lo que tiene que pasar después de que alguien pide el servicio, y en qué orden. Cada paso se convierte en una **tarea de verdad**, con responsable, fecha límite, recordatorio y un lugar en la lista de tareas que la persona abre cada día, y la dependencia entre pasos es la misma que las tareas ya tienen. El plan se congela en el pedido cuando el cumplimiento **empieza**, no cuando se pide el servicio: editar el elemento después nunca reescribe un pedido en marcha, y la versión nueva vale desde el siguiente inicio.

Quien coordina el trabajo tiene la cola de cumplimiento: qué está pendiente, con quién y desde hace cuánto. El pedido aprobado que nadie ha iniciado aparece **arriba**, con su antigüedad a la vista, porque aprobar no inicia nada, alguien todavía tiene que poner el plan a rodar. El elemento que no espera aprobación empieza en cuanto se pide.

1. Diseñe el plan en el elemento del catálogo: asunto, tipo de tarea, plazo en días contados desde el inicio, quién la recibe y, cuando importe, el paso anterior del que depende.
2. Cuando alguien pide el servicio, el caso se abre como siempre. Si el elemento exige aprobación, el cumplimiento espera la decisión; si no hay aprobación que esperar, empieza de inmediato.
3. Al iniciar el cumplimiento, el plan se congela en el pedido y las tareas nacen en el orden de las dependencias, cada una con dueño y plazo.
4. El panel del pedido en el caso muestra cada paso, con quién está, el plazo y lo que ya se completó. Los pasos también aparecen en la línea de tiempo del caso, porque son tareas normales atadas a él.
5. Marque Entregado cuando el servicio llegó de verdad a la persona. Un paso obligatorio todavía abierto lo bloquea, con el motivo a la vista; un paso marcado como no obligatorio nunca bloquea.
6. ¿Lo marcó por error? Revierta la entrega con una nota. Eso es un asiento nuevo: la entrega anterior sigue en el historial, no se borra nada.

Activos del cliente · el caso trata de este equipo

El caso ahora apunta al **equipo** del cliente, la unidad instalada con su número de serie, y no solo al modelo de producto que se vendió. En el caso usted lo elige dentro de la base instalada del cliente, buscando por número de serie, que es como el cliente se identifica por teléfono. Solo entra equipo del cliente de ese caso, y a partir de ahí el historial del propio equipo cuenta la atención: casos vinculados, desvinculados y resueltos quedan en la misma línea de tiempo que la instalación, los traslados y los mantenimientos.

La parada la registran **personas**, o nace del propio caso. Aquí no hay telemetría ni señal de máquina, así que la disponibilidad, el MTTR y el MTBF valen exactamente lo que valga la disciplina de quien registra. La pantalla lo dice en voz alta en lugar de adornar el número.

• Garantía y cobertura: el sello de garantía (activa, por vencer, vencida) y el contrato de servicio aparecen antes de que usted abra la boca con el cliente.
• Ubicación: mover el equipo registra a dónde fue, así que el historial de ubicación es la lectura de esos movimientos y no un campo único que olvida el pasado.
• Reemplazo con linaje: reemplazar retira el antiguo y crea el nuevo heredando cuenta, contrato y ubicación, con un evento en cada lado apuntando al otro.
• Ciclo de vida: activo, en mantenimiento, en RMA, retirado y dado de baja. Lo dado de baja no vuelve, porque la baja es un hecho contable; el camino de vuelta es registrar un activo nuevo con el linaje del anterior.
• Parada: abrir y cerrar la parada, planificada o no. El mismo activo nunca está parado dos veces a la vez, y las paradas superpuestas se fusionan antes de sumarse, así la disponibilidad nunca queda negativa.
• Disponibilidad: el porcentaje en la ventana, con la parte planificada separada de la no planificada, porque una ventana de mantenimiento acordada con el cliente no es una promesa rota. El MTTR y el MTBF quedan vacíos sin muestra suficiente.
• Riesgo y próxima acción: criticidad, antigüedad, fallas repetidas, cobertura y disponibilidad medida suman una puntuación explicable, y el motor declara lo que tuvo que suponer por falta de dato.

Base de conocimiento · responsable, revisión y uso

La base ganó la capa que responde quién responde por cada artículo y si todavía merece confianza: un responsable, un revisor, un ciclo de revisión en días y, a partir de ellos, el artículo **vencido de revisión**. El cuadro de gobernanza es en vivo, se calcula al abrirlo, así que nunca depende de que el barrido nocturno haya corrido. Solo se le exige al artículo publicado: el borrador todavía se está escribiendo y el archivado salió de circulación.

La visibilidad dejó de ser solo publicado o no. Cada artículo tiene una audiencia: **externo** es lo que el centro de ayuda y el portal muestran a quien tiene el enlace, e **interno** nunca sale del CRM. Todo artículo nace externo, exactamente como se comportaba antes, así que nada cambia hasta que usted decida lo contrario.

• Responsable y revisor son personas de su equipo, definidas por artículo. Sin responsable, el artículo queda señalado en el cuadro, que es donde la falta de responsable se resuelve.
• Ciclo de revisión en días: la próxima revisión es la última revisión más el ciclo. Un artículo sin ciclo nunca vence, y nadie es perseguido por él.
• El aviso de revisión vencida va al **responsable** del artículo, una vez por vencimiento. El artículo sin responsable no avisa a nadie, porque volcar cada día la mitad sin dueño en la campana de quien administra enseña a la gente a ignorar la campana.
• Archivar saca el artículo de circulación con autor, fecha y rastro de auditoría, en vez de que alguien edite un campo de estado en silencio. Desarchivar lo devuelve a borrador, nunca directo al aire.
• Borrador por IA a partir de casos resueltos: elija hasta cinco casos cerrados, apunte a un vacío si quiere, y el asistente escribe un artículo reutilizable. **Nace siempre como borrador** y entra en la misma cola de revisión que cualquier artículo escrito a mano: la IA propone, la persona aprueba. Solo entra el caso resuelto, porque un caso abierto todavía no tiene respuesta.
• Lectura por artículo: cuántas visitas abrieron cada artículo, por qué puerta, y qué artículos publicados nadie leyó en el período, que es la parte de la base que no trabaja.

Autoservicio · el asistente y la tasa de desvío

La base de conocimiento pública ganó un asistente. Responde anclado **solo** en sus artículos publicados y muestra las fuentes que usó, para que quien lee una respuesta generada pueda comprobar de dónde salió. Cuando no encuentra nada lo dice y lleva al formulario de apertura, y la pregunta sin respuesta queda registrada como vacío de cobertura. Nunca llena el silencio con un paso inventado, y cuando no hay IA configurada muestra los artículos encontrados en lugar de fingir que está fuera de servicio.

Eso es lo que hace medible el desvío, y la definición es estricta a propósito: **un caso evitado es una declaración explícita** de quien iba camino de abrir un caso y desistió, después de recibir una respuesta o un artículo sugerido y hacer clic en que eso resolvió el problema. Nada más cuenta.

• Leer un artículo no cuenta. Quien lee puede estar comparando, investigando, o leyendo el artículo equivocado camino de abrir el caso igual.
• Buscar sin desenlace no cuenta. Cerrar la pestaña no es un éxito.
• El caso le gana a la declaración: si la persona dijo que se resolvió y abrió un caso en la misma visita, la visita cuenta como caso. Preferimos medir de menos.
• La visita que no decidió nada queda enteramente fuera de la tasa, ni arriba ni abajo, y se informa aparte como indecisa.
• La tasa es la parte de las visitas que **decidieron algo** y decidieron no abrir un caso. Sin ninguna decisión en el período la tasa queda vacía y nunca en 0%, porque no saber y cero por ciento son respuestas distintas.
• El embudo (búsquedas, preguntas, preguntas respondidas) mide alcance, no resultado, y nada de eso entra en la tasa.

Analítica de atención · informes listos, hallazgos y proyección

La pestaña Analítica de la consola de casos responde lo que ninguna pantalla respondía: desde hace cuánto está parada la cola, cuánto de cada hito prometido se cumplió, cuánto escaló, qué han estado haciendo la voz, el bot y la mensajería, cuánto costaron los incidentes en casos, hacia dónde va el volumen y, al final, qué hacer al respecto. Todo número llega ya calculado del servidor, así que no hay dos pantallas discrepando en silencio sobre la misma cuenta.

Dos lecturas que parecen la misma y no lo son: **la antigüedad corre en el reloj** (el tiempo de calendario desde que se creó el caso) y **el plazo corre en el horario laboral** (la promesa de SLA, con las pausas descontadas). Tienen nombres distintos a propósito. Mezclarlas daría dos números con la misma etiqueta y ninguna forma de saber cuál se incumplió.

• Informes listos: un clic convierte la plantilla en un informe suyo, con nombre en su idioma. De ahí en adelante es un informe normal, editable, compartible, exportable y programable como cualquier otro, sin ningún motor aparte por detrás.
• Hallazgos: SLA por debajo de lo acordado, entra más de lo que sale, cola envejeciendo, reaperturas, escalamiento, vacíos de conocimiento. Cada uno viene con los números que lo sostienen, una causa probable y una acción, ordenados por peso.
• Cumplimiento por hito: primera respuesta, siguiente respuesta y resolución, y no solo la resolución. La siguiente respuesta es cada vez que el cliente vuelve a hablar después de haber sido respondido una vez, y solo entra en la cuenta el caso que de verdad tenía objetivo.
• Envejecimiento de la cola por tramos (menos de un día, de uno a tres, de tres a siete, más de una semana), en general, por cola y por agente, con el caso más viejo a la vista.
• El bot tiene tres desenlaces, no dos: contenido sin humano, transferido a un humano, y **pidió humano y no vino nadie**, que es cola abandonada y antes se escondía dentro del número de contención.
• La voz, la mensajería y los incidentes tienen cada uno su lectura, porque una conversación de WhatsApp no es un caso y un incidente se mide por lo que costó en casos y por la causa raíz que vuelve siempre.
• Proyección de volumen: tendencia más un índice por día de la semana, para que el sábado no se proyecte como si fuera martes.

IA que actúa en el caso, con política

La IA ya leía todos los casos (categoría, urgencia, sentimiento, resumen) y nadie consumía eso. Ahora puede **escribir** categoría y prioridad en el caso, pero solo bajo una política que define el espacio de trabajo, y viene **apagada de forma predeterminada**: nada cambia hasta que quien administra la enciende en **Configuración → IA de atención**. Campo por campo eliges entre **No hacer nada**, **Sugerir (una persona confirma)** y **Escribir cuando esté segura**. Escribir solo ocurre por encima de un umbral de confianza que tú defines (de 50% a 100%, 80% de forma predeterminada); por debajo, la misma propuesta se convierte en una sugerencia que se aplica con un clic.

En la consola, la caja **Sugerencias de la IA** lista lo que está esperando: el valor propuesto con su confianza y el motivo por el que no se escribió (la política manda solo sugerir, por debajo del umbral, una persona ya había elegido un valor, límite diario alcanzado), con **Aplicar** y **Descartar**. Lo que la política escribió por sí sola queda visible en el historial de la caja como escrito por la política, para que el agente sepa que la categoría no la puso él. **Clasificar con IA ahora** ejecuta la misma política a mano. La caja desaparece para el espacio de trabajo que no encendió la política y no tiene ninguna sugerencia.

• La IA clasifica contra **tus** listas de categoría y prioridad. Un valor que no es una de tus opciones nunca se graba, y sin opciones registradas en un campo se queda callada en lugar de inventar una.
• Un valor elegido por una persona no se sobrescribe. De forma predeterminada el modo automático solo rellena lo que está vacío o sigue en el valor predeterminado del formulario; reemplazar una elección humana exige la opción explícita **Permitir que la IA reemplace un valor elegido por una persona**.
• Un borrador de respuesta **nunca se envía**. Aceptarlo lo coloca en el redactor con **Usar en el redactor**; revisar, editar y enviar siguen siendo tuyos. Resolver y cerrar un caso tampoco son nunca automáticos: no existe un modo para eso, en ningún lugar.
• Cada escritura automática cuenta en el límite diario de acciones compartido con el agente (**Configuración → IA**, autonomía del agente). En el límite, la IA vuelve a solo sugerir y lo dice en la caja y en la pantalla de la política, con los números de hoy: escritos, sugeridos, retenidos por el límite, esperando a una persona.
• Todo deja rastro: cada escritura automática en el libro de acciones del agente, cada llamada de IA en el registro de auditoría de IA cuando está encendido, y el propio cambio de política en la pista de auditoría.
• **Ejecutar cuando se crea un caso** aplica la política sin ninguna automatización configurada. Con eso encendido, crear un caso desde la pantalla espera a la IA unos segundos antes de que el caso aparezca; si la IA no está disponible (sin clave, tope de gasto, proveedor caído) el caso se crea de todos modos, sin nada escrito.
• Las automatizaciones del caso y las reglas por tiempo ganaron dos acciones: **Clasificar con IA (según la política de IA de atención)** y **Redactar respuesta con IA (nunca se envía)**. Una regla que primero fija la categoría y luego pide la IA no ve a la IA deshacerla.
• El mismo análisis del mismo texto nunca genera dos sugerencias y nunca cuenta dos veces en el límite; repetir una corrida no cuesta nada.

Trabajo de campo a partir del caso

El caso que necesita una visita ya no se vuelve a escribir en otra pantalla. Con la vertical de Servicios de Campo encendida, la caja **Trabajo de campo** de la consola abre la orden de campo directamente desde el caso, programa la visita y muestra al agente lo que el cliente pregunta por teléfono: próxima visita, si está atrasada, última visita, técnico, equipo. Todo se lee en vivo de la orden, de sus visitas y de su historial de estado, así que un cambio hecho en el tablero de despacho es lo que el caso muestra en la próxima apertura. La orden lleva el asunto y la descripción del caso como problema, y la prioridad del caso traducida a la de la orden (crítica pasa a urgente, alta queda alta, media normal, baja baja).

**Abrir orden de campo** pide la **propiedad**, que es obligatoria porque el caso no conoce la dirección de la visita: las propiedades del cliente vienen primero y marcadas, un cliente con una sola propiedad ya la tiene preseleccionada, y un caso sin contacto ni empresa busca en toda la base por nombre, dirección o código postal (las primeras 50, con un aviso para refinar). Cuando el caso apunta a un activo cuyo número de serie coincide con exactamente un equipo de esa propiedad, el equipo se **sugiere** con una casilla, nunca se elige por ti. Tipo de orden (reparación de forma predeterminada), técnico y ventana de llegada son opcionales; con ventana, la primera visita se programa de inmediato y aparece en el tablero de despacho; sin ventana, la orden queda en borrador, todavía sin visita.

• **Programar visita** agrega una visita a la misma orden desde la consola: una vuelta es la visita 2, 3 y así sucesivamente, nunca una segunda orden. Un caso tiene como máximo una orden, y un segundo clic en abrir responde que ya existe.
• La ventana de llegada y el técnico de la propia orden solo se rellenan cuando estaban vacíos: una segunda visita no reescribe lo acordado para la primera.
• **Visita atrasada** aparece cuando la ventana ya empezó y la visita sigue solo programada, es decir, nadie salió. El selector de cambio de estado ofrece solo las transiciones que la máquina de estados de la vertical acepta desde el estado actual.
• Cuando el trabajo de campo se **completa**, **no pudo completarse** o fue **cancelado**, quien tiene a cargo el caso recibe un aviso en su idioma con un enlace a la consola, venga el cambio de la consola, de la pantalla de la vertical o de la app. Despachado, en camino y esperando una pieza quedan visibles en la caja sin hacer sonar la campana de nadie.
• **El estado del caso nunca cambia por sí solo** cuando el campo termina. Confirmar con el cliente y resolver el caso es una decisión de quien atiende.
• **Desvincular** deshace el lazo entre caso y orden y nada más: la orden sigue viva en la vertical, con su propio historial. Cancelarla es una transición de la vertical, hecha allí.
• La tarea recordatorio en la fecha de la visita es opcional y reutiliza el módulo de actividades; aparece en la línea de tiempo del caso y en la lista de tareas del técnico, o en la del dueño del caso cuando no hay técnico.
• Con la vertical apagada, la caja lo dice y apunta a **Configuración · Verticales**, en lugar de mostrar un botón que fallaría. Ofrece el camino ligero que todo espacio de trabajo tiene, **Abrir una orden de servicio**, y muestra esa orden y sus citas cuando existe una.

Dónde configurar: **Configuración → Textos rápidos** para las frases, **Configuración → Plantillas de correo del ticket** para los textos transaccionales, y **Configuración → Habilidades** para quién sabe qué y qué exige cada cola. El swarm, el seguimiento y las pestañas de trabajo no necesitan configuración: ya están en la consola.

Abrir este artículo dentro del sistema →