# Convierte una idea de automatización en un encargo bien definido. Un buzón de soporte ficticio convertido en una primera prueba concreta. Úsalo para preparar tu briefing; no es un informe de cliente. Sigue el recorrido de una bandeja de soporte: del trabajo manual actual a un primer alcance verificable. Revisa los datos, las dudas, las comprobaciones y la recomendación antes de adaptar el ejemplo a tu equipo. **Diagnóstico del flujo** · SUPPORT-SCOPE / EXAMPLE-01 Recomendación del ejemplo: aclarar las categorías antes de contratar la PoC. ## 01. Dibujar la tarea actual Una persona lee cada consulta, busca al cliente y asigna un responsable. La automatización propuesta se limita a sugerir la cola de destino. Todavía no hay un ahorro de tiempo medido, y el documento no presupone que haga falta un modelo de IA. En este ejemplo ficticio hay una pequeña muestra sin datos identificativos y un borrador de categorías. Falta confirmar si las clasificaciones anteriores son coherentes y quién autoriza el acceso a los datos. El diagnóstico muestra esas carencias antes de contratar el desarrollo. Leer la consulta → Buscar el contexto → Elegir una cola → Asignar responsable ## 02. Qué contiene el documento ### El mapa del flujo 01 / Situación actual Dónde empieza y termina la tarea, qué herramientas utiliza y quién toma cada decisión. Incluye las excepciones: una consulta incompleta también necesita una persona responsable. ### Un inventario de datos 02 / Información disponible Ejemplos, campos, definiciones de categorías y restricciones de acceso. Separa lo que ya está disponible de lo que alguien debe aprobar, anonimizar o recopilar. ### El problema concreto 03 / Pregunta que resolver Identifica la tarea repetida y la pregunta que debe responder el primer desarrollo. Aquí se evalúa si una sugerencia ayuda al revisor, no si se puede automatizar todo el servicio de soporte. ### El primer recorrido 04 / Límites del alcance El mensaje llega a una pantalla con una categoría propuesta y un estado de revisión. Una persona confirma la decisión. Las respuestas automáticas, las escrituras en el CRM y el despliegue quedan fuera. ### Los criterios propuestos 05 / Pruebas que acordar Entradas normales, ambiguas, vacías y no admitidas, con el comportamiento esperado para cada una. Define cómo pasa a revisión manual un resultado ausente antes de implementar el recorrido principal. ### Una recomendación 06 / Próxima acción Decide si conviene aclarar los datos, probar una regla sencilla o delimitar una PoC. Anota el motivo, la persona responsable y la información que falta. El diagnóstico puede recomendar preparación en lugar de desarrollo. ## 03. Definir las primeras pruebas Son comprobaciones propuestas para el siguiente encargo, no pruebas ya superadas. Acuerda las entradas y el comportamiento con el responsable del flujo. El informe final añadirá la versión, las observaciones reales y la decisión de aceptación. ### SCOPE-01: Una consulta con categoría clara **Prueba propuesta** - **Entrada:** Un mensaje autorizado o ficticio que el responsable de soporte pueda clasificar sin desacuerdo. - **Comportamiento esperado:** Mostrar el mensaje y la categoría propuesta. La decisión final sigue correspondiendo a quien revisa. - **Notas de revisión:** Preparar ejemplos de todas las categorías incluidas. Reservar un conjunto separado para revisar, de modo que la demostración no sea la única prueba. ### SCOPE-02: Una consulta ambigua **Regla por acordar** - **Entrada:** Un mensaje que podría ir a dos colas o que no aporta suficiente información para elegir una. - **Comportamiento esperado:** Mostrar revisión manual y conservar el origen. La regla de clasificación define cuándo no se debe proponer una categoría. - **Notas de revisión:** Soporte debe resolver primero los solapamientos. Registrar los desacuerdos en lugar de convertir etiquetas dudosas en datos de referencia. ### SCOPE-03: Entrada vacía o no admitida **Límite por acordar** - **Entrada:** Un mensaje vacío o un idioma o adjunto que el alcance inicial no admite. - **Comportamiento esperado:** Explicar la limitación y ofrecer una corrección o vía manual útil. No tratar la entrada como una consulta clasificada válida. - **Notas de revisión:** Enumerar los campos, idiomas y formatos admitidos. Cada tipo de entrada adicional requiere una decisión de alcance. ### SCOPE-04: Fallo de una dependencia **Prueba propuesta** - **Entrada:** Un mensaje válido para el que el proveedor de clasificación no devuelve un resultado utilizable. - **Comportamiento esperado:** Conservar el mensaje, mostrar el fallo y aplicar la política de reintento o revisión manual. Evitar decisiones duplicadas. - **Notas de revisión:** Designar al responsable del fallo y acordar la recuperación antes de integrar en producción. La primera prueba puede provocar el error de forma controlada. ## 04. De la pregunta al alcance El diagnóstico avanza según la información disponible. Estas son fases de trabajo, no fechas comprometidas. El plazo del paquete y el alcance final se confirman con tus datos antes de empezar. ### Preparar: Traer una tarea real Describe el desencadenante, los pasos, las herramientas y el responsable. Comparte un ejemplo representativo por el canal acordado y retira la información sensible cuando corresponda. ### Revisar: Seguir las decisiones Recorre un caso normal y una excepción. Separa las reglas acordadas de las suposiciones sobre datos, accesos, volumen o comportamiento de los usuarios. ### Delimitar: Fijar el primer alcance Elige un resultado útil y escribe pruebas, exclusiones y dependencias. Compara una mejora manual, una regla determinista y un paso asistido por IA con la tarea concreta. ### Decidir: Entregar la recomendación Devuelve el mapa, las carencias y el siguiente paso propuesto. Si procede desarrollar, acuerda por separado los entregables, el precio y las condiciones de aceptación. ## 05. Elegir el siguiente paso ### Decisión del ejemplo: aclarar primero las reglas La muestra permite empezar, pero las categorías solapadas impedirían evaluar bien el resultado. Se propone resolver las etiquetas y comprobar una regla de clasificación sencilla antes de pagar una PoC basada en modelos. Todavía no hay una estimación de ahorro justificable. ### Definir las categorías Revisar mensajes discutidos, escribir las reglas y decidir cuándo se requiere revisión manual. Utilizar las mismas definiciones para la referencia inicial y el prototipo posterior. **Responsable de la acción:** Responsable de soporte ### Confirmar datos y accesos Confirmar qué ejemplos se pueden compartir, sus limitaciones y quién aprueba el siguiente entorno. Tener permiso no demuestra que la muestra sea representativa. **Responsable de la acción:** Responsable de datos y empresa contratante ## 06. Preparar tu propio encargo 1. Sustituye el ejemplo de soporte por una tarea que tu equipo haga hoy. Describe el inicio y el resultado de forma observable e identifica quién revisará la salida. 2. Enumera las pruebas disponibles y las dudas pendientes. Deja el volumen, el coste y el tiempo como desconocidos hasta medirlos; no conviertas suposiciones en un caso de negocio. 3. Elige un caso normal, uno ambiguo y un fallo. Escribe qué debe ver y hacer una persona en cada situación y qué operaciones no realizará la primera versión. 4. Comparte el documento con los responsables de negocio y tecnología. El Markdown incluye el ejemplo y un encargo en blanco para adaptar. Es material de preparación, no un contrato de trabajo aprobado. ## Preguntas ### ¿Tenemos que elegir primero un modelo de IA? No. Empieza por la tarea, los datos y las reglas de revisión. El diagnóstico puede identificar una solución con reglas sencillas o mostrar que primero hace falta preparar los datos. ### ¿Podemos empezar sin una API disponible? Una exportación sin datos identificativos o un ejemplo ficticio puede ayudar a delimitar el alcance. El documento debe indicar qué permite comprobar y qué supuestos de integración siguen pendientes. ### ¿La descarga incluye un diagnóstico de pago? No. El ejemplo y el encargo en blanco son gratuitos. Un diagnóstico de pago revisa tu flujo y tus datos dentro del alcance acordado y recomienda un siguiente paso para tu situación. ### ¿Qué hacemos después? Puedes utilizar el documento internamente, resolver los pendientes o acordar un desarrollo. El paquete es un punto de partida: entregables, exclusiones, aceptación y calendario requieren un acuerdo escrito. ## Tu propio encargo ### Flujo y responsable de negocio [ ] ### Inicio y pasos actuales [ ] ### Datos disponibles y responsable del acceso [ ] ### Resultado útil [ ] ### Casos normales, ambiguos y de fallo [ ] ### Exclusiones [ ] ### Pruebas que faltan [ ] ### Responsable de la decisión y fecha de revisión [ ] [Consultar el siguiente alcance](https://urbanodx.com/es/contact/?package=teardown&from=service_details&utm_source=urbanodx&utm_medium=sample&utm_campaign=202609-deliverables)