Porque cobramos por media hora?

Para las empresas que recién se lanzan en temas de sopoprte en el mundo del software, y para nuestros clientes que quizás se preguntan porqué cobramos un mínimo de media hora por intervención, me gustaría explicar un poco mejor lo que hacemos.

Nuestro negocio, básicamente, es desarrollar sistemas de información (en particular Chamilo, Drupal y Dolibarr) y dar soporte sobre ellos (esto incluye también cuidar los servidores que los alojan). Toda esta actividad radica en los servicios “humanos” de personas altamente calificadas para brindar estos servicios a quien los necesiten.

Para definirlo de forma simplística, alquilamos actividad cerebral, es decir que damos acceso a nuestros clientes a mentes brillantes para que resuelvan problemas para ellos, y les permitimos alquilar estas mentes brillantes solo cuando las necesiten.

Por lo tanto, también estamos tomando una gran cantidad de riesgo al poner estas mentes brillantes a su disposición (si nadie las quiere por un tiempo, tenemos que seguir asgurando sus ingresos).

También pueden haber cantidades de discusiones sobre la manera en la cual un cierto problema es considerado resuelto o no, pues los problemas de software muchas veces se indican de forma interpretada, dando las impresiones personales de cada uno porque cada uno tiene circonstancias particulares y vive sus problemas de maneras distintas. Mucho de este trabajo no puede ser contabilizado sin generar frustraciones. Por lo tanto, el trabajo de nuestros responsables de soporte, responsables del diálogo con los clientes y de ser más explícitos para facilitar este diálogo, está contabilizado como parte del tiempo de resolución del problema.

Analizando el tiempo necesario para un ingeniero para resolver un problema, aparecen de forma más clara las razones por las cuales se considera un tiempo mínimo de atención. Estos son tiempos mínimos aproximados basados en la realidad de la mayoría de los casos que atendemos. Se considera (en este caso) que la ficha del cliente, indicando los accesos comunes al sistema del cliente ya fueron registrados:

• 60s: Lectura del correo/mensaje del cliente
• 240s: Registro de la incidencia (incluye: clasificación, designación de título claro que permitirá luego apoyarse en esta incidencia para cortar el tiempo de tratamiento de otras, indicación copiado-pegado del detalle del reporte por el cliente, asignación de las personas que deben estar al tanto de esta incidencia, asignación de un tiempo aproximado de resolución, asignación de un momento aproximado de entrega, definición de dependencias con otras incidencias, etc)
• 60s: Conexión al sistema del cliente (o a una copia local) y reproducción del problema
• 60s: Creación de nuevo contexto de prueba que permita reproducir la incidencia en un sistema que no afecte al cliente (para el tiempo de trabajo en este)
• 300s: Investigación y, quizás, resolución del problema (se trata de un tiempo mínimo, en caso de poder aprovechar a su máximo la experiencia de nuestros ingenieros, pero no son raros los casos en los cuales esta resolución pueda tomar más de 2h)
• 120s: Verificar, una última vez, que la corrección resolvió el problema
• 60s: Registrar el cambio en nuestros repositorios de historial para cada cliente – esto implica también vincularlo con el código de la incidencia y darle un comentario adecuado
• 180s: Reportar al cliente (y en la incidencia) sobre la resolución (o no) de la incidencia
• 120s: Terminar, reportar su tiempo consumido, tomar 1 minuto de relajación para pasar a otra tarea

En total, el tratamiento de una sola incidencia representa un trabajo mínimo de 20 minutos, y en promedio (con la resolución de temas más complejos) más de media hora.

Por esta razón, nos es imposible asegurar, en buenas condiciones de seriedad y concentración, asegurar un tiempo de intervención menor a 20 minutos.