# Un prototipo que funciona. Y pruebas para decidir el siguiente paso. Un informe ilustrativo para un prototipo de clasificación de consultas. Los registros y resultados son ficticios y muestran cómo documentar la decisión de entrega. Explora una entrega de ejemplo para una PoC de clasificación de consultas: alcance, comprobaciones, incidencias y recomendación final. Este es el detalle que conviene acordar antes de empezar. **Informe de aceptación** · SUPPORT-POC / DEMO-01 Recomendación del ejemplo: aplazar el despliegue hasta comprobar los dos puntos pendientes. ## 01. El flujo acordado El equipo de este ejemplo recibe consultas de soporte y las asigna manualmente a una cola. Quiere comprobar si una herramienta puede proponer la cola adecuada sin ocultar el mensaje original a quien lo revisa. Las respuestas automáticas y las actualizaciones del CRM quedan fuera de esta PoC. El recorrido empieza con un mensaje ficticio y termina con una propuesta aceptada o un estado explícito de revisión manual. La persona responsable de soporte define las categorías. El desarrollador registra la versión y los datos de prueba. El responsable de la contratación decide la aceptación con respecto al alcance escrito. Mensaje de prueba → Categoría propuesta → Revisión humana → Decisión registrada ## 02. Qué contiene la entrega ### Un recorrido funcional 01 / Prototipo La entrada, la cola de revisión y el estado de la decisión en el entorno acordado. Debes poder recorrer la tarea completa e identificar las decisiones que siguen correspondiendo a una persona. ### Una demostración repetible 02 / Guion de demostración Condiciones iniciales, identificadores de los datos de prueba, pasos y resultado esperado. Un compañero que no asistió a la presentación debería poder repetir el recorrido sin depender únicamente de una grabación. ### El registro de comprobaciones 03 / Informe de aceptación Cada criterio conecta una entrada, un resultado esperado, una observación y un estado. El informe identifica la versión revisada y distingue un fallo de una comprobación que todavía no se ha realizado. ### Incidencias y decisiones 04 / Registro de riesgos Limitaciones conocidas, consecuencias para el siguiente paso, responsable y pruebas necesarias para cerrar cada punto. Los problemas pendientes siguen visibles aunque la demostración principal funcione bien. ### Código e instrucciones 05 / Notas de traspaso Entrega del código acordado, instalación, nombres de las variables de configuración, dependencias y recuperación. Los derechos, las licencias, los accesos y la responsabilidad del despliegue se rigen por el acuerdo del proyecto. ### Una recomendación concreta 06 / Próximo alcance Una propuesta escrita para continuar, reducir el alcance, reunir más información o detener el proyecto. El trabajo de producción tiene su propia estimación y condiciones; una PoC no se convierte automáticamente en un despliegue. ## 03. El registro de aceptación Los cuatro registros siguientes son ejemplos cumplimentados, no resultados de un cliente. Un informe útil conserva los casos difíciles y las pruebas que faltan junto a las comprobaciones satisfactorias. Abre cada registro para ver su detalle. ### DEMO-01: Una consulta clara de facturación **Resultado esperado** - **Entrada:** «Necesito una copia de mi última factura». Las categorías del ejemplo son Facturación y Acceso a la cuenta. - **Comportamiento esperado:** Proponer Facturación, mostrar el mensaje original y exigir que una persona confirme la clasificación. - **Notas de revisión:** El registro ficticio muestra Facturación, conserva el mensaje y mantiene la decisión pendiente de revisión. ### DEMO-02: Una consulta con dos posibles responsables **Requiere cambios** - **Entrada:** «No puedo entrar en mi cuenta para descargar la factura». Podrían corresponder ambas categorías. - **Comportamiento esperado:** Dejar la categoría sin decidir y pasar a revisión manual, conforme a la regla de ambigüedad acordada. - **Notas de revisión:** El registro del ejemplo eligió Facturación sin señalar la ambigüedad. Es necesario revisar la regla y repetir la comprobación. ### DEMO-03: Un envío vacío **Resultado esperado** - **Entrada:** Un mensaje que solo contiene espacios, enviado desde el mismo formulario. - **Comportamiento esperado:** Mostrar una validación comprensible y no solicitar una clasificación. Permitir que la persona corrija la entrada. - **Notas de revisión:** El ejemplo muestra la validación junto al campo y no crea un elemento en la cola de revisión. ### DEMO-04: El proveedor no está disponible **Sin comprobar** - **Entrada:** Un mensaje válido cuando no se puede acceder al proveedor de clasificación. - **Comportamiento esperado:** Conservar la entrada, mostrar el fallo y ofrecer la recuperación o revisión manual acordada sin duplicar el trabajo. - **Notas de revisión:** En este ejemplo no hay pruebas adjuntas. Una recuperación que no se ha comprobado no puede darse por válida. ## 04. Dos semanas, cuatro revisiones Esta secuencia ilustra una PoC acotada de dos semanas. Las fechas reales dependen del alcance, de los datos y de la disponibilidad para revisar. Cada hito deja algo que la empresa puede comprobar. ### Antes del día 1: Acordar la pregunta Confirmar el flujo, las categorías, los datos ficticios o autorizados, las exclusiones y los criterios. Designar a quien revisa y acordar el entorno antes de desarrollar. ### Fin de semana 1: Revisar el primer recorrido Recorrer la entrada, la propuesta y la revisión humana. Registrar los comentarios frente al alcance e identificar a tiempo los datos o accesos que faltan. ### Semana 2: Comprobar los límites Revisar entradas ambiguas, datos no válidos y los fallos acordados. Vincular las observaciones a una versión y repetir las comprobaciones afectadas por cada cambio. ### Revisión final: Tomar la decisión Repetir la demostración, revisar los pendientes y confirmar el traspaso. Registrar la aceptación o las condiciones restantes y decidir si se justifica otro encargo. ## 05. Decisión y tareas pendientes ### Decisión del ejemplo: aplazar el despliegue El recorrido principal se puede revisar, pero el ejemplo contiene una decisión ambigua incorrecta y una recuperación sin comprobar. Se recomienda una revisión adicional acotada. El informe no demuestra preparación para producción, ahorro ni precisión con tráfico real de clientes. ### Resolver las categorías solapadas Acordar qué consultas necesitan revisión manual, corregir el comportamiento y repetir DEMO-02 en una versión identificada antes de aceptar el resultado. **Responsable de la acción:** Responsable de soporte y desarrollador ### Documentar la recuperación Provocar la indisponibilidad del proveedor en el entorno de pruebas acordado. Registrar la entrada conservada, el error visible y el resultado de la recuperación antes del despliegue. **Responsable de la acción:** Desarrollador y revisor de la empresa ## 06. Revísalo con tu equipo 1. Pide a un compañero que repita la demostración con las instrucciones y los identificadores de prueba. Convierte los pasos que faltan en tareas de traspaso mientras el equipo que lo desarrolló sigue disponible. 2. Comprueba que cada criterio aceptado apunta a un resultado de la misma versión. Mantén visibles las correcciones y las pruebas pendientes; una buena demostración es solo una parte de la revisión. 3. Confirma el acceso al repositorio, la responsabilidad de la configuración y quién operará el siguiente entorno. Las credenciales se transfieren por el canal acordado y no se incluyen en el informe. 4. Registra la decisión en el proceso de aprobación de tu empresa. El Markdown es un formato de informe reutilizable; no incluye código fuente, un prototipo alojado ni una entrega de producción completa. ## Preguntas ### ¿Es una entrega real de un cliente? No. El flujo, los mensajes y las observaciones son ficticios y explican el formato del informe. El caso de producto propio enlazado en la web es una evidencia distinta. ### ¿Una PoC de dos semanas incluye el despliegue en producción? Solo incluye el trabajo que figure en el alcance escrito. Los accesos, el refuerzo técnico, la supervisión, el despliegue y el soporte deben tener responsables y condiciones de aceptación acordadas. ### ¿Qué ocurre si falla un criterio? Se registra la observación, su efecto y el responsable del siguiente paso. La empresa decide la aceptación según el acuerdo. Una petición nueva o un cambio de alcance se trata expresamente. ### ¿Podemos usar nuestra propia plantilla? Sí. Comparte el formato de aceptación, los requisitos de contratación y el proceso de revisión antes de delimitar el trabajo. Lo esencial es conectar criterio, prueba y decisión. ## Tu registro de aceptación ### Versión y entorno [ ] ### Alcance y criterio [ ] ### Datos de prueba y pasos [ ] ### Resultado esperado [ ] ### Resultado observado y ubicación de la prueba [ ] ### Estado e incidencia pendiente [ ] ### Responsable y fecha de revisión [ ] ### Decisión de la empresa [ ] [Consultar el siguiente alcance](https://urbanodx.com/es/contact/?package=poc&from=service_details&utm_source=urbanodx&utm_medium=sample&utm_campaign=202609-deliverables)