Freshdesk – Buenas Prácticas Operativas

Resumen
Este tutorial reúne y estandariza las principales orientaciones discutidas en la reunión de capacitación institucional de Freshdesk, abordando dudas recurrentes sobre la apertura de tickets, tratamiento de múltiples problemas, uso correcto de los estados, funcionamiento del SLA, tickets vencidos, transferencias entre áreas, filtros, notas internas y uso de la base de conocimiento.

El objetivo es garantizar claridad operativa, evitar la pérdida de tickets y mejorar la experiencia del alumno y de los equipos internos.

Palabras clave & Tags

Freshdesk, apertura de ticket, SLA, tickets vencidos, estado del ticket, transferencia de ticket, notas internas, filtros, base de conocimiento, atención al alumno

Descripción

Durante el uso diario de Freshdesk, las prácticas incorrectas pueden generar impactos directos en el SLA, en los reportes y en la percepción del servicio por parte del alumno.

Este documento consolida orientaciones prácticas alineadas con la realidad operativa de la institución, sirviendo como una referencia única para agentes, coordinadores y equipos involucrados en la atención.

1. Apertura de Tickets

¿Qué ocurre cuando un alumno abre un ticket con varios problemas diferentes?

Cuando un alumno describe más de un problema en un mismo ticket (por ejemplo: financiero, académico y acceso), Freshdesk trata toda la información como un único ticket, con un solo SLA, independientemente del número de áreas involucradas.

Antes de profundizar en este tema, es importante entender el concepto de SLA (Service Level Agreement – Acuerdo de Nivel de Servicio).
El SLA define los tiempos esperados para la primera respuesta y para la resolución del ticket. Es uno de los principales indicadores utilizados para medir la calidad del servicio y se refleja tanto en la vista operativa como en los reportes de Freshdesk.

Esto puede generar:

• Dificultad en la priorización
• Transferencias excesivas entre áreas
• Tickets vencidos debido a una única pendiente

¿Es mejor mantener todo en un solo ticket o separarlo por tema?

Buena práctica recomendada:

Siempre que sea posible, el alumno debe separar los problemas en tickets diferentes, especialmente cuando:

• Involucran áreas distintas
• Tienen prioridades diferentes
• Requieren acciones independientes

Ejemplo:

• Ticket financiero
• Ticket académico
• Ticket de TI

Cada ticket tendrá su propio SLA y responsable.

¿Cómo priorizar cuando hay múltiples problemas en un mismo ticket?

Cuando no sea posible separarlos de inmediato:

1. Identificar el problema más crítico
2. Actuar primero sobre ese problema
3. Registrar los demás puntos en una nota interna, marcando al responsable si es necesario
4. Indicar al alumno que cree nuevos tickets, si corresponde

Cuando un alumno abre un ticket con múltiples solicitudes, es posible separar cada tema creando tickets secundarios (child tickets).
 Esto facilita el control, la organización y la derivación hacia diferentes equipos.

Utilice esta funcionalidad cuando:

• El ticket contiene más de un problema o consulta
• Los temas deben ser tratados por equipos diferentes (Finanzas, TI, Académico, etc.)
• Se desea mantener el historial organizado sin mezclar contextos

Pasos para crear un ticket secundario

1.1 Acceder al ticket original

• Ir al ticket creado por el alumno
• Abrirlo normalmente para visualizar los detalles

1.2 Localizar la opción para crear un ticket relacionado

Dentro del ticket:

• En el menú lateral derecho
• Buscar la opción Principal y Secundario (Parent–Child)

• Seleccionar Crear ticket secundario (Create a child ticket)

1.3 Definir el nuevo ticket (child ticket)

Al crear el ticket secundario:

• Asunto: definir un título específico del problema
• Descripción: copiar únicamente la parte relevante de la solicitud
• Grupo responsable: dirigirlo al equipo correspondiente
• Prioridad / Tipo: ajustar según sea necesario

Consejo: Mantener siempre el ticket enfocado en un solo tema

1.4 Guardar el ticket secundario

• Hacer clic en Create (Crear)
• El nuevo ticket será creado y vinculado al ticket original

 

1.5 Actualizar el ticket principal

En el ticket original:

• Las solicitudes han sido separadas
• Cada una será tratada de forma individual

 Resultado esperado

Después del proceso, tendrás:

• 1 ticket principal (padre)
• Varios tickets secundarios (hijos), cada uno con:

• Un tema específico
• Un responsable definido
• Mejor seguimiento

¿Puede un alumno reabrir un ticket antiguo para un nuevo asunto?

No es recomendable, aunque el alumno puede hacerlo.

Reutilizar tickets antiguos puede:

• Hacer que Freshdesk reabra automáticamente el ticket
• Hacer que el SLA vuelva como vencido
• Generar inconsistencias en los reportes
    

Al identificar que el alumno utilizó un ticket antiguo para tratar un nuevo asunto, el agente debe:

1. Responder el ticket, informando de forma clara y objetiva que se trata de un nuevo tema
2. Indicar al alumno que no reutilice tickets antiguos, explicando que esto puede afectar los tiempos de atención y el control del SLA
3. Solicitar que el alumno abra un nuevo ticket, garantizando que la solicitud sea derivada correctamente al área responsable
4. Una vez realizada la orientación, cerrar el ticket actual, cuando sea aplicable

 Esta práctica contribuye a:

• Mantener la organización de los atendimientos
• Garantizar mayor precisión en los plazos (SLA)
• Evitar inconsistencias en los reportes

2. Estado, SLA y Tickets Vencidos

¿Por qué algunos tickets aparecen como “vencidos” aunque ya hayan sido respondidos?

Algunos tickets pueden aparecer como vencidos porque el SLA no depende únicamente de la respuesta enviada al alumno.

El tiempo de SLA está influenciado principalmente por:

• el estado del ticket
• y el nivel de prioridad definido (Baja, Media, Alta o Urgente)
  
  

Esto significa que:

• Si el estado permanece como Abierto, el SLA continúa contando incluso después de una respuesta
• Los tickets con mayor prioridad (Alta o Urgente) tienen plazos más cortos y pueden vencer más rápidamente
• La combinación entre estado y prioridad determina el comportamiento del SLA

¿Qué hace que el SLA continúe contando incluso después de una respuesta?

Responder un ticket no pausa automáticamente el SLA.

El SLA se comporta correctamente cuando:

• el estado refleja quién tiene la próxima acción

Es decir:

• Si el estado está en Abierto, la acción sigue con el agente
• Si está en En espera de respuesta del solicitante, la acción está con el alumno

Diferencia práctica entre los estados

 
 El estado siempre debe reflejar quién necesita actuar a continuación.

¿Colocar el ticket en estado Pendiente congela el SLA?

Sí.
Al cambiar el estado de un ticket a Pendiente, el SLA se pausa (se congela).

Esto significa que el tiempo de SLA deja de contabilizarse mientras el ticket permanezca en ese estado.

De esta forma, el ticket no podrá quedar vencido durante el período en que esté marcado como Pendiente, ya que el temporizador del SLA permanece detenido hasta que el estado vuelva a uno activo.

Atención: Aunque el SLA esté pausado, es importante que el ticket no permanezca sin seguimiento durante largos períodos.

Se recomienda que el agente:

• realice un seguimiento frecuente de los tickets en estado Pendiente,
• verifique que el alumno o el área responsable haya sido correctamente informado,
• y retome la atención tan pronto como haya una respuesta, evitando olvidos o retrasos en la continuidad del proceso.
  
  

Mantener este control es fundamental para garantizar un servicio de calidad y una buena experiencia para el alumno.

Importante: Si el ticket ya estaba vencido antes de cambiar a Pendiente, este cambio no eliminará el estado de vencido.

Esto ocurre porque Freshdesk mantiene el historial del SLA, y el incumplimiento registrado no se revierte.

Al colocar el ticket en estado Pendiente:

• el SLA se pausa solo a partir de ese momento,
• sin modificar el tiempo ya acumulado anteriormente.

En otras palabras:

• El ticket permanece vencido si ya superó el plazo
• El estado Pendiente evita que el tiempo siga contando, pero no corrige el historial previo

¿Por qué un ticket reabierto meses después vuelve como vencido?

Esto ocurre porque:

• Freshdesk reutiliza el historial del ticket
• El SLA acumulado es retomado

Por eso, se recomienda evitar reutilizar tickets antiguos para nuevos asuntos.

¿Cómo se comporta el SLA cuando el ticket es transferido entre áreas?

El SLA continúa contando, incluso cuando el ticket se transfiere entre equipos, siempre que permanezca en un estado activo.

Las transferencias múltiples aumentan el riesgo de vencimiento, especialmente cuando no hay una definición clara de responsabilidad.

Buenas prácticas al transferir un ticket:

• Registrar una nota interna explicando el contexto
• Al transferir a otro sector, asignar siempre el ticket a un responsable específico, garantizando la continuidad de la atención
  
  

¿Por qué los tickets antiguos aparecen como vencidos en los reportes?

Los reportes de Freshdesk presentan una visión histórica y gerencial del ticket, y no solo la vista operativa del día a día.

Esto significa que el reporte considera todo el ciclo de vida del ticket, incluyendo:

• el tiempo hasta la primera respuesta,
• reaperturas realizadas por el alumno, incluso después de mucho tiempo,
• cambios de estado (Abierto, Pendiente, En espera de respuesta),
• períodos en los que el ticket estuvo pendiente esperando retorno, del alumno o de otra área

Por lo tanto, un SLA elevado en el reporte no necesariamente indica un error del agente. Por ejemplo:

• el ticket pudo haber sido respondido dentro del plazo,
• haber quedado en espera de respuesta,
• y luego haber sido reabierto después de un tiempo, aumentando el SLA total
  
  

Estos detalles quedan registrados en los reportes, permitiendo entender que el impacto en el SLA se debe al historial del ticket, y no a una demora en la atención inicial.

3. Encaminamiento y Responsabilidad

¿Cómo evitar que los tickets se pierdan durante las transferencias?

• Nunca transferir un ticket sin: 
  • una nota interna explicando el contexto,
  • y la definición de un responsable

¿Mejor práctica al transferir: persona o grupo?

Asignar siempre el ticket a:

• el grupo correcto,
• y a una persona específica

Transferir solo al grupo aumenta el riesgo de que el ticket quede sin atención.

4. Filtros, Visualización y Reportes

¿Por qué algunos tickets no aparecen cuando hay filtros aplicados?

En Freshdesk, los filtros se guardan automáticamente.
Esto significa que, cuando un agente aplica un filtro y sale de la página o del sistema, este filtro permanece activo al regresar, sin reiniciarse automáticamente.

Por este motivo, algunos tickets pueden no aparecer en la visualización, incluso estando abiertos o asignados, simplemente porque no cumplen con los criterios del filtro activo.

Antes de concluir que un ticket “desapareció”, es importante:

• revisar los filtros activos,
• eliminar o ajustar los filtros aplicados,
• confirmar que la visualización sea la adecuada (por grupo, no asignados, no resueltos, etc.)
  
  

Filtros recomendados

• Tickets no asignados
• Tickets por grupo
• Tickets no resueltos
  
  

Evitar trabajar únicamente con la vista de “Mis tickets”.

5. Notas Internas y Comunicación

Importancia de las notas internas

Las notas internas:

• Garantizan la continuidad del proceso de atención
• Reducen el retrabajo
• Registran el historial del ticket
• Envían notificaciones por correo electrónico

¿Las notas generan notificación automática?

Sí, especialmente cuando:

Se realiza la mención de agentes, quienes reciben una notificación automática por correo electrónico informando sobre la nota añadida al ticket

¿Las notas quedan registradas en el historial?

Sí. Las notas internas forman parte del historial completo del ticket.

Se visualizan de forma clara en la línea de tiempo del ticket, separadas de las respuestas públicas al alumno e identificadas como comunicación interna entre agentes.

Estas notas no son visibles para el alumno y se utilizan para registrar contexto, decisiones e información relevante para la continuidad del proceso de atención entre los equipos.

6. Base de Conocimiento y Materiales

¿El alumno puede resolver el problema antes de abrir un ticket?

Sí.

La Base de Conocimiento está compuesta por artículos informativos, que son materiales explicativos creados por los equipos para orientar a los alumnos sobre dudas y procedimientos comunes (por ejemplo: cómo localizar el ID del alumno, cómo acceder a plataformas o cómo abrir un ticket correctamente).

Estos artículos están disponibles para los alumnos y, en muchos casos, permiten que el problema sea resuelto sin necesidad de abrir un ticket, agilizando la atención y reduciendo el volumen de solicitudes repetitivas.

Enlace a la base de conocimiento:
Solutions : Suporte ao Aluno / Apoyo Estudiantil

¿Es posible sugerir artículos relacionados con el tema del ticket?

Sí, con base en:

• Asunto
• Descripción
• Palabras clave

Creación de materiales explicativos para alumnos

Se recomienda crear artículos como:

• Cómo localizar el ID del alumno
• Cómo abrir un ticket correctamente
• Qué área seleccionar
• Cómo realizar el seguimiento de un ticket

Cómo utilizar artículos y respuestas predefinidas para escalar la atención

• Reducción de tickets repetitivos
• Respuestas estandarizadas

Contactar Soporte

Si persisten dudas o se requiere asistencia adicional, comuníquese con el equipo de TI a través de:

https://mustedustudents.freshdesk.com/sp/support/tickets/new