Búsquedas frecuentes
Tutoriales actualizados
Un ticket interno es un pedido de ayuda que nace y muere dentro de la empresa.
Lo abre alguien que trabaja ahí y lo atiende un área de la misma empresa, sin que ningún cliente participe.
La computadora que no arranca, la lámpara quemada del depósito, el certificado que se necesita para un trámite: todo eso es un ticket interno.
Sin un registro, los pedidos internos viajan por mensajes sueltos, correos y conversaciones de pasillo.
El resultado es predecible: se pierden, se duplican y nadie sabe cuántos hay ni quién los está atendiendo.
Hay tres síntomas que delatan que el circuito informal dejó de alcanzar.
Registrar el pedido convierte un favor en un compromiso con fecha, y eso cambia el comportamiento de las dos partes.
Esta es la confusión más común y conviene resolverla de entrada.
La diferencia no está en la herramienta sino en quién es el cliente.
El ticket de servicio atiende a alguien de afuera, tiene impacto comercial y suele arrastrar compromisos contractuales.
El ticket interno atiende a alguien de adentro, y su impacto es la productividad de la propia gente.
Separarlos evita que el pedido de una lámpara compita en la misma cola que el reclamo de un cliente que está por irse.
El error clásico es pensar el ticket interno como algo exclusivo de un solo sector.
En realidad cualquier área que dé servicio puertas adentro recibe pedidos, y la lista es más larga de lo que parece.
Los tres términos se usan como sinónimos y no lo son.
El ticket es el recipiente: el registro del pedido, sea lo que sea que haya adentro.
El incidente es una interrupción concreta que hay que restablecer cuanto antes.
El problema es la causa de fondo que genera incidentes repetidos y que se resuelve una sola vez.
Cinco tickets internos por la misma impresora son cinco incidentes y un solo problema.
Un servicio interno sin números vive de percepciones, y las percepciones suelen ser peores que la realidad.
Los dos datos que ordenan la discusión son cuántos pedidos entran por período y cuánto se tarda en cerrarlos.
Con esos dos números se puede pedir más gente, cambiar una prioridad o justificar el reemplazo del equipo que genera la mitad de los tickets.
El hub de Atención y servicio al cliente ubica este concepto dentro de un proceso empresarial.
En Atención al Cliente para empresas medianas: Mesa de Ayuda, Tickets y Autoservicio bien hechos vemos cómo se aplica a decisiones y tareas concretas.
EGA Futura Habitat muestra cómo se refleja dentro de la Plataforma.
Y EGA Futura People lo muestra desde otra parte del sistema.
El ticket interno es un objeto propio de la base de datos, con diecisiete campos, y cada registro es un pedido concreto de alguien de la empresa.
Su estructura está pensada para responder cuatro preguntas: quién pidió, quién atiende, de qué se trata y cuánto tardó.
El campo Solicitante guarda al usuario que abrió el pedido y Usuario asignado a quien lo tiene que resolver.
Que sean dos campos distintos es lo que permite armar la bandeja personal de cada persona que atiende, filtrando por el asignado.
Hay además un campo Empleado, que apunta al legajo de la persona involucrada.
Esa distinción importa porque quien abre el pedido no siempre es la persona afectada, como cuando un jefe reporta la falla del equipo de alguien de su equipo.
El campo Área funcional completa el cuadro, indicando qué sector se hace cargo.
La Categoría es lo que revela el alcance real del objeto: Instalaciones, Maquinarias y equipamientos, Recursos Humanos, Administración, Finanzas, Legales, Software y aplicaciones y Hardware.
Ocho categorías que van desde una falla de sistema hasta una consulta legal.
Ese abanico es la mejor prueba de que el ticket interno no pertenece a un área sino a toda la empresa.
Un Informe agrupado por categoría responde de inmediato cuál es el sector que más pedidos recibe.
El Estado arranca en Nuevo y recorre Asignado, En proceso, Esperando respuesta, En espera, Resuelto y Cerrado.
Los dos estados de pausa merecen atención porque se confunden todo el tiempo.
Esperando respuesta significa que la pelota está del lado de quien pidió, típicamente porque se necesita un dato adicional para avanzar.
En espera significa que la demora es ajena a las dos partes, como cuando se aguarda un repuesto.
Distinguirlos evita la discusión eterna sobre de quién es la culpa de que un ticket lleve dos semanas abierto.
Y la diferencia entre Resuelto y Cerrado es la confirmación: el primero lo declara quien atendió, el segundo da por terminado el circuito.
Los valores son Crítica, Alta, Normal y Baja, con Normal como valor por defecto.
Ese valor por defecto está bien elegido: obliga a que la urgencia sea una decisión explícita y no el estado natural de todo lo que entra.
Cruzando prioridad con estado en una Vista de lista aparece la cola de trabajo del día ordenada por lo que de verdad importa.
La Fecha compromiso registra para cuándo se prometió la solución y la Fecha de resolución cuándo se logró.
Sobre esas fechas trabaja Días de resolución, un campo que se calcula solo y guarda cuánto tardó realmente cada pedido.
Ese número es la base de todo lo demás: promediado por categoría muestra qué sector es el más lento, y promediado por prioridad muestra si lo crítico se atiende como crítico.
Al calcularse solo, nadie lo puede maquillar, que es exactamente lo que se le pide a un indicador de servicio.
La Descripción guarda el pedido tal como lo planteó quien lo hizo.
Los Comentarios acumulan el ida y vuelta mientras el ticket avanza.
Las Notas de resolución explican qué se hizo finalmente, y son el campo más subestimado de todos.
Bien escritas, esas notas convierten cada ticket cerrado en materia prima para un artículo de conocimiento que evita el siguiente ticket igual.
El Motivo de cierre agrega la razón por la que terminó, y permite separar lo que se resolvió de lo que se cerró por otra vía.
Alguien de depósito abre un ticket de categoría Hardware porque el lector de códigos dejó de funcionar.
Entra como Nuevo con prioridad Normal, pasa a Asignado cuando sistemas lo toma y a En espera mientras llega el repuesto.
Al reemplazarlo queda Resuelto, con las notas de resolución explicando qué se cambió, y el área funcional de sistemas suma un pedido más a su Informe del mes.
Si el mismo lector vuelve tres veces, los Días de resolución acumulados son el argumento para comprar uno nuevo.
El Ticket interno se confunde seguido con el que abre un cliente, y de ahí sale la primera consulta. Después vienen los estados que se parecen entre sí y cómo se mide el servicio interno.
La diferencia está en quién es el cliente.
El ticket de servicio atiende a alguien de afuera de la empresa, y el ticket interno atiende a la propia gente de la casa: son dos objetos separados justamente para que no compitan en la misma cola.
No. Recursos Humanos es una de las ocho categorías disponibles.
Las otras siete cubren Instalaciones, Maquinarias y equipamientos, Administración, Finanzas, Legales, Software y aplicaciones y Hardware, o sea cualquier área que preste servicio puertas adentro.
Esperando respuesta indica que la demora depende de quien hizo el pedido, casi siempre porque se necesita un dato para poder seguir.
En espera indica que la demora es ajena a las dos partes, como cuando se aguarda un repuesto o la respuesta de un tercero.
Con el campo Días de resolución, que se calcula solo a partir de las fechas del ticket y por lo tanto nadie puede ajustar a mano.
Promediado por categoría y por prioridad, muestra qué sector tarda más y si los pedidos críticos se están atendiendo como tales.
El objeto es EGAFutura__Ticket_interno__c, con etiqueta Ticket interno, y expone diecisiete campos.
Convive con EGAFutura__Ticket_servicio__c, que es el objeto de atención a clientes externos: son dos objetos separados y no dos tipos de registro del mismo.
EGAFutura__Estado__c tiene siete valores: Nuevo, Asignado, En proceso, Esperando respuesta, En espera, Resuelto y Cerrado. El valor por defecto es Nuevo.
EGAFutura__Prioridad__c tiene cuatro valores: Crítica, Alta, Normal y Baja, con Normal como valor por defecto.
EGAFutura__Categoria__c tiene ocho valores: Instalaciones, Maquinarias y equipamientos, Recursos Humanos, Administración, Finanzas, Legales, Software y aplicaciones y Hardware.
EGAFutura__ClosureReason__c guarda el motivo de cierre, también como lista de selección.
EGAFutura__RequesterUser__c es un Lookup a User y guarda al solicitante.
EGAFutura__Usuario_asignado__c es un Lookup a User y guarda a quien atiende el pedido.
EGAFutura__Empleado__c es un Lookup a EGAFutura__Empleado__c, y EGAFutura__Area_funcional__c un Lookup al objeto de áreas funcionales.
EGAFutura__DueDate__c es la fecha compromiso y EGAFutura__ResolutionDate__c la fecha de resolución, ambas de tipo Date.
EGAFutura__ResolutionDays__c es un campo Formula de tipo Number y por lo tanto de solo lectura: admite filtro, agrupación y consulta, pero cualquier intento de escribirlo falla.
EGAFutura__Descripcion__c, EGAFutura__Comentarios__c y EGAFutura__ResolutionNotes__c son los tres Long Text Area de 32768 caracteres.
Name es de tipo Text con ochenta caracteres, y el conjunto se completa con CurrencyIsoCode y EGAFutura__EGA_Futura_ID__c, una numeración automática obligatoria.
Como EGAFutura__ResolutionDays__c es una fórmula, un tablero de indicadores debe agrupar por ese campo en lugar de recalcularlo por fuera.
Los dos Lookup a User permiten armar filtros por usuario actual, que es lo que convierte una Vista de lista en la bandeja personal de quien atiende.
Al importar tickets históricos conviene enviar Estado y Prioridad de forma explícita, porque los campos con valor por defecto se completan solos cuando se los omite.
Ventas, compras, inventario, finanzas y equipo, con la información al día y disponible desde cualquier dispositivo. Funciona en la nube, así que no hay servidores que mantener.
Quiero llevar mi Empresa a la Nube
