Cómo registrar una petición funcional de un cliente SaaS sin confundirla con una incidencia

Separa comportamiento esperado, problema de uso y nueva necesidad para que producto reciba contexto comparable.

Equipo enginerIT· 3 min de lectura

Una función solicitada es una hipótesis sobre la necesidad

Un cliente puede pedir un botón, una exportación o una integración cuando en realidad intenta resolver un problema de operación. Si cada frase se convierte directamente en desarrollo, el backlog se llena de soluciones aisladas y solicitudes duplicadas. Un registro útil conserva la necesidad, el flujo actual y el contexto; la persona de producto decide si existe una mejora común o una configuración diferente.

Distingue defecto, duda y petición de capacidad

Compara lo que ocurrió con el funcionamiento documentado y la tarea que el cliente intentaba completar. Si el producto se comporta de forma distinta a lo esperado, puede ser una incidencia; si falta comprensión, puede ser una consulta. No conviertas una falla en petición de función sin investigar.

Guarda la solución que propuso el cliente como propuesta

Anota “quiero un botón” por separado de la necesidad que explicó. Esa idea puede ser una buena pista, pero no establece el diseño correcto. Mantén el lenguaje original y resume el problema sin atribuir beneficios que la persona no mencionó.

Describe la tarea y el momento en el flujo

Registra qué persona trata de hacer, qué información tiene, qué pasos sigue y en qué parte se atasca. Usa ejemplos autorizados que eviten datos de producción innecesarios. Una frase como “sería más rápido” necesita concretar qué parte hoy obliga a cambiar de pantalla o repetir información.

Identifica alcance dentro de la cuenta

Comprueba producto, plan o módulo, rol y configuración de la instancia. Una función disponible en otra edición no es necesariamente un defecto. El equipo de producto revisa acceso y documentación antes de considerar que la petición aplica a un cambio general.

Busca solicitudes relacionadas sin borrar diferencias

Agrupa casos que describen una tarea semejante y muestra cuenta, fecha, contexto y necesidad. La misma etiqueta puede esconder usos distintos. Conserva las diferencias para que la síntesis no convierta tres peticiones aisladas en un requisito universal sin evidencia.

Pregunta por frecuencia e impacto con datos comprobables

Solicita una estimación que el cliente pueda explicar: cuántas veces sucede, qué rol interviene y qué alternativa usa actualmente. Distingue cifra declarada de métrica extraída del producto. No inventes ahorro de tiempo ni priorices por el número de comentarios solamente.

Comunica recepción sin prometer desarrollo

El cliente recibe referencia, síntesis y próximo punto de actualización si se ha acordado. Evita decir que la función está prevista, en roadmap o llegará en una versión si producto no lo confirmó. La petición puede analizarse, rechazarse, configurarse o agruparse con otras; cada estado necesita lenguaje distinto.

Cierra la conversación con decisión y aprendizaje

Registra quién evaluó, fecha, criterio aplicado y respuesta compartida. Si se implementó, enlaza el cambio con la solicitud y confirma la versión. Si se resolvió por soporte o configuración, documenta ese camino para evitar tratar el mismo caso como desarrollo pendiente.

Antes de ponerlo en marcha

✓ Cuenta y flujo relacionado
✓ Tarea que el cliente intenta completar
✓ Comportamiento actual comprobado
✓ Solución sugerida separada del problema
✓ Usuarios o procesos afectados con fuente
✓ Estado y responsable de respuesta

Revisa una lista de peticiones y separa problema expresado, solución sugerida y decisión pendiente.

Comprueba qué solicitudes representan un comportamiento roto y cuáles describen necesidades de producto; evita contar frases parecidas como demanda confirmada.

Cuéntanos qué necesitas →