Casos por sector para el proyecto

La organización

Banco Surandino es un banco múltiple peruano de tamaño mediano, con sede en Lima y 84 agencias. Atiende a unos 620,000 clientes de banca personal y pequeña empresa: cuentas, tarjetas, créditos personales, vehiculares y para microempresa. Su canal digital creció fuerte, pero la atención no creció al mismo ritmo, y hay presión por bajar costos sin perder satisfacción.

Situación y dolores

Recibe unos 38,000 contactos al mes entre teléfono, chat de la app y web.

• Colas en horas punta y fin de mes; la primera respuesta en chat supera los 6 minutos y el abandono telefónico llega al 18% en picos.
• El 64% de los contactos son las mismas preguntas informativas: requisitos de un crédito, comisiones, cómo bloquear una tarjeta, cargos no reconocidos, horarios.
• El cliente quiere resolver a cualquier hora; fuera de horario solo queda un IVR limitado.
• Asesores calificados gastan media jornada recitando requisitos y tarifas de bajo valor.

Fuentes que sí puede usar

• Tarifario vigente: comisiones, tasas referenciales, mantenimiento, ITF.
• Requisitos y características de cada producto (créditos, tarjetas, cuentas).
• Manual de "qué hacer ante": tarjeta perdida, cargo no reconocido, fraude.
• FAQ de banca digital; reglamento y contrato marco; directorio de agencias; cartilla de derechos del usuario financiero.

Lo que NO puede usar ni responder

• Saldos, movimientos o deuda de un cliente concreto (transaccional, va por API con autenticación).
• Aprobar, rechazar o pre-evaluar un crédito, o subir una línea (decisión con impacto financiero).
• Asesoría o recomendaciones de inversión personalizadas.
• Claves, tokens o números completos de tarjeta; y la gestión de un fraude en curso.

Preguntas típicas

• "¿Qué requisitos piden para un crédito personal?" (informativa, dentro de alcance)
• "¿Cuánto cobran por mantenimiento de la cuenta sueldo?" (tarifario)
• "Perdí mi tarjeta, ¿qué hago?" (el procedimiento se informa, pero el bloqueo se escala)
• "¿Cuánto tengo de saldo y por qué me cobraron ayer?" (transaccional y personal, no contestable)
• "Creo que me clonaron la tarjeta." (fraude: primer paso informativo y escalar de inmediato)

Restricciones y riesgos

• Regulación financiera y de transparencia: informar mal una comisión o un requisito genera reclamos formales.
• Datos financieros sensibles: el bot nunca pide ni expone claves, tokens o números de tarjeta.
• Fraude y suplantación: el bot no autentica ni ejecuta operaciones, deriva.
• Error catastrófico e irreversible: una respuesta equivocada sobre dinero puede causar pérdida, por eso el fallback humano es obligatorio en todo lo sensible.

El reto para el equipo

Propongan un chatbot que caiga en el cuadrante verde: alto impacto, alta factibilidad. La clave es delimitar hacia lo seguro, no "que resuelva todo el banco". Redúzcanlo a informar requisitos, tarifas y procedimientos citando el tarifario y el reglamento, y escalar todo lo transaccional o sensible. Así conservan el grueso del volumen (el 64% repetitivo) y eliminan el riesgo. Apunten a un groundedness muy alto (SLA sugerido cercano al 98%) y a un 0% de respuestas sobre saldos, fraude o asesoría sin derivar.

La organización

AndinaShop es una tienda en línea peruana de moda, hogar y tecnología de gama media, con operación 100% e-commerce y dos tiendas físicas en Lima que también sirven de puntos de recojo. Vende unas 9,500 referencias, despacha a todo el país, tiene 1.2 millones de cuentas y un programa de lealtad. Es el sector más "verde" del taller: alto volumen y error casi siempre recuperable.

Situación y dolores

Recibe unos 55,000 contactos al mes (WhatsApp, chat web, correo, redes), con picos de hasta 3x en campañas.

• Colas estacionales brutales en campañas como Cyber; el equipo no escala al ritmo de la demanda.
• Repetición extrema (Pareto puro): el 80% del volumen son las mismas dudas sobre devoluciones, envíos, cambios de talla, pagos, facturación y puntos.
• Compran de noche y en fines de semana, y se frustran si la respuesta llega al día siguiente.
• Agentes contestando "¿en cuántos días llega a Cusco?" en vez de resolver un paquete extraviado real.

Fuentes que sí puede usar

• Política de devoluciones, cambios de talla o color, y cancelaciones.
• Garantías y manejo de productos dañados o defectuosos.
• Plazos y costos de envío por destino; opciones de recojo en tienda.
• Métodos de pago, facturación; reglas del programa de puntos; horarios y política de privacidad.

Lo que NO puede usar ni responder

• Estado o ubicación de un pedido concreto ("¿dónde está mi pedido #4821?"): transaccional, API de tracking.
• Stock o disponibilidad en vivo de un producto (transaccional).
• Datos de un cliente específico: dirección, historial, medios de pago guardados.
• Negociaciones ad hoc ("¿me das descuento si no devuelvo?"): decisión, se escala.

Preguntas típicas

• "¿Cuántos días tengo para devolver un producto?" (política, dentro de alcance)
• "¿Cuánto cuesta el envío a Trujillo y en cuántos días llega?" (dentro de alcance)
• "Quiero cambiar la talla de un polo, ¿cómo hago?" (dentro de alcance)
• "¿Dónde está mi pedido? Lo compré hace 3 días." (transaccional, derivar a tracking)
• "Si no me devuelven el dinero hoy voy a denunciarlos." (queja emocional: respuesta empática y escalar)

Restricciones y riesgos

• Protección al consumidor: informar mal un plazo o un costo genera reclamos y, si es sistemático, sanciones.
• Datos personales: no exponer direcciones, historial ni medios de pago.
• Riesgo reputacional en redes: una respuesta fría a una queja pública escala rápido; la escalación empática importa.
• Bajo riesgo de daño grave, lo que hace al sector ideal para automatizar ampliamente.

El reto para el equipo

Diseñen el chatbot en el cuadrante verde aprovechando que aquí hay mucho contenido informativo legítimo. El reto fino es separar limpio lo informativo (RAG sobre el centro de ayuda) de lo transaccional (API de tracking, que solo se señala, no se construye) y no caer en "resoluciones falsas" durante los picos. Este sector permite metas de deflexión más ambiciosas que banca o salud porque el riesgo es menor; el CES, el esfuerzo del cliente, es su métrica de experiencia estrella.

La organización

Instituto Tecnológico Pacífico (ITP) es una institución privada de educación superior técnica en el Perú, con sede en Lima y filiales en Chiclayo y Huancayo. Ofrece carreras técnicas de 3 años y programas cortos, con unos 14,000 estudiantes activos. Las áreas que más atienden público son Admisiones, Servicios Académicos y Finanzas estudiantiles. Es el caso canónico de admisiones que el curso usa como ejemplo verde.

Situación y dolores

Durante las campañas de admisión y matrícula la demanda se multiplica.

• En semanas pico, Admisiones recibe unas 1,200 consultas repetitivas por semana y 3 personas no se dan abasto.
• Las mismas preguntas: requisitos de admisión, fechas y cronograma, costos, becas, cómo matricularse, cómo pedir un certificado.
• Postulantes y apoderados consultan de noche y fines de semana, con prisa por una fecha límite.
• Asesores que deberían orientar casos complejos pasan el día recitando fechas y requisitos.

Fuentes que sí puede usar

• Reglamento de admisión vigente y requisitos por modalidad o carrera.
• Calendario académico: inscripción, exámenes, matrícula, inicio de clases.
• Tabla de aranceles, pensiones y formas de pago.
• Reglamento de becas y descuentos; guía de trámites; reglamento del estudiante; horarios de oficinas.

Lo que NO puede usar ni responder

• Estado de la postulación, nota de examen o resultado de un postulante concreto (transaccional y personal).
• Saldo de pensiones o deuda de un estudiante específico (transaccional).
• Decidir una beca, una admisión o una convalidación (decisión con juicio, va a un humano).
• Notas, expediente o datos personales de un alumno.

Preguntas típicas

• "¿Qué requisitos piden para postular a analítica de datos?" (dentro de alcance)
• "¿Cuándo es el examen y hasta cuándo me inscribo?" (calendario)
• "¿Cuánto cuesta la pensión y qué formas de pago hay?" (aranceles)
• "¿Pasé el examen? Quiero mi resultado." (transaccional y personal, derivar)
• "¿Me darán la beca? Mi familia tuvo un problema económico." (decisión sensible, escalar a Bienestar con tacto)

Restricciones y riesgos

• Información oficial y vinculante: una fecha o un requisito mal informado puede hacer que un postulante pierda el ciclo.
• Datos del estudiante: no exponer notas, resultados ni datos personales.
• Casos sensibles de bienestar (situación económica, salud mental, conducta) se derivan con empatía.
• El conocimiento cambia por campaña, no minuto a minuto: estable y buen candidato a RAG.

El reto para el equipo

Diseñen el chatbot en el cuadrante verde: este es el ejemplo de libro del curso. El caso "FAQ de admisiones" es deliberadamente factible. El reto fino está en no dejar que el bot prometa resultados ni decida becas o admisiones, y en mantener el corpus sincronizado con el calendario de cada ciclo. Apunten a una deflexión alta de consultas informativas y a un groundedness alto contra el reglamento y el calendario vigentes.

La organización

Red de Salud Vida Plena es una red privada de clínicas y centros médicos en el Perú, con 3 clínicas y 6 centros ambulatorios. Ofrece consulta externa, laboratorio, imágenes, chequeos y un programa de afiliados. El área de Contact Center y Admisión gestiona citas, orientación de servicios y consultas administrativas. Es el sector más exigente en delimitación: el error clínico puede ser catastrófico e irreversible.

Situación y dolores

Recibe unos 42,000 contactos al mes (teléfono, WhatsApp, web). El volumen se reparte así:

• 45% pregunta horarios, ubicación de sedes y servicios disponibles.
• 25% pregunta requisitos y preparación de un estudio (ayuno, qué llevar, cobertura del seguro).
• 20% quiere agendar, reprogramar o cancelar una cita (transaccional).
• 10% son consultas clínicas ("¿este síntoma es grave?", "¿qué tomo para...?").

Hay colas telefónicas largas, mucha repetición informativa, y personal de salud consumido por preguntas de bajo valor.

Fuentes que sí puede usar

• Directorio de sedes, horarios de atención y de cada servicio.
• Cartera de servicios y especialidades por sede.
• Instructivos de preparación para estudios: ayuno, indicaciones previas, documentos a llevar.
• Tarifario de servicios particulares, lista de aseguradoras en convenio y FAQ administrativa.

Lo que NO puede usar ni responder

• Cualquier orientación clínica o diagnóstica (síntomas, gravedad, qué medicamento tomar): riesgo catastrófico, humano obligatorio.
• Historia clínica, resultados o datos de salud de un paciente concreto (datos especialmente protegidos).
• Estado o confirmación de una cita específica y disponibilidad de agenda en vivo (transaccional).
• Cobertura exacta del caso de un paciente con su seguro (depende de su póliza, se escala).

Preguntas típicas

• "¿En qué sedes hacen resonancia y en qué horario?" (dentro de alcance)
• "¿Necesito ayuno para el perfil lipídico y de cuántas horas?" (preparación de estudio)
• "¿Atienden con el seguro X y qué documentos llevo?" (convenios y requisitos)
• "Tengo dolor de pecho desde anoche, ¿es grave?" (posible emergencia: mensaje de seguridad y derivar de inmediato)
• "¿Cuáles fueron los resultados de mi análisis?" (dato de salud personal, no contestable)

Restricciones y riesgos

• Riesgo a la vida: el bot no triajea, no diagnostica ni recomienda tratamientos; ante cualquier indicio clínico da un mensaje de seguridad y escala.
• Datos de salud con protección reforzada: no accede, pide ni expone historia clínica ni resultados.
• Emergencias: debe detectar lenguaje de urgencia ("dolor de pecho", "no puede respirar") y derivar sin demora.
• El caso viable se limita estrictamente a lo administrativo y de preparación de estudios, nunca a lo clínico.

El reto para el equipo

Este es el caso más exigente en delimitación: aquí "delimitar es restar". Diseñen un chatbot que solo atienda lo administrativo e informativo (horarios, servicios y preparación de estudios concentran cerca del 70% del volumen) y que escale agresivamente. Necesitan una regla de escalación robusta con detección de emergencia y un mensaje de seguridad estándar para síntomas. La métrica número uno es el 0% de respuestas a consultas clínicas sin derivar, un SLA duro e innegociable; nunca prioricen contención sobre seguridad.

La organización

ConectaPerú Telecom es un operador ficticio que ofrece internet fijo por fibra, telefonía móvil y planes empaquetados de internet y TV, con unos 2.3 millones de clientes. Es un negocio de alto volumen y márgenes ajustados donde la atención es un centro de costo enorme y una fuente constante de quejas. El riesgo principal no es la vida ni el dinero, sino confundir RAG (documentos) con troubleshooting o transacción en vivo (API).

Situación y dolores

Recibe del orden de 190,000 contactos al mes.

• Colas y saturación crónica, sobre todo cuando una incidencia de red dispara llamadas simultáneas.
• Repetición masiva informativa: planes y precios, cobertura por zona, cómo pagar el recibo, configurar el router, portabilidad, permanencia y penalidades.
• El cliente quiere resolver a cualquier hora y muchas dudas simples no necesitan a un humano.
• Agentes explicando "¿cómo cambio mi clave WiFi?" en vez de gestionar averías reales.

Fuentes que sí puede usar

• Catálogo de planes vigentes: características, velocidades, precios, beneficios.
• Criterios de cobertura por zona y tecnología.
• Guías de configuración estándar: router, WiFi, APN móvil, TV.
• Procedimientos de portabilidad, alta y baja, permanencia y penalidades; FAQ de facturación genérica; contrato de servicio.

Lo que NO puede usar ni responder

• Estado de la red o de una avería en vivo en la zona del cliente (tiempo real, va por sistemas, no RAG).
• Diagnóstico personalizado de "por qué no me funciona" (depende de telemetría, es agéntico).
• Saldo, consumo o monto exacto del recibo de un cliente concreto (transaccional y personal).
• Ejecutar gestiones como dar de baja o cambiar de plan (transacción con efecto contractual, se escala).

Preguntas típicas

• "¿Qué planes de fibra tienen y a qué velocidad?" (catálogo, dentro de alcance)
• "¿Cómo cambio la clave de mi WiFi?" (guía de configuración)
• "¿Qué necesito para portar mi número?" (requisitos de portabilidad)
• "Se me cayó el internet, ¿por qué no funciona?" (pasos genéricos de la guía y, si persiste, escalar)
• "Quiero darme de baja." (gestión contractual y posible queja, escalar a retención)

Restricciones y riesgos

• Regulación de telecomunicaciones: informar mal sobre permanencia, penalidades o portabilidad genera reclamos y riesgo regulatorio.
• Datos personales: no exponer consumo, recibos ni datos de la línea.
• Confusión RAG contra API (riesgo de diseño número uno): muchas consultas parecen contestables pero requieren datos vivos.
• Riesgo no catastrófico para la persona, pero alto impacto reputacional: un bot que atrapa al cliente sin resolver dispara detractores.

El reto para el equipo

Diseñen un chatbot que se quede en el cuadrante verde resistiendo la tentación de la "apuesta". Recorten el caso a lo informativo y de configuración estable (planes, cobertura general, guías, portabilidad, facturación genérica). La arquitectura debe separar nítidamente RAG (documentos) de lo que sería integración agéntica o API (estado de red, recibo, gestiones), sin construir la API, solo señalándola. La mitigación clave: no fingir que sabe el estado de la red. Si quieren atacar las averías, recorten de "diagnosticar la falla" a "guiar pasos estándar y escalar si no resuelve".