Pana · Investigación competitiva
Reconstrucción técnica y operativa de cómo Karta construyó su AI Concierge, y qué implica para la decisión de Customer Support de Pana — con el sistema de Tiers de Ka, hallazgos de underwriting, y el plan de staffing completo.
Abrir el benchmark completo ↗AXS · Experience Layer
Cómo Alden clasifica cada solicitud, quién la ejecuta, con cuánta autonomía, y qué se mide en cada paso. Basado en el Anexo de Tiers v1 y el doc de Orquestación v0.2 — los umbrales son v1 a propósito, se ajustan con la data del piloto.
Click en un rol para ver la propuesta operativa completa.
Alden (agente, guardrails, tool coverage), la app, TigerBeetle ledger, AXS360, integraciones (Rain, WhatsApp Business API, booking rail). Dueño del transcript-QA y el backlog de automatización que alimenta el log del concierge.
La voz humana de Alden: onboarding white-glove F&F, el playbook de servicio (tono, SLAs, matriz de escalación, ventanas de cobertura), toma de threads, conversaciones sensibles, dossiers de usuarios, retención y referidos.
Cada superficie que toca un usuario o un broker: copy del catálogo de beneficios (EN/ES), tarjeta + unboxing, materiales de lanzamiento, workflow de aprobación de partners — y co-staffea el concierge, dueño del diseño de gestos y del taste layer.
Dueño de la cola que interrumpe cualquier tier: fraude, señales AML/sanciones, contracargos, patrones de gasto anómalos — y la revisión manual de KYC que va más allá de lo que Alden puede automatizar. Nunca comunica la razón al usuario sin su propia aprobación.
Dueño del modelo de riesgo: define los criterios de aprobación/rechazo, límites de tarjeta, y los umbrales que alimentan las decisiones automatizadas de Alden. Revisa a mano los casos en zona gris — score borderline, documentación incompleta, señales mixtas de KYC.
El backstop detrás de la máscara: claims vía desks de Visa, operaciones de tarjeta con Rain (freeze, límites, disputas, tarjetas adicionales), legwork de fulfilment (LHC/Ten), staffing de ventanas de cobertura, higiene de casos en AXS360.
Esto define quién ejecuta cada solicitud, con cuánta autonomía, y por lo tanto cuánta gente hace falta en Ops. No es un dato aparte — es la base de todo lo que sigue.
Autonomía de Alden por monto — defaults, se ajustan con data
Hand-back y registro — la regla del loop
El LLM es la parte fácil. El trabajo defendible es la capa de señales sobre nuestra propia data.
Transacciones de tarjeta Rain (auth + posted, vía webhook), feed de StoneX, ledger de TigerBeetle, comportamiento en la app.
Limpieza de merchant, mapeo MCC, geo, e inferencia de viaje desde gasto de vuelos/hoteles.
Intención de viaje · eventos de nueva ciudad/aeropuerto · hitos (cumpleaños, aniversario) · patrones de categoría · anomalías · beneficios sin usar.
Respuestas reactivas + triggers proactivos (incluida activación de beneficios), dentro de los guardrails de autonomía y el ruteo por tier.
Arreglar (el producto falló) → T2·OPS. Lograr (la vida del usuario) → T2·CONCIERGE. Si una reserva del concierge falla, se queda en CONCIERGE — la promesa era nuestra. Si la tarjeta declinó a mitad de compra, es OPS — el producto era nuestro.
Sospecha de fraude, señales AML/sanciones, anomalías de KYC, abuso de contracargos, patrones de gasto anómalos. El caso sale del flujo de servicio hacia la cola de compliance, con owner propio, su propio SLA interno, y sin promesas de servicio al usuario más allá de "estamos revisando". No se escala "a Compliance o a Concierge" — son escaleras distintas. Servicio sube T0→T3; compliance interrumpe desde cualquier punto. Alden marca el trigger; nunca comunica la razón al usuario sin aprobación del owner de compliance.
Estudio comparativo: modelo in-house escalonado + expansión trilingüe vs. BPO (Horatio). Costos, cobertura, contratación y riesgos — portado del benchmark de Pana como referencia de metodología, adaptado a la capacidad que Ops de AXS necesita.
Cuatro formas de armar el equipo interno de Customer Support, de la más progresiva a la que cubre 24/7 desde el día uno — elige un botón para ver el detalle de cada una. En cualquiera de los 4 escenarios el equipo cubre los 3 canales (Voice, Chat y Email).
No solo qué es cada uno — sobre todo, a quién escalamos cuando un usuario está en medio de una gestión con ese proveedor y algo falla.
| Proveedor | Qué hace | Rol en el flujo de Alden | Si algo falla, escala a |
|---|---|---|---|
| Duffel | API de booking — vuelos, hoteles, autos. Search, book, ancillaries, cobro al cliente, manejo de orders. | Vuelos: Alden busca y reserva directo (Tier 1, sin humano). Hoteles/autos: el equipo humano de Concierge ejecuta la reserva sobre la misma infraestructura (T2·CONCIERGE). | Reason code API_FAILURE → T2·OPS si es un vuelo (Tier 1 falló); si es hotel/auto ya en manos humanas, el Concierge Team resuelve directo con Duffel o el proveedor final. |
| Rain | Emisión de tarjetas — infraestructura de pagos stablecoin para enterprise. Settlement rápido, cards, movimiento de dinero global. Maneja autorización y procesamiento de transacciones (compras, retiros ATM, punto de venta). | Es el processor detrás de toda operación de tarjeta: freeze, límites, disputas, tarjetas adicionales (T2·OPS), y la fuente del webhook de transacciones que alimenta el pipeline de señales. | Antes de escalar, Ops triagea: ¿balance suficiente? ¿tarjeta activa? ¿el merchant acepta la red? Si esos 3 chequeos pasan y sigue fallando, es API_FAILURE → T2·OPS toma control en <15min. Si es un patrón, no un caso puntual, se escala además a Product & Engineering (dueño de la integración). |
| WhatsApp Business | El canal — la infraestructura de mensajería sobre la que corre todo el front door del usuario con Alden. | Es la única puerta de entrada del usuario. Si funciona pero Alden no responde, es el escenario del bloque 04 (incidente de Alden). Si el canal mismo cae, es un escenario más severo — ver nota abajo. | SYSTEM_OUTAGE → Product & Engineering de inmediato. Sin canal alterno de voz (confirmado en el doc), no hay fallback de mensajería — solo queda contacto directo si Ops ya tiene el número/email del usuario por fuera del thread. |
| OpenTable / The Fork | Reservas de restaurantes en tiempo real. en progreso, aún no integrados | Mientras no estén integrados, toda reserva de restaurante es 100% manual — va directo a T2·CONCIERGE sin ninguna capa de API de por medio. | No aplica reason code de vendor todavía — cualquier problema con una reserva de restaurante hoy es un caso normal de Concierge, no una falla de sistema. |
El protocolo de triage de Rain (balance → tarjeta activa → merchant/red) viene del material de entrenamiento de CS de Pana Global, que también documenta a Rain como su processor — el mismo vendor sirve a ambos productos.
Todos los demás fallbacks del sistema (vendor cae → Ops, Alden cae → Ops toma los threads manualmente) asumen que el canal de WhatsApp sigue funcionando. Si WhatsApp Business API mismo cae, no hay ningún fallback definido — ni en el doc original ni en esta propuesta. Esto es lo más urgente de resolver antes de escalar el piloto: necesita un canal de contacto de emergencia (email, SMS directo) para los usuarios activos, algo que hoy no existe.
| Code | Cuándo se usa | Va a |
|---|---|---|
| API_FAILURE | Vendor o booking rail no respondió | T1 → T2·OPS (fallback automático) |
| KYC_MISMATCH | Documento no coincide con lo declarado | Compliance override |
| LIMIT_EXCEEDED | Monto sobre el guardrail de autonomía | T2/T3 según monto |
| JUDGMENT_REQUIRED | Petición de criterio, "mesa imposible", gesto | T2·CONCIERGE |
| MEMBER_ESCALATION | El usuario pidió humano explícitamente | T2·OPS o T3 |
| COMPLIANCE_FLAG | Fraude / AML / sanciones / contracargos | Compliance override |
| SYSTEM_OUTAGE | Alden mismo no está respondiendo | Ver bloque de incidente, más abajo |
Un reason code recurrente con alta frecuencia es candidato directo a la lista semanal de automatización que ya menciona el doc — esta tabla es lo que la alimenta.
Alden clasifica el caso como T2·OPS y lo registra en AXS360 con el reason code correspondiente.
Ops & Member Support toma el thread de forma invisible — el usuario sigue viendo una sola conversación con Alden.
Ejecuta según el tipo: filing de claim con el desk de Visa, operación de tarjeta vía Rain (freeze, límites, disputa, tarjeta adicional), o legwork de fulfilment (LHC/Ten).
Cierra con resumen escrito y hand-back a Alden — el usuario nunca re-explica el caso.
La señal llega vía Alden (detectada proactivamente) o vía solicitud directa del usuario.
AXS360 lo surfacea al Concierge Team como prompt de "diseñar un gesto" o de resolver la petición.
Member Relations Lead + Brand & Experience Lead aportan el criterio/taste; Alden o los desks ejecutan la parte operativa.
Hand-back a Alden con la promesa cumplida — o, si falla, el caso se queda en Concierge (la promesa era suya, no del producto).
Alden detecta un trigger de excepción (monto sobre el umbral, acción irreversible, conversación sensible) y nunca ejecuta solo.
Member Relations Lead toma la conversación directamente — Alden asiste con contexto, no decide.
Si el caso lo amerita (queja de un top usuario sin resolver, decisión de negocio), se escala a dirección.
Se mide por retención, referidos, y "cero quejas sin dueño" — no por tiempo de respuesta.
Alden detecta el trigger (fraude, AML/sanciones, anomalía KYC, contracargos, gasto anómalo) desde cualquier tier.
El caso sale del flujo de servicio hacia la cola de compliance — deja de ser un caso de CS/Concierge.
El owner de compliance investiga con su propio SLA interno; el usuario solo recibe "estamos revisando" hasta que ese owner apruebe comunicar más.
Alden nunca explica la razón del trigger al usuario sin luz verde explícita de compliance.
Muestra semanal: Member Relations Lead revisa 15–20% de los casos T2/T3 cerrados esa semana (más alto en las primeras semanas del piloto).
Revisión 100% en T3: todo caso de excepción pasa por un segundo par de ojos antes de considerarse cerrado — son decisiones sensibles o irreversibles.
Rúbrica: ¿se resolvió dentro del SLA? ¿el reason code fue el correcto? ¿el hand-back a Alden quedó bien documentado en AXS360?
El output no es solo un score — los casos mal etiquetados retroalimentan los umbrales de guardrails, no únicamente el backlog de automatización.
El doc cubre falla de API de vendor (fallback a Ops en <15min) pero no falla del propio orquestador. Son escenarios distintos: uno es un caso más con su reason code; el otro es un incidente.
Protocolo propuesto: WhatsApp Business sigue recibiendo mensajes aunque Alden no responda — Ops toma control manual de todos los threads entrantes con una plantilla pre-aprobada ("estamos experimentando una interrupción técnica, un miembro de nuestro equipo te atiende en breve"), y se escala de inmediato a Product & Engineering — no es una decisión de Ops, es un incidente.
Sin definir todavía: SLA de disponibilidad objetivo del propio Alden, y proceso de post-mortem — el doc no lo toca en absoluto.
| Caso | Tiempo para tomarlo |
|---|---|
| T2·OPS | <15 min en horario de cobertura |
| T2·CONCIERGE | <30 min en horario de cobertura |
| T3 — 1ª respuesta de Member Relations Lead | <30 min en horario, <2h fuera de horario |
| Compliance override — triage | <1h, 24/7 (sin ventana de cobertura) |
Los guardrails dicen QUÉ monto requiere humano. Esto complementa con CUÁNTO TARDA ese humano — el doc no lo define en ningún punto.
Sin API de beneficios hoy — el pilot corre sobre documentos + desks. Entitlements atados al BIN vía Rain; Alden guarda el mapa de entitlements. La Luxury Hotel Collection (Kiwi) la reserva un desk en nombre del usuario, con ops usando la máscara de Alden.
Los usuarios ya tienen Ten gratis vía Visa Infinite concierge (teléfono/web). La API paga es un upgrade, no un prerequisito — se activa post-piloto según lo que el canal gratis no pueda absorber. El usuario nunca ve "Ten", todo se lee como Alden.
Co-staffeado en el piloto (Member Relations + Brand & Experience), con Ops & Member Support como backstop. Cualquiera toma un thread de forma invisible; hand-back cuando la parte de alto contacto termina.
El doc original (v0.2) tenía esta decisión "parqueada a Q4" entre Odynn vs. Duffel-direct, sin firmar nada. Según la lista de proveedores más reciente, Duffel ya es el proveedor confirmado — ver la tabla de proveedores más arriba para el detalle operativo.
La meta es "T0 + T1 ≥ 70% de las solicitudes" — pero no dice qué pasa operativamente si no se llega.
Si se llega (≥70%): se activa Fase 2, dimensionando Ops permanente con el modelo de capacidad del bloque 01, ahora con data real en vez de supuestos.
Si no se llega (<70%): Fase 2 NO se activa automáticamente. Antes de sumar headcount se corre un sprint de automatización dirigido por los reason codes más frecuentes (bloque 02) — la falla es de producto, no se resuelve contratando más gente.
Propuesta de cadencia: esta decisión se revisa explícitamente en la semana 8 del piloto (Ago–Oct), dentro de la misma revisión semanal Producto+Ops+Concierge que ya existe.
No está en el doc de AXS — es la pieza que falta para que "Ops & Member Support" tenga un dueño único de la operación, no solo un equipo ejecutando casos.
Por cada request: intención · tier asignado · carril (OPS/CONCIERGE) · ruta de fulfilment (Visa / booking rail / desk / humano) · monto · tiempo humano invertido · resultado · reason code si escaló.
Ajustar umbrales, mover intenciones de tier, y medir la meta del piloto: T0 + T1 ≥ 70% de las solicitudes. Esta data es también la evidencia para el tranche 2 y la negociación con vendors — y el insumo directo del dashboard de CS performance que arma el Head de Operaciones.
Dueño de Alden, la app, TigerBeetle, AXS360 e integraciones. El mismo tipo de huecos que llenamos para Ops (capacidad, SLAs, QA) aplican aquí — por ejemplo: ¿cuántos ingenieros cubren el backlog de automatización que alimentan los reason codes? Aún no desarrollado.
Dueño de T3 y de la revisión de QA. Falta definir: la matriz de escalación exacta, y cuántos usuarios por Lead antes de necesitar un segundo. Aún no desarrollado.
Dueño del taste layer y del diseño de gestos en T2·CONCIERGE. Falta definir: cómo se prioriza qué gestos se ejecutan cuando hay más señales que capacidad de ejecutarlos. Aún no desarrollado.
Dueño de la escalera de compliance override (ver bloque 02 de Ops) — la única que interrumpe el flujo de servicio desde cualquier tier, sin pasar por Ops ni Concierge. Cubre: triggers de fraude, señales AML/sanciones, contracargos, y la revisión manual de KYC que Alden no puede resolver solo (documento no coincide, identidad no verificable, entidad de alto riesgo). Falta definir: SLA interno propio, y quién dentro de Compliance tiene autoridad para aprobar que Alden comunique la razón de un bloqueo al usuario. Aún no desarrollado.
Dueño del modelo de riesgo detrás de cada aprobación: construye y mantiene los criterios de elegibilidad, los límites de crédito/tarjeta por usuario, y los umbrales de score que determinan si una solicitud se aprueba sola, necesita más documentación, o se rechaza. Alimenta directamente los guardrails de Alden (bloque 02 de Ops) — un umbral mal calibrado ahí es un problema de Underwriting, no de Producto. También revisa a mano los casos borderline: score en zona gris, documentación incompleta, señales de KYC mixtas. Falta definir: con qué frecuencia se recalibra el modelo, y si las decisiones borderline pasan por el mismo reason-code system que usa Ops. Aún no desarrollado.