Software de mesa de ayuda para agencias: cada solicitud de cliente en una sola cola

Los clientes nunca ven tu cola. Ven Soporte en su propio portal, que lleva el nombre, el logotipo y los colores del cliente, con los de tu agencia en su lugar donde el cliente no ha fijado ninguno. Una tarjeta «How can we help?» (¿cómo podemos ayudarte?) con un botón «New request» está sobre las solicitudes abiertas, cada una con su número, su estado, una línea clara sobre lo que ocurre a continuación y un punto cuando tu equipo escribió en último lugar. Las solicitudes resueltas y cerradas se pliegan en una lista inferior que muestra además la valoración en estrellas que haya dado el cliente. Mientras la página sigue abierta se vuelve a comprobar cada medio minuto más o menos, y de nuevo cuando el cliente regresa a la pestaña, de modo que una respuesta aparece sin recargar.

Las respuestas de tu equipo llevan la marca de tu agencia junto al nombre del compañero que las escribió, de modo que un hilo se lee como una sola agencia con independencia de quién tecleara. Cualquier persona a la que invites al portal del cliente puede plantear una solicitud y ve todas las que se han registrado para esa empresa, incluidas las que registró tu equipo, y esos inicios de sesión no ocupan ninguna plaza de agencia. Las respuestas y las resoluciones les llegan por la campana del portal y, según sus ajustes de notificación, por email y por aviso en el dispositivo. Plantear una solicitud también envía a quien la presentó un justificante por email, salvo que haya desactivado los emails de Soporte. Los portales son una función de los planes Scale y Enterprise.

El lado de la agencia se abre con cinco recuentos: «Open», «In progress», «Waiting on client», «Unassigned» y «Urgent» (abiertos, en curso, a la espera del cliente, sin asignar y urgentes). Cada uno es un botón que filtra la cola que tiene debajo, junto a pestañas para «All», «Open», «In progress», «Waiting on client», «Resolved» y «Closed» (todos, abiertos, en curso, a la espera del cliente, resueltos y cerrados), un cuadro de búsqueda y un orden por actividad reciente, prioridad, más nuevos o más antiguos. «My tickets» (mis tickets) muestra los que tienes asignados, y el interruptor «Unassigned» muestra los que todavía no tiene nadie. La numeración de tickets va por cliente, así que el n.º 4 de un cliente no dice nada de cuántos tickets gestiona tu agencia.

El selector de clientes de la cabecera acota toda la página. Elige un cliente y la cola, los recuentos y el formulario «New ticket» lo siguen; elige «Todos los clientes» y cada fila lleva el nombre y la marca del cliente, de modo que quien dirige puede vigilar todas las cuentas a la vez. El selector muestra también los tickets abiertos por cliente. Un panel de contexto en el ticket abierto reúne los datos del perfil del cliente, quien hizo la solicitud, los contactos y los miembros del portal, y el equipo de la cuenta, con accesos rápidos al perfil, al CRM, a Chat y a Archivos.

Para quien puede gestionar Soporte, el editor bajo cada ticket alterna entre «Reply» (responder) y «Internal note» (nota interna). Una respuesta va al cliente. Una nota se guarda en el mismo hilo como una tarjeta ámbar de borde discontinuo marcada «Internal note», y el propio editor se vuelve ámbar mientras escribes una, de modo que publicar lo que no toca por costumbre resulta difícil. Las notas son donde ocurre el trabajo: quién tiene el acceso del cliente, qué dijo el último desarrollador, si ya se acordó la compensación.

La separación se hace en el servidor antes de que el portal llegue a recibir el hilo. Las notas se filtran del hilo allí, la clave del autor en la lista del equipo no se envía jamás, y la persona asignada, las etiquetas, el estado de posposición y la tarea vinculada del ticket tampoco forman parte de lo que un cliente puede cargar. Lo que el cliente sí ve es el hilo público: las respuestas, los archivos adjuntos y breves líneas del sistema, como un cambio de estado o a quién se asignó el ticket, de modo que el progreso es visible aunque la discusión no lo sea.

Cada ticket lleva una prioridad, y cada prioridad lleva un tiempo de respuesta: «Urgent» (urgente) 4 horas, «High» (alta) 8 horas, «Normal» 24 horas y «Low» (baja) 48 horas. Mientras te toca responder a ti, la cabecera del ticket muestra una etiqueta que dice «Respond in 3h» (responder en 3 h) y, cuando se acaba el tiempo, se pone roja y dice «Overdue» (vencido), con cuánto lleva de retraso. El reloj arranca cuando el cliente escribe, o cuando se plantea un ticket desde el portal, y se detiene cuando el equipo responde. Los clientes escriben a través del portal, así que en un plan sin él un ticket que registra tu equipo no lleva reloj. Una nota interna no lo detiene, y no corre nada mientras un ticket está a la espera del cliente, resuelto o cerrado. Las horas son horas transcurridas sin más, no horas laborables.

Responder es más rápido con las cinco respuestas predefinidas del editor: acusar recibo, pedir más información, dar una actualización, pedir al cliente que confirme una corrección y avisar de que el trabajo está programado. Se insertan como texto normal, así que editas los detalles antes de enviar. La primera respuesta que puede leer un cliente lleva un ticket «Open» a «In progress» por sí sola y deja una línea del sistema que lo indica. Eso reserva «Open» para los tickets que necesitan el siguiente paso del equipo: los nuevos, los que un cliente ha reabierto y aquellos a los que un cliente contestó mientras el ticket estaba resuelto o a la espera del cliente.

No todos los tickets abiertos pueden avanzar hoy: un desarrollador está fuera, un cliente viaja, una plataforma está caída. «Snooze» (posponer) lo aparca durante cuatro horas, hasta mañana a las 9 a. m., durante tres días, durante una semana o hasta la hora que elijas. El ticket sale de todas las pestañas predeterminadas y de los recuentos que hay sobre la cola, «Unassigned» y «Urgent» incluidos, y espera bajo una pestaña «Snoozed» que solo existe mientras haya algo aparcado. Lo que queda en la cola es el trabajo que se puede hacer ahora.

Dos reglas lo mantienen honesto. Posponer afecta a todo el equipo y es interno: un compañero ve la misma cola, y el cliente no recibe ninguna notificación ni ninguna línea en el hilo, ni recibe nunca el dato de que el ticket está pospuesto. Y no pausa el reloj de respuesta, porque ocultar una fila es solo clasificar el trabajo, mientras que una promesa de responder es un compromiso, de modo que un ticket aparcado puede llegar a «Overdue» aunque esté fuera de la vista. Si el cliente responde o reabre un ticket pospuesto, este despierta en cuanto lo hace y vuelve a la cola.

Una solicitud también es trabajo, y el trabajo pertenece al tablero. La mesa de ayuda mantiene una tarea por cada ticket en un proyecto «Support Tickets» de ese cliente: una solicitud del portal recibe su tarea al llegar, y un ticket que registra tu equipo recibe una al guardarse. La tarea se titula con el número y el asunto del ticket, se crea con la prioridad del ticket y se enlaza de vuelta con él. Cuando tu equipo cambia el estado, el responsable o el asunto, la tarea lo sigue: los tickets resueltos y cerrados van a la primera columna de hechos, «In progress» va a la columna de progreso cuando tu tablero tiene una, y todo lo demás queda en la primera columna de abiertos. Cuando un cliente cierra o reabre un ticket, la tarea se mueve también.

La tarea se crea en la medida de lo posible, así que si alguna vez falta una, «View task in Projects» (ver la tarea en Proyectos), en el menú del ticket, la crea. El vínculo va en un solo sentido, del ticket a la tarea, así que un desarrollador puede añadir subtareas y comentarios a la tarea sin tocar lo que lee el cliente. El proyecto y sus tareas se crean privados y no se comparten con el portal, que tiene su propia página de Soporte para la versión del cliente. La carga de soporte aparece entonces junto al trabajo de entrega en Proyectos, donde los responsables ya miran, en lugar de en una herramienta aparte que tienen que acordarse de abrir.

Resolver un ticket no termina la conversación; plantea una pregunta. El ticket del cliente muestra «Did this solve it?» (¿esto lo ha resuelto?) con dos botones: uno que cierra el ticket y otro, «Not quite» (no del todo), que lo reabre. Un ticket cerrado sigue cerrado hasta que el cliente o tu equipo lo reabre. Cuando el cliente lo reabre, el ticket vuelve a la cola, despierta si estaba pospuesto y avisa al equipo; si lo reabre tu equipo, el estado vuelve a «Open». Del lado del cliente, responder a un ticket cerrado está bloqueado hasta que se reabre, de modo que una respuesta tardía nunca desaparece en un registro terminado.

Cuando un ticket está resuelto o cerrado, el cliente puede valorarlo de uno a cinco, y la valoración aparece como estrellas en su fila de tu cola y en la cabecera del ticket. Los cambios de estado y las asignaciones del equipo, el cierre o la reapertura por parte de un cliente y las valoraciones dejan una línea del sistema en el hilo, así que el historial de un ticket se lee en orden. Un ticket planteado por error puede eliminarlo quien puede gestionar Soporte, tras una confirmación en dos pasos. El hilo se va con él, y «Undo» (deshacer) recupera el ticket pero no sus respuestas. La tarea del ticket se queda en Proyectos hasta que alguien la elimine.