Cómo rechazar una solicitud sin perder a la clienta

Cerrar el círculo suele significar decirle a alguien que su solicitud se lanzó. La mitad difícil, para la que la mayoría de sistemas de seguimiento no tiene ningún proceso, es decir que no. La mayoría de las solicitudes de funciones nunca se lanzan, lo que significa que la mayor parte del cierre de círculo que un producto realmente debe a sus usuarias es un rechazo, no un anuncio, y un rechazo mal gestionado cuesta más buena voluntad de la que habría costado el silencio. Bien gestionado, puede costar casi nada, porque lo que la mayoría de quienes solicitan algo quieren de verdad es saber que fueron escuchadas, no la función en sí.

¿Por qué importa rechazar bien tanto como lanzar bien?

Porque el silencio se lee como un rechazo sin explicación, y un no explicado se lee como atención. Quien no oye nada asume que su solicitud fue ignorada o se perdió, y ambas conclusiones le enseñan a dejar de molestarse en preguntar, que es el mismo resultado que obtiene un producto con un rechazo real, solo que llega más despacio y con más resentimiento por el camino. Una respuesta que dice que no, con claridad y con un motivo, cierra el círculo tan completamente como una función lanzada, y lo hace más rápido.

¿Qué hace que un rechazo caiga mal?

Casi siempre tres cosas, combinadas. Genericidad: un “gracias por tu feedback” enlatado que no menciona qué se pidió realmente se lee como si no se hubiera leído en absoluto, aunque sí se haya leído. Retraso: un rechazo que llega seis meses después de la solicitud, cuando quien preguntó ya olvidó haberlo hecho, se siente peor que un no rápido, porque implica que la solicitud estuvo parada en vez de considerada y rechazada. Y un motivo que no aguanta: “no está en nuestro roadmap” no responde nada, mientras que “esto requeriría rediseñar cómo funcionan los permisos, y no planeamos tocar eso este año” le da a quien preguntó algo que realmente puede evaluar y, si le importa lo suficiente, escalar o rodear.

¿Qué debería decir realmente un buen rechazo?

Cuatro cosas, en este orden: un reconocimiento que nombre la solicitud concreta, no una paráfrasis genérica; el motivo real, dicho con honestidad incluso cuando el motivo honesto es “esto no encaja con hacia dónde va el producto” en vez de una excusa más suave; si la puerta está cerrada o simplemente no está abierta ahora, porque eso necesita tonos muy distintos; y, cuando exista, una alternativa que atienda la necesidad subyacente aunque no sea la función pedida literalmente.

Hola Jamie,

Gracias por la solicitud de añadir importación masiva por CSV para
invitaciones de equipo. Lo revisamos, y no lo vamos a construir:
nuestro flujo de invitaciones se basa en revisar individualmente cada
miembro nuevo por seguridad, y la importación masiva iría en contra
de eso por diseño, no por descuido.

Si el problema real es invitar a un equipo grande rápido, la API
soporta invitaciones individuales por script, lo que te da casi toda
la velocidad sin saltarte la revisión: [enlace]. Avísame si quieres
ayuda para configurarlo.

Fíjate en lo que hace esto que una plantilla no puede: nombra la función real, da un motivo ligado a una decisión de diseño real en vez de una política vaga, y ofrece un camino que resuelve el problema subyacente en vez de solo cerrar el ticket.

¿En qué se diferencia de cerrar el círculo con una función lanzada?

La mecánica es parecida, el tono no. Cerrar el círculo de feedback con el cliente cubre el caso lanzado, donde el mensaje son buenas noticias y el riesgo principal es olvidar enviarlo. Un rechazo son malas noticias, o al menos noticias no deseadas, y necesita más cuidado en el motivo dado y menos automatización en la entrega: una notificación de función lanzada puede ser un comentario con plantilla disparado por un cambio de estado, pero un rechazo que se lee como plantilla es exactamente el fallo que este enfoque entero intenta evitar. Ambos comparten un requisito, eso sí: la solicitud original tiene que seguir vinculada a quien la hizo, la misma disciplina de seguimiento que cubre seguimiento de solicitudes de funciones, o no hay forma de enviar ninguno de los dos mensajes individualmente.

¿Debería un rechazo ser público, como un estado en un roadmap público?

Normalmente el motivo concreto no, aunque el estado sí. Roadmap público cubre etiquetas de estado que quien pidió algo puede consultar sin volver a preguntar, y un estado “rechazado” o “no planeado” puede formar parte de ese sistema. Pero el motivo detallado, sobre todo cuando toca prioridades internas o contexto poco favorecedor, suele valer más en la respuesta individual que en una página de estado pública, donde la misma redacción tiene que funcionar para cada lectora en vez de para la única persona que realmente preguntó.

¿Merece cada solicitud rechazada una respuesta individual?

Toda solicitud de una persona nombrada y contactable sí, al menos una breve. Solicitudes de alto volumen, duplicadas o anónimas son la excepción: agrupar solicitudes similares y responder una vez por grupo, o actualizar una etiqueta de estado compartida, es razonable cuando las respuestas individuales de verdad no escalan. La línea a mantener es que “no podemos responder a todos individualmente” debería ser una restricción operativa real, comprobada contra el volumen real, no una excusa por defecto para saltarse una respuesta que habría tomado dos minutos.

FAQ

¿Es mejor rechazar rápido con un motivo débil, o tomarse tiempo para uno bueno? Rápido, con un motivo honesto, gana a cualquiera de los dos por separado. Una respuesta rápida con un motivo real, aunque sea breve, supera a una respuesta lenta con uno pulido; el propio retraso es parte de lo que daña la confianza.

¿Debería un rechazo prometer alguna vez revisar la solicitud más adelante? Solo si es realmente probable y hay un mecanismo para revisarla de verdad, como una etiqueta que la haga resurgir en un ciclo de planificación. Un vago “lo tendremos en cuenta” sin ese mecanismo es funcionalmente lo mismo que el silencio, solo que dicho con más amabilidad.

¿Y si el motivo honesto es algo que la empresa no puede compartir, como una preocupación competitiva? Dilo directamente en vez de inventar un motivo más suave. “No podemos compartir el razonamiento concreto aquí, pero esto no es algo que planeemos construir” es más honesto, y se respeta más, que una explicación inventada que se cae ante una pregunta de seguimiento.

¿Rechazar una solicitud significa que debería borrarse del seguimiento? No. Consérvala, etiquetada como rechazada con el motivo, para que forme parte del patrón contra el que se agrupa la siguiente solicitud similar, y para que un contexto cambiado más adelante (una nueva integración, una nueva prioridad de equipo) pueda hacerla resurgir en vez de empezar la evaluación de cero.

Las afirmaciones técnicas de este artículo no se han revisado de forma independiente. Si algo está mal, avísanos y lo corregiremos.

Relacionado en changeloop: Documentación para desarrolladores, Herramientas de changelog comparadas