El soporte que vive en WhatsApp resuelve rápido y no recuerda nada

Son las seis y media de un viernes. Al celular personal del muchacho que sabe le entra un mensaje: «oye, otra vez no deja timbrar». Contesta, pregunta dos cosas, pide una foto de la pantalla y a las siete está resuelto. Nadie levantó nada, nadie escribió nada, y el lunes todos siguieron trabajando.

Eso funciona. Por eso lleva años así y nadie lo cuestiona.

El problema aparece en marzo, cuando el mismo error vuelve a salir y la persona que lo resolvió aquel viernes ya no trabaja ahí.

Por qué el orden es el argumento equivocado

Cuando alguien le propone poner tickets, casi siempre le habla de orden: que nada se pierda, que haya un tablero, que se vea quién atiende qué.

Es un argumento débil y su gente lo sabe: las solicitudes no se pierden. El que insiste por WhatsApp sale antes que el que manda correo.

El problema es otro y es más caro: su operación no recuerda nada.

Cada solicitud que se atiende por mensaje se resuelve dos veces. Una cuando ocurre. Otra seis semanas después, cuando el diagnóstico se rehace desde cero porque la conversación quedó enterrada cuatrocientos mensajes atrás, en el teléfono de alguien.

Cuando el historial vive en un teléfono

Contabilidad tuvo un documento que no se timbraba y lo resolvió con el proveedor. Dos meses después le pasó a la sucursal, que llamó al contador y se acordaba a medias. Cuatro meses después le tocó a compras, que abrió un caso nuevo y pagó otra vez el diagnóstico.

Tres veces el mismo problema, tres soluciones que nadie escribió. Desde la dirección la foto es una sola: «a veces falla el timbrado».

Un chat está hecho para fluir, no para consultarse. Nadie busca hacia arriba en un grupo de doscientos participantes, y si quien tuvo esa conversación ya no está, la información nunca estuvo en otro lado.

Y quien carga el soporte en su celular se vuelve imposible de sustituir y de dejar descansar. No es que no quiera compartir lo que sabe: no hay dónde ponerlo.

Las preguntas que hoy no puede contestar

De estas tres, ¿cuántas contesta con números y no con impresiones?

• ¿Cuántas solicitudes de soporte entraron el mes pasado y cuáles se repitieron?
• ¿Qué área pide más ayuda, y sobre qué?
• ¿Cuántas eran una falla del sistema y cuántas eran alguien que nunca recibió capacitación?

Cuando le hago la primera a un dueño, no me da un aproximado: me dice que no sabe. Ese número no existe en ningún lado.

La tercera es la que más dinero mueve: la falla se corrige, la falta de capacitación se enseña. Sin esa separación se paga soporte por algo que salía con una explicación.

Qué aparece cuando se cuentan las solicitudes

Desde adentro, el soporte se siente como mil cosas distintas todos los días. Cuando se registra unas semanas aparece otra cosa: un grupo pequeño de causas explica la mayor parte del ruido.

Permisos mal asignados desde que entró alguien nuevo. Un reporte que solo dos personas saben sacar. Una contraseña que caduca y siempre agarra a la misma área en el peor día del mes.

Ninguna de esas se arregla contestando más rápido. Se arreglan una vez, de raíz, y desaparecen. Pero para atacarlas hay que verlas, y para verlas hay que contarlas.

A quién mide el registro

Prefiero decir yo la parte incómoda, antes de que la descubra a los tres meses.

Contar el soporte no mide solo a los usuarios: me mide a mí. Si prometí algo para el mismo día y tardé dos, queda con fecha y hora, y usted lo ve sin preguntarme. Un proveedor que le pide confianza pero se resiste a que le tomen el tiempo le está diciendo algo.

Y mide a su equipo interno. A veces muestra que sistemas llevaba dos años desbordado pidiendo apoyo que nadie autorizó; a veces, lo contrario. Conviene saberlo con números.

Es el mismo principio del motor de base de datos: sin medición antes y después no hay mejora, hay opinión.

Qué tiene que dejar cada solicitud

Hasta aquí no hace falta comprar nada. Hace falta que cada solicitud deje un rastro que alguien más pueda consultar dentro de un año: que lo dicho quede pegado al caso y no al chat de quien lo atendió; que quede clasificado, para que a fin de mes haya una lista de temas y no una sensación; y que tenga hora de entrada y de cierre.

Eso lo hace cualquier herramienta seria, incluidas las de renta mensual por usuario. Yo uso Zammad por lo de siempre: se instala en su servidor y los datos son suyos. Si un día decide seguir sin mí, el sistema sigue operando con quien usted quiera.

Lo que convierte el registro en memoria es más chico: las respuestas que se repiten se escriben una vez y quedan a la mano. El segundo que pregunte recibe lo que ya se construyó. Lo demás es administración.

Cómo se maneja la resistencia

Poner tickets donde había WhatsApp molesta, y la molestia es legítima: antes el usuario escribía cinco palabras, ahora le piden llenar un formulario. Debajo hay dos miedos: perder velocidad y —el que nadie dice en voz alta— que el registro se use para evaluar personas. Así lo manejo:

No se le quita el canal a nadie el primer día. Que sigan escribiendo o llamando; al principio registrar es trabajo mío. Nadie adopta un sistema que llegó como castigo.

El ticket devuelve algo esa misma semana. Quien reporta sabe en qué va sin volver a preguntar y nota que la segunda vez le contestaron más rápido. Si solo sirve para que la dirección tenga tablero, lo van a esquivar.

Los primeros meses los números no tocan la evaluación de nadie, y eso se dice enfrente. En cuanto el registro se vuelve un arma, los tickets se redactan a la defensiva.

Se pone fecha para cerrar el canal viejo. Sin fecha, los dos conviven años y usted paga dos veces la misma atención.

Aun así tarda meses, y siempre queda alguien que nunca lo va a preferir. Prometerle una adopción limpia en tres semanas sería mentirle.

Lo que Zammad no le va a resolver

Es un sistema más: necesita quien lo actualice, lo respalde y responda cuando se caiga. Si no va a tener dueño adentro, no lo instale.

La base de conocimiento no se llena sola: alguien tiene que escribir lo que se resolvió, y ese rato a la semana hay que apartarlo. Sin eso, compró una bandeja de entrada más elegante.

La integración con WhatsApp existe, pero pide una cuenta de WhatsApp Business y un número dedicado: no es conectar el teléfono de nadie.

Lo más importante: los tickets no arreglan el sistema que falla. Si su aplicación se traba cinco veces por semana, Zammad documentará impecablemente las cinco. La causa está en otro lado: a veces en el motor de datos, a veces en cómo están amarrados los sistemas entre sí.

Cuándo no le hace falta esto

• Si son ocho personas en el mismo pasillo. El chat es más rápido que cualquier herramienta y ahí se aprende hablando.
• Si recibe dos o tres solicitudes por semana. No hay patrón que descubrir en ese volumen. Una libreta basta.
• Si nadie va a leer los datos. Un registro que nadie revisa cada mes es trabajo administrativo de más.
• Si el problema es un solo sistema inestable y ya sabe cuál es. Arréglelo primero. Registrar la misma falla ochenta veces no la arregla.

Empiece con una hoja, no con un sistema

Dos semanas de registro a mano, con tres datos por solicitud: quién pidió, qué pidió, cuándo quedó resuelto.

Al terminar va a tener, por primera vez, la lista de lo que le está costando tiempo. Con ella se decide si hace falta una herramienta o basta con capacitar a dos personas y corregir un permiso.

Si sale un patrón claro y un volumen que ya no cabe en la hoja, entonces sí conviene montar el registro en serio. Y si la mayoría resultan de CONTPAQi, con más razón: son preguntas que se repiten cada cierre y casi nunca quedan escritas.

La primera vez que se resuelve un problema se paga con trabajo. De la segunda en adelante se paga con intereses.