«¿Podéis añadir exportación a Excel?» «Estaría genial poder duplicar un proyecto.» «Lo que necesitamos de verdad es una integración con nuestro ERP.»
En cualquier empresa de software, soporte recibe peticiones de funcionalidades cada semana. Y en la mayoría acaban igual: alguien responde «¡gracias, lo trasladamos al equipo!», la petición se queda en una conversación cerrada y nadie vuelve a saber de ella. Ni el equipo de producto, que no sabe cuántos clientes la pidieron, ni el cliente, que no se entera cuando por fin sale.
Gestionarlas bien no exige una herramienta de roadmap. Exige tres hábitos: recogerlas siempre igual, contarlas y cerrar el círculo con el cliente.
La respuesta corta
Para gestionar las peticiones de funcionalidades: regístralas todas en un mismo sitio, con quién la pide, qué problema quiere resolver y qué peso tiene ese cliente; agrúpalas y cuéntalas para que producto decida con datos y no con la última conversación; responde al cliente con honestidad, sin prometer fechas que no controlas; y cuando la funcionalidad salga, avisa a cada cliente que la pidió. Lo más valioso de cada petición no es la solución que propone el cliente, sino el problema que describe.
Paso 1: recoger el problema, no solo la petición
Un cliente que pide «exportación a Excel» probablemente quiere otra cosa: pasar datos a su contable, hacer un informe que el producto no hace, o hacer una copia de seguridad. Cada una se resuelve de forma distinta.
Por eso, cuando llega una petición, la pregunta útil es: «¿Qué necesitas hacer con eso?». La respuesta es lo que hay que registrar.
Paso 2: registrar siempre igual
Cada petición, con cuatro datos:
| Dato | Ejemplo |
|---|---|
| Qué pide | Exportar proyectos a Excel |
| Para qué | Mandar el informe mensual a su cliente |
| Quién | Empresa X, plan Pro, cliente desde hace dos años |
| Cuándo | Fecha de la conversación |
Dónde, importa menos que hacerlo siempre en el mismo sitio. Puede ser una etiqueta en la bandeja de soporte, una hoja compartida o una incidencia en la herramienta del equipo técnico. Con GitHub conectado, por ejemplo, el agente de Intake puede crear el issue desde la conversación o vincularla a uno que ya existe.
Paso 3: agrupar y contar
Una petición aislada es una anécdota. Treinta clientes pidiendo resolver el mismo problema es una decisión.
Cada cierto tiempo —una vez al mes basta—, alguien agrupa las peticiones que resuelven el mismo problema y las cuenta. Con dos columnas más:
- Cuántos clientes la han pedido.
- Qué peso tienen: ingresos, plan, riesgo de baja.
Así, la conversación con producto deja de ser «un cliente me ha dicho» y pasa a ser «veintidós cuentas, tres de ellas grandes, quieren mandar informes a sus clientes y hoy no pueden».
Si quien atiende es un agente de IA, la clasificación de las conversaciones por tema ayuda a ver de un vistazo cuántas veces aparece cada petición, sin depender de que alguien se acuerde de etiquetarlas.
Paso 4: qué responder al cliente
La tentación es prometer para quedar bien. Es un error: una promesa incumplida pesa más que un «no» honesto.
Tres respuestas según el caso:
Si está prevista: > Es algo que tenemos previsto. No te puedo dar fecha todavía, pero te he apuntado y te escribo en cuanto esté disponible.
Si no está prevista: > Ahora mismo no está en nuestros planes, pero lo he registrado con tu caso para que el equipo de producto lo tenga en cuenta. Mientras tanto, puedes hacerlo así: [alternativa].
Si ya existe una forma de hacerlo: > Esto ya se puede hacer, aunque no es obvio: [pasos]. Si no te encaja para lo que necesitas, cuéntame más y lo registro.
La tercera es más común de lo que parece: una parte de las peticiones son funcionalidades que ya existen y el cliente no ha encontrado. Eso no es un problema de producto, es de documentación o de diseño.
Paso 5: cerrar el círculo
Cuando una funcionalidad sale, avisa a cada cliente que la pidió. Un mensaje personal —«¿te acuerdas de que pediste duplicar proyectos? Ya está disponible»— hace más por la relación con ese cliente que cualquier campaña.
Es el paso que casi nadie hace y el que más se nota. Si las peticiones están registradas con quién las pidió, cuesta minutos. Y si la petición estaba vinculada a una incidencia, el aviso al cerrarla puede ser automático.
Errores frecuentes
- Decir «lo trasladamos» y no registrarlo. El cliente lo nota cuando pregunta tres meses después.
- Contar votos sin peso. Diez clientes gratuitos no pesan lo mismo que uno que paga el 10 % de tus ingresos.
- Copiar la solución del cliente. El cliente describe bien su problema y mal la solución.
- Prometer fechas. Las fechas de producto cambian; la confianza no se recupera igual.
- Un tablero público sin respuesta. Si los clientes votan y nadie contesta, es peor que no tenerlo.
Preguntas frecuentes
¿Dónde registro las peticiones de funcionalidades?
En un solo sitio, siempre el mismo: una etiqueta en la bandeja de soporte, una hoja compartida o la herramienta de incidencias del equipo técnico. Lo importante es que nadie las tenga que buscar en conversaciones cerradas.
¿Hay que responder a todas las peticiones?
Sí, aunque sea para decir que no está prevista. El cliente que pide algo quiere saber que se le ha escuchado.
¿Cómo decido qué funcionalidades hacer?
Con el número de clientes que comparten el problema, el peso de esos clientes y el coste de resolverlo. Las peticiones son una fuente, no la única.
¿Conviene un portal público de votaciones?
Solo si alguien lo mantiene y responde. Un portal abandonado transmite que las peticiones no le importan a nadie.
¿Cómo aviso a los clientes cuando sale algo que pidieron?
Con un mensaje personal a cada uno. Si las peticiones están registradas con el cliente, es una tarea de minutos.
Para seguir
- Informe mensual de soporte, con plantilla
- Cómo decir que no a una función que pide un cliente
- Cómo escribir notas de versión que se lean
- Cómo conseguir reportes de bugs útiles
- Niveles de soporte técnico en una empresa de software
- Cómo mejorar la retención de clientes en un SaaS
- Soporte con IA para equipos de producto
