En nuestros procedimientos del servicio de soporte tenemos que tomar algunas decisiones según las importancia de los problemas. Y más de una vez me han preguntado como evaluar la importancia de un problema. Llaman dos clientes con problemas distintos y uno puede ser importante y el otro no. ¿Cómo saberlo?
Es algo similar a la labor que debe hacer el responsable de un servicio de urgencia en un hospital. Recibe un enfermo y tiene que asignarle prioridad según la importancia de la dolencia. Quizás haya casos claros. Alguien puede llegar con un resfriado y otra persona puede tener un infarto. Pero en otras ocasiones puede ser algo difícil distinguir un malestar sin importancia de una dolencia grave.
Alguien puede pensar que el criterio para decidir que un problema de un cliente es importante es que el cliente te diga que es importante. Es un dato sí, pero solo un dato. Seguir ese criterio potenciaría los hipocondríacos en los hospitales y ocasionaría algún que otro muerto. En informática supondría un mal servicio. Es un dato, insisto, a tener en cuenta, no lo evites ni lo desprecies, pero no te quedes en él.
En realidad hay datos más relevantes. El primero es el coste del problema. El coste puede ser de tiempo o de dinero (porque se pierdan ventas) Dos ejemplos:
- 1.- La aplicación se ha vuelto lenta. Pido el balance y tarda 2 minutos cuando antes tardaba 10 segundos
- 2.- La aplicación se ha vuelto lenta. Al meter las líneas de ventas se para y tengo que esperar 5 segundos para pasar a la siguiente.
¿Cual es el más importante? En realidad depende de las circunstancias. Pero en un caso típico una empresa típica (que no sea una asesoría) sacará un balace ese día, no más y tendrá que escribir cien, o incluso mil líneas de ventas (piensa en un supermercado). Así que:
- 1.- Coste 2 minutos
- 2.- Coste 500 x 5 segundos = 2500 segundos = 42 minutos
Recuerdo un caso curioso. Un cliente nos llamó porque no le funcionaba un proceso de importación de unas facturas de compras desde otro ordenador. Había hecho una importación de muchos datos y todo había ido bien menos ese fichero. Vimos que efectivamente había alguna pega porque el proceso no terminaba. Estuvimos investigando y en un momento determinado tras varias pruebas y una conexión remota decidimos copiar el fichero para ver el motivo. Al verlo pensamos que había algún problema en la copia. Tenía muy pocos bytes, así que deducimos que estaba corrupto o algo parecido. Accedimos de nuevo, pero no, parecía que todo bien. Resulta que lo que quería importar era ... una factura con una línea. En escribirla a mano hubiera tardado 15-20 segundos y llevábamos más de una hora solucionando el problema. Era algo que no era necesario repetir en el futuro, puesto que no habría más cambio de ordenador al menos en años.
En segundo lugar, detrás del coste, debes considerar las consecuencias. Hay errores que permiten trabajar, el usuario los considera poco importantes y sin embargo pueden tener consecuencias a largo plazo. Ejemplo, un aviso de errores detectados en el disco duro de un ordenador. El aviso significa que puedes seguir trabajando pero ... ¡que en un rato te puedes quedar sin información!
