Catálogo de serviciosNUEVO
Quien necesita algo interno hoy abre un ticket en blanco y escribe lo que recuerda. Nadie sabe qué se puede pedir, el ticket llega sin el dato obvio, el agente pregunta, la persona responde al día siguiente, y el plazo del SLA se fue en esa ida y vuelta. El catálogo cambia el ticket en blanco por una vitrina: cada servicio, desde un portátil nuevo hasta un acceso a un sistema, es un elemento con su propio formulario, su cola y su prioridad. La persona elige el servicio, responde las preguntas de ese servicio, y el sistema abre un ticket de verdad, ya rellenado y en el lugar correcto. No existe un pedido paralelo: es el mismo ticket que abre la consola, que cronometra el SLA, que mueven las automatizaciones y que ve la API. Y, por primera vez, se puede responder cuántas veces se pidió cada servicio en el mes.
- Vitrina con búsqueda por nombre, descripción o código, y categorías en árbol, para que un elemento viva en TI y, dentro de ella, en Accesos.
- Formulario por servicio: hasta 40 preguntas en nueve tipos (texto, texto largo, selección, correo, teléfono, número, fecha, fecha y hora, sí o no), cada una obligatoria o no, con su texto de ayuda.
- Pregunta condicional: el campo solo aparece cuando otro campo tiene determinado valor, y lo que quedó oculto no se exige ni se guarda.
- Cola, prioridad y categoría por defecto en cada elemento: el ticket nace donde tiene que nacer, sin triaje manual.
- Asunto compuesto: tú marcas qué respuestas entran en el asunto, así cien pedidos del mismo servicio no llegan con cien asuntos idénticos.
- Aprobación por elemento, en el mismo motor de aprobación que la empresa ya usa, sin un segundo motor.
- El pedido congela una foto del formulario: cambiar las preguntas hoy no hace que el pedido de ayer mienta.
- Reenviar el mismo formulario devuelve el pedido que ya existe, en vez de abrir un segundo ticket y comprar dos portátiles.
- Informe de cuántas veces se pidió cada servicio, contado por el vínculo con el elemento, nunca por un contador mantenido a mano.
Gratis en Sellio, solo pagas la máquina
Un catálogo de servicios con formulario propio, cola y aprobación suele ser un módulo de ITSM aparte. En Sellio viene junto con la atención: solo pagas la máquina.
El pedido llega completo
El servicio hace sus preguntas al momento de pedir, así el agente no pierde un día preguntando lo obvio y el plazo no se va en la ida y vuelta.
Nadie tiene que adivinar qué se puede pedir
La vitrina muestra los servicios por categoría, con búsqueda por nombre, descripción o código, y cada uno explica qué es antes de que la persona rellene nada.
La cola recibe trabajo ya triado
Cola, prioridad y categoría vienen del elemento, y el asunto ya dice de qué se trata, así nadie tiene que reclasificar lo que acaba de llegar.
Lo que se pide se puede medir
El informe muestra cuántas veces se pidió cada servicio, que es la pregunta que hoy simplemente no tiene respuesta posible.
El pedido se vuelve un ticket de verdad, con número de protocolo, cola, SLA, consola, automatizaciones, API e historial: todo lo que el producto ya da a cualquier ticket.
Las respuestas van a dos lugares con propósitos distintos: como texto legible dentro del ticket, para que el agente lo lea, y estructuradas en el pedido, para que el informe las cuente.
La aprobación reutiliza el motor de la casa, el mismo de las demás aprobaciones, así que política, delegación y traza valen aquí sin ninguna regla nueva.
El catálogo nace vacío: mientras nadie registre un elemento, abrir un ticket sigue funcionando exactamente como ayer.
Del ticket en blanco a la vitrina
La pregunta que responde el catálogo es simple y hoy no tiene respuesta: ¿qué se puede pedir? Sin vitrina, cada persona inventa su propia forma de pedir lo mismo. Sin formulario por servicio, el pedido llega sin el dato que el agente va a tener que preguntar de vuelta, y esa ida y vuelta es la que se come el plazo. Con el catálogo, quien administra arma la lista una vez, en Configuración: categorías, elementos y las preguntas de cada elemento. Cualquier persona de la empresa abre la misma pantalla, elige y pide. Un catálogo que solo ve el administrador no tendría a quién servir.
El formulario es del servicio, no del ticket
Cada elemento lleva las preguntas que ese servicio necesita: hasta 40, en nueve tipos, cada una obligatoria o no y con un texto de ayuda debajo. La pregunta puede ser condicional, y aparece solo cuando otra respuesta tiene determinado valor; el campo que quedó oculto no se exige ni se guarda, porque exigir la respuesta de una pregunta que la persona nunca vio es la forma más rápida de volver un formulario imposible de enviar. La lectura es tolerante en el formato y estricta en el significado: "3.300,00" y "35%" entran como número, la fecha acepta los formatos que la gente escribe, pero el 30 de febrero se rechaza en vez de convertirse solo en el 2 de marzo. Dos preguntas con la misma clave se rechazan al guardar, si no la segunda sobrescribiría la respuesta de la primera sin ningún error.
Dónde nace el ticket, y con qué cara
El elemento define la cola de destino, la prioridad y la categoría del ticket, así el pedido cae en el equipo correcto con el peso correcto, sin triaje manual. El asunto se arma con el nombre del servicio más las respuestas que marcaste como parte del asunto: sin eso, cien pedidos de "Acceso a un sistema" llegan con cien asuntos idénticos y la cola se vuelve ilegible. La descripción del ticket lleva las respuestas en pares de pregunta y valor, en el mismo formato que ya usa el portal, para que el agente lo lea todo sin abrir otra pantalla. Y el canal del ticket sale del mapa de canales de tu empresa, no de un literal escrito en el código.
Aprobación por elemento, sin un segundo motor
Un elemento puede exigir aprobación, y esa exigencia es un dato del elemento, no un motor nuevo: quien decide es el mismo motor de aprobación que la empresa ya usa en otras cosas, con las mismas políticas, la misma delegación y la misma traza. El ticket se abre de inmediato, y la aprobación pendiente bloquea la resolución por el camino que la consola ya tiene. Retener el ticket hasta que alguien apruebe dejaría al solicitante viendo la nada, sin número de protocolo, sin cola y sin SLA. El pedido tiene tres estados, esperando aprobación, abierto y rechazado, y el estado se lee de la aprobación en cada consulta, nunca se copia a una columna: una copia divergiría en silencio en cuanto una aprobación se decidiera en otro lugar. Una honestidad que la propia pantalla dice en voz alta: el motor responde "aprobado" cuando ninguna política coincide, así que marcar "exige aprobación" en una empresa sin política registrada no bloquea nada. Registra primero la política, la exigencia después.
Desactivar no es cancelar, y eliminar no siempre se puede
Desactivar un elemento quiere decir "no pidas más esto", nunca "cancela lo que está en curso". Los tickets ya abiertos por ese servicio siguen abiertos, con la misma cola y el mismo plazo, y los pedidos históricos siguen contando en el informe. Cancelar el trabajo de otra persona con un clic de configuración sería una consecuencia que nadie pidió y que la pantalla no avisa. Por la misma razón, un elemento que ya se pidió no se puede eliminar, solo desactivar: eliminarlo se llevaría el significado de todo pedido histórico y el informe empezaría a mentir en silencio. Y una categoría con elementos dentro tampoco se elimina, porque los elementos quedarían sin taxonomía y la vitrina con una sección fantasma. Mover los elementos, o desactivar la categoría, es el camino.
La foto que impide que el historial mienta
El elemento es editable para siempre, y eso es justamente lo que hace necesario el congelamiento. Cada pedido guarda una foto de las preguntas como estaban cuando la persona respondió, junto con el número de versión del formulario y el código y el nombre del servicio de aquel día. Renombrar una pregunta hoy, o cambiar el nombre del servicio, no reescribe lo que se pidió en marzo. La versión del formulario sube cuando el formulario cambia, y solo entonces: renombrar el elemento o cambiar su cola no es un cambio de formulario, e inflar el número en cada guardado le quitaría el sentido al número que el pedido congela. Del otro lado de ese vínculo sale la métrica que justifica que el catálogo exista, cuántas veces se pidió cada servicio, contada a partir de los propios pedidos y no de un contador incrementado a mano.
- 1
En Configuración, catálogo de servicios, quien administra crea las categorías y los elementos.
- 2
Cada elemento recibe sus preguntas, su cola de destino, su prioridad y, si corresponde, la exigencia de aprobación.
- 3
Cualquier persona de la empresa abre la misma pantalla, elige el servicio y rellena el formulario.
- 4
El ticket se abre en la cola correcta, con las respuestas dentro, y el pedido queda registrado para el informe.
Un portátil nuevo para quien entró
El elemento pregunta el modelo, el centro de costo y la fecha de inicio, exige la aprobación del responsable y cae en la cola de TI con prioridad alta.
Acceso a un sistema
La pregunta "qué sistema" es una selección, y el campo "qué perfil" solo aparece después de elegir el sistema, así nadie responde lo que no aplica.
Segunda copia de un documento
La misma persona puede pedir dos veces el mismo día, a propósito; lo que no ocurre es que un doble clic abra dos tickets del mismo pedido.
El servicio deja de ofrecerse
Desactivas el elemento y desaparece de la vitrina al instante, sin tocar los tickets que ya estaban en curso ni borrar el historial de quien lo pidió.
¿El pedido es un ticket o algo aparte?
Es un ticket de verdad, con número de protocolo, cola, SLA, consola, automatizaciones, API e historial. No existe un pedido paralelo con ciclo propio.
¿Quién puede armar el catálogo y quién puede pedir?
Armarlo es de quien administra, porque un elemento define cola, prioridad y aprobación, es decir, define trabajo para los demás. Pedir es de cualquier persona de la empresa.
¿Desactivar un elemento cancela los pedidos en curso?
No. Desactivar quiere decir "no pidas más esto": los tickets ya abiertos siguen abiertos, con la misma cola y el mismo plazo.
¿Puedo eliminar un elemento que ya se pidió?
No, solo desactivarlo. Eliminarlo se llevaría el significado de todo pedido histórico y el informe empezaría a mentir. Vale lo mismo para una categoría con elementos dentro.
Si cambio las preguntas, ¿cambian también los pedidos antiguos?
No. Cada pedido guarda una foto de las preguntas como estaban cuando la persona respondió, con la versión del formulario y el nombre del servicio de aquel día.
¿Marcar "exige aprobación" garantiza que alguien va a aprobar?
Solo si existe una política de aprobación que coincida con el caso. El motor responde "aprobado" cuando ninguna política coincide, y la pantalla lo avisa donde activas la exigencia.
¿Un doble clic abre dos tickets?
No. Reenviar el mismo formulario devuelve el pedido que ya existe. Pedir el mismo servicio otra vez, a propósito, sigue valiendo: dos segundas copias son dos pedidos.
¿Tengo que configurar el catálogo para que la atención siga funcionando?
No. Mientras nadie registre un elemento, abrir un ticket sigue funcionando exactamente como antes, así que puedes adoptarlo un servicio a la vez.