Del ticket al proyecto: cuando el cliente pide más de lo que vendiste

El ticket dice: "¿me pueden ayudar a configurar el reporte de comisiones?". Suena a media hora. Al abrirlo, resulta que las comisiones dependen de tres esquemas distintos, que dos vendedores tienen condiciones especiales y que nadie tiene por escrito cómo se calculan.

Lo que sigue es predecible. La persona de atención entra a averiguar, la conversación se alarga tres semanas, y en el tablero ese caso aparece como un ticket que lleva veintiún días abierto arruinando el indicador de todo el equipo.

El problema no es que el cliente haya pedido de más. Es que la solicitud entró por una puerta diseñada para otra cosa, y nadie la movió a la puerta correcta.

Las cuatro señales de que no es un ticket

Todas se pueden detectar en los primeros diez minutos, que es cuando conviene decidir:

1. Involucra a alguien que no es de atención. Si hay que meter a operaciones, a finanzas o a quien vendió, ya no es una respuesta: es una coordinación.
2. Nadie sabe cuánto va a tardar. Un ticket se estima en minutos u horas. Si la respuesta honesta a "¿cuánto es esto?" es "depende", es un proyecto.
3. El alcance está sin definir. "Ayúdenme a dejar esto funcionando" puede ser una tarde o dos meses. La ambigüedad no se resuelve trabajando: se resuelve acordando.
4. Tiene entregables. Si al final debe existir algo que hoy no existe —una configuración, un documento, una integración—, hay un producto de por medio y merece plan.

Con dos de las cuatro presentes, conviene detenerse antes de seguir trabajando. Cada hora que ese caso pasa como ticket es una hora que no está en ningún plan ni en ninguna cotización.

Por qué importa separarlos

No es una cuestión de orden: los dos se rompen mutuamente cuando se mezclan.

El proyecto arruina tus indicadores de atención. Un caso de tres semanas dentro de la cola de tickets destruye cualquier medición de tiempo de resolución, y con ella la posibilidad de saber si tus acuerdos se cumplen. La consecuencia práctica es que el equipo deja de creer en el tablero.

El ticket ahoga al proyecto. Un trabajo que necesita dos horas seguidas de concentración no sobrevive en una cola donde entran mensajes cada quince minutos. Se hace a pedazos, mal y tarde.

Y el trabajo se vuelve invisible. Es el costo más caro: tres semanas de una persona metidas en un ticket no aparecen en ningún reporte de capacidad. Cuando alguien pregunta por qué el equipo va lento, no hay forma de mostrarlo.

Cómo convertirlo sin que suene a negativa

El momento de la conversión es delicado porque el cliente pidió ayuda y puede oír "no te vamos a ayudar". La secuencia que funciona reencuadra el mismo hecho como un servicio mejor:

1. 1
   Reconocer lo que pidió con precisión

   Repetirle lo que entendiste, específico. "Quieres que el reporte calcule comisiones con los tres esquemas y las excepciones de dos vendedores." Con eso solo, el cliente suele darse cuenta del tamaño.

2. 2
   Explicar por qué merece más que un ticket

   No "esto no es soporte", sino "esto necesita que lo hagamos bien y para eso hay que definir tres cosas antes". El argumento es de calidad, no de reglamento.

3. 3
   Proponer el alcance por escrito

   Qué incluye, qué no, quién participa de su lado y para cuándo. Media página basta, y es lo que evita que el proyecto crezca sin control después.

4. 4
   Dejar cerrado el ticket con el enlace al proyecto

   El caso de atención se cierra correctamente —no se abandona— y queda apuntando a dónde continúa. El cliente ve que su solicitud avanzó, no que se archivó.

Qué se cobra y qué no

Es la pregunta incómoda y conviene tener una regla escrita antes de que aparezca el caso, porque decidirlo en caliente siempre termina en regalarlo.

La tercera fila es donde vive casi toda la ambigüedad. La regla práctica que resuelve la mayoría de los casos: la primera vez se hace y se enseña; a partir de la tercera, o el cliente lo hace o lo cotizas. Regalar indefinidamente no es generosidad, es un servicio no reconocido que después no se puede quitar.

El proyecto necesita cosas que el ticket no

Convertirlo no es cambiarle la etiqueta. Un proyecto que se lleva con las herramientas de un ticket fracasa igual. Cuatro cosas hacen falta:

• Un responsable único. No el equipo de atención: una persona con nombre que responde por la fecha de entrega.
• Tareas con orden y dependencias. Qué no puede empezar hasta que termine otra cosa. Es lo que hace que mover una fecha mueva lo que arrastra, en lugar de descubrirlo tarde.
• Compromisos del lado del cliente. La mayoría de los proyectos que se atrasan se atrasan esperando información del cliente. Si eso no está en el plan como una tarea con dueño y fecha, el atraso se te atribuye a ti.
• Un criterio de terminado. Escrito antes de empezar. Sin él, el proyecto se cierra cuando alguien se cansa, que nunca es un buen momento.

Y conviene que el proyecto viva colgado del mismo cliente que compró: quien entrega necesita ver qué se vendió, con qué condiciones y qué se prometió, sin preguntarle a quien vendió. Cuando esa información está en otro lado, la mitad de los problemas de entrega son de contexto, no de ejecución.

Cuándo NO conviene convertirlo

La conversión también se aplica de más, y hacerlo tiene su propio costo.

Cuando de verdad es corto. Si son dos horas de trabajo claro, montar un proyecto con plan y alcance cuesta más que hacerlo. La ceremonia debe ser proporcional.

Cuando es la tercera vez que pasa lo mismo. Si tres clientes pidieron lo mismo este mes, el trabajo no es un proyecto por cliente: es un cambio en el producto o un instructivo público. Convertirlo en proyecto tres veces es tratar el síntoma.

Cuando el cliente está molesto por un problema tuyo. Responder a una queja legítima con un proceso formal y una cotización es la peor lectura posible. Ahí primero se resuelve y después, en frío, se habla del alcance.

Cuando el volumen no lo justifica. Con dos casos así al trimestre, la regla escrita es más burocracia que beneficio y basta con el criterio de quien atiende. La formalización empieza a pagar cuando esto pasa varias veces al mes.

Cómo afecta a tus acuerdos de servicio

Hay una consecuencia práctica que conviene dejar por escrito desde el principio: los compromisos de tiempo de atención no aplican a los proyectos. Un acuerdo que promete resolución en dos días no puede cubrir un trabajo de tres semanas, y no aclararlo es la forma más común de incumplir algo que nunca se debió comprometer.

La redacción que funciona distingue entre atender un problema —que sí tiene tiempo comprometido— y ejecutar una solicitud de cambio, que tiene su propio plan con sus propias fechas. Cómo se fijan esos tiempos sin firmar incumplimientos está en Acuerdos de servicio: cómo definir tiempos que sí puedas cumplir.

Por dónde empezar

Revisa los casos abiertos que llevan más de dos semanas. Suelen ser pocos, y casi siempre son proyectos disfrazados; ésa es la lista que está distorsionando todos tus indicadores de atención.

Sácalos de la cola, dales responsable, alcance y fecha, y avisa al cliente. Vas a recuperar dos cosas al mismo tiempo: un indicador de atención que describe la realidad, como el que se ordena en Bandeja compartida: que ningún correo se quede sin respuesta, y la visibilidad de un trabajo que hasta hoy nadie sabía que estaba ocurriendo.