Documento histórico
Este documento se conserva solo para trazabilidad. Consulte el índice maestro para la fuente vigente.
Documento histórico — no usar como fuente de decisiones actuales
Reemplazado por la versión canónica del 2026-07-11. Conservar solo como trazabilidad histórica.
Modelo de negocio (AS-IS → TO-BE)¶
Descripción del proceso actual (cómo se hacen hoy los envíos a Cuba desde EE.UU.) y del proceso objetivo al que apunta IslaBox. Este documento justifica la existencia del sistema y define el cambio que se quiere conseguir.
1. Contexto del negocio¶
El flujo de envío de compras online desde Estados Unidos hacia Cuba es, en la práctica, un proceso artesanal, fragmentado y propenso a errores. La mayoría de los usuarios finales (compradores cubanosamericanos radicados en EE.UU. que envían a familiares en Cuba) no cuentan con una herramienta que guíe el proceso de extremo a extremo.
Actores del proceso actual¶
| Actor | Rol actual |
|---|---|
| Comprador en EE.UU. | Compra online, recibe en su casa, luego re-envía por su cuenta o pide ayuda |
| Casillero / courier en Miami | Recibe paquetes, los identifica manualmente y los consolida |
| Agencia de envío a Cuba | Transporta, pasa aduana, entrega en domicilio del destinatario |
| Destinatario en Cuba | Recibe en su casa sin visibilidad del estado del envío |
| Operadores humanos (WhatsApp) | Resuelven dudas, confirman trackings, gestionan incidencias |
2. Modelo AS-IS (cómo funciona hoy)¶
Flujo real del usuario, paso a paso¶
flowchart TD
A["Usuario quiere enviar a Cuba"] --> B["Busca en Google 'envío a Cuba desde Miami'"]
B --> C["Encuentra un casillero por WhatsApp"]
C --> D["Pregunta al operador por chat"]
D --> E["Le pasan la dirección del casillero"]
E --> F["Usuario copia y pega en Amazon / SHEIN / Temu"]
F --> G{"¿Puso el identificador?"}
G -- "No" --> H["Paquete llega y nadie sabe de quién es"]
G -- "Sí" --> I["Paquete llega y se identifica"]
I --> J["El operador confirma recepción por WhatsApp"]
J --> K["El operador pregunta qué hacer"]
K --> L["El usuario decide: enviar individual o consolidar"]
L --> M["Cotizan por WhatsApp"]
M --> N["El usuario paga (Zelle, efectivo, transferencia)"]
N --> O["El operador despacha"]
O --> P["El destinatario recibe (sin notificación)"]
H --> Q["Cola de conciliación manual"]
Q --> R["Se pierde tiempo buscando al dueño"]Problemas detectados¶
| # | Problema | Impacto | Frecuencia |
|---|---|---|---|
| 1 | La dirección del casillero se comparte a mano por WhatsApp | Errores de tipeo, direcciones incompletas | Alta |
| 2 | El usuario no sabe dónde poner su identificador (Address Line 1 vs Line 2 vs Company) en cada tienda | Paquetes no identificados | Alta |
| 3 | No hay prealerta sistemática: el operador se entera cuando el paquete ya llegó | Conciliación manual costosa | Alta |
| 4 | El operador resuelve todo por WhatsApp: estado, costos, incidencias | Saturación del chat, demoras | Alta |
| 5 | No hay cálculo de costo anticipado: el usuario se entera del precio al final | Sorpresa, fricción, abandono | Media |
| 6 | No hay trazabilidad: el usuario no sabe dónde está su paquete | Ansiedad, llamadas al operador | Alta |
| 7 | El almacenaje se cobra de forma irregular y sin aviso previo | Conflictos, reclamos | Media |
| 8 | El KYC no existe: cualquier persona puede enviar sin verificación | Riesgo regulatorio y de fraude | Alta |
| 9 | No hay categorización de productos estándar | Errores en aduana, retención de paquetes | Media |
| 10 | La consolidación se hace a criterio del operador, sin transparencia | Costo no óptimo, desconfianza | Media |
| 11 | El pago es informal (Zelle, efectivo, transferencias) | Sin factura, sin trazabilidad fiscal | Alta |
| 12 | El destinatario en Cuba no tiene visibilidad del envío | Dependencia total del remitente | Alta |
| 13 | No hay programa de referidos ni fidelización | Crecimiento lento, basado en boca a boca | Media |
| 14 | No hay módulo informativo de aduana: el usuario llega a Cuba y se sorprende con cargos | Conflictos post-envío | Alta |
| 15 | La conciliación de paquetes sin identificar es 100% manual | Carga operativa, paquetes perdidos | Media |
Métricas actuales (estimadas, sin fuente verificable)¶
| Métrica | Valor estimado |
|---|---|
| % de paquetes que llegan con identificador correcto | ~50-60% |
| Tiempo promedio de identificación de un paquete sin prealerta | 2-7 días |
| % de usuarios que reportan la compra antes de que llegue | < 20% |
| Carga operativa del WhatsApp | 60-80% del tiempo del operador |
| Paquetes perdidos o no reclamados al año | Estimado 5-10% |
3. Modelo TO-BE (cómo funcionará con IslaBox)¶
Visión general¶
flowchart TD
A["Usuario se registra en la app (teléfono +1)"] --> B["Recibe identificador CP-NNNNNN-D"]
B --> C["Ve y copia la dirección del casillero en un toque"]
C --> D["Consulta tutoriales de Amazon/SHEIN/Temu"]
D --> E["Compra en la tienda online"]
E --> F["Reporta la compra en la app (prealerta)"]
F --> G["El paquete llega al almacén"]
G --> H["El operador lo identifica con el identificador"]
H --> I["El sistema vincula con la prealerta"]
I --> J["El usuario recibe push de recibido"]
J --> K{"¿Qué quiere hacer?"}
K -- "Enviar individual" --> L["Cotización → Pago → Despacho"]
K -- "Consolidar" --> M["Selecciona otros paquetes → Cotización → Pago"]
L --> N["Tracking en tiempo real"]
M --> N
N --> O["Entrega en Cuba + notificación al destinatario (vía usuario)"]Cambios clave respecto al AS-IS¶
| # | Cambio | Beneficio |
|---|---|---|
| 1 | Dirección del casillero copiable desde la app | Cero errores de tipeo |
| 2 | Tutoriales paso a paso por tienda con capturas | El usuario sabe dónde poner cada dato |
| 3 | Prealerta sistemática desde la app | El operador sabe qué esperar; reduce conciliación |
| 4 | Notificaciones push en cada cambio de estado | El usuario no necesita preguntar por WhatsApp |
| 5 | Cotización anticipada antes del pago | Cero sorpresas en el costo |
| 6 | Tracking visual del estado del envío | Visibilidad total, menos ansiedad |
| 7 | Días gratis de almacenaje configurables + alertas push antes del vencimiento | Cargos transparentes, no sorpresivos |
| 8 | KYC obligatorio antes del primer envío | Cumplimiento regulatorio, antifraude |
| 9 | 15 categorías operativas con flags regulatorios | Aduana sin sorpresas, menos retenciones |
| 10 | Consolidación guiada en la app | Costo óptimo, transparencia |
| 11 | Pago formal con factura desglosada (servicio, envío, aduana, etc.) | Trazabilidad fiscal |
| 12 | El destinatario en Cuba aparece como contacto del usuario | Cero dependencia de WhatsApp |
| 13 | Programa de referidos con niveles y crédito (Fase 2) | Crecimiento orgánico, retención |
| 14 | Módulo informativo de aduana con la Res. 175/2022 | Usuario educado, menos conflictos |
| 15 | Colas operativas en el backoffice (conciliación, KYC, etc.) | Operación eficiente, menos paquetes perdidos |
Métricas objetivo (KPIs del MVP)¶
| Métrica | Valor actual estimado | Objetivo MVP |
|---|---|---|
| % de paquetes con identificador correcto | 50-60% | > 95% |
| Tiempo de identificación sin prealerta | 2-7 días | < 24 h (cola de conciliación) |
| % de usuarios que reportan la compra | < 20% | > 70% (con onboarding) |
| Carga del WhatsApp | 60-80% del tiempo | < 30% (consultas residuales) |
| Paquetes perdidos al año | 5-10% | < 1% (con prealerta + identificador) |
| Tiempo promedio de identificación de paquetes conciliados | n/d | < 2 h (con búsqueda por tracking) |
| Tasa de incidencias aduanales | n/d | < 5% (con categorización previa) |
4. Análisis de brechas (AS-IS → TO-BE)¶
Brechas de proceso¶
| Proceso AS-IS | Proceso TO-BE | Brecha |
|---|---|---|
| Identificación manual por WhatsApp | Identificador único + prealerta + escaneo en almacén | Necesidad de sistema de casillero_codes + módulo de prealerta + app móvil |
| Cotización a mano | Cotización automática en app, basada en peso + vía + servicios | Necesidad de módulo de tarifas + Quote/QuoteItem |
| Pago por ZZelle/efectivo | Pago formal con factura desglosada | Necesidad de Payment + Invoice + integración con Stripe (Fase 2) |
| Sin verificación de identidad | KYC obligatorio para despachar | Necesidad de kyc_records + revisión manual en backoffice |
| Estado solo por WhatsApp | Tracking visual con eventos | Necesidad de package_events + notificaciones push |
| Sin almacenamiento controlado | Almacenaje con días gratis, alertas y cargos | Necesidad de timer + jobs diarios + Cargo |
Brechas tecnológicas¶
| Capa | AS-IS (mental) | TO-BE |
|---|---|---|
| App móvil | ❌ No existe | ✅ Android nativo (Kotlin/Compose) + iOS (Fase 2) |
| Backend | ❌ Manual | ✅ Django + FastAPI + PostgreSQL + Redis + MinIO |
| Backoffice | ✅ Django Admin con colas operativas | |
| Archivos | ❌ n/d | ✅ MinIO con URLs prefirmadas |
| Notificaciones | ✅ Push + email + WhatsApp (Fase 3) |
Decisiones operativas resueltas 2026-06-06 (preguntas.md): casillero propio en Miami (no de tercero); agencia aliada provee API (contrato pendiente); IslaBox opera como intermediario digital, por lo que actualmente no requiere licencia de courier propia, ya que el transporte internacional y la entrada a Cuba son gestionados por la agencia aliada autorizada. Esta estructura debe validarse legalmente antes del lanzamiento (en particular, obligaciones regulatorias de OFAC y del Departamento de Transporte de EE.UU. si IslaBox fuera tratada como freight forwarder o intermediario de transporte).
Brechas de información¶
| Información | AS-IS | TO-BE |
|---|---|---|
| Catálogo de categorías | ❌ No existe | ✅ 15 categorías con flags de la Res. 175/2022 |
| Tarifas vigentes | 📝 En la cabeza del operador | ✅ Configurables en backend, visibles en app |
| Estados de paquete | 📝 5-6 estados a ojo | ✅ 16 estados oficiales + transiciones |
| Reglas de aduana | 📝 Lo que sepa el operador | ✅ Documentadas y administrables |
| Días gratis de almacenaje | 📝 Variable, a negociar | ✅ 15 días por defecto (configurable globalmente) |
| Costo por día extra | 📝 Variable | ✅ $0.50 USD por defecto (configurable globalmente) |
5. Supuestos del modelo¶
- El casillero físico de IslaBox está (o estará) ubicado en Miami, FL, accesible a las principales tiendas online de EE.UU.
- La agencia aliada de transporte a Cuba puede recibir guías maestras de consolidación y entregarlas a domicilio en Cuba.
- La Aduana cubana aplica la Resolución 175/2022 como normativa vigente (verificable, con fecha de última actualización).
- Los usuarios aceptan instalar una app móvil y proporcionar documento de identidad.
- El envío desde Miami a Cuba es viable económicamente para el usuario final con los precios definidos ($2.40/lb barco, $3.35/lb avión).
- Existe un mercado suficientemente grande de personas en EE.UU. que envían regularmente a Cuba para sostener el modelo.
6. Riesgos del modelo de negocio¶
| Riesgo | Probabilidad | Impacto | Mitigación |
|---|---|---|---|
| La agencia aliada cambia precios o deja de operar | Media | Alto | Contratos a mediano plazo; diseñar para multi-agencia |
| Cuba endurece restricciones aduanales | Media | Alto | Módulo de aduana administrable; alertas a usuarios |
| El mercado objetivo es más pequeño de lo estimado | Media | Alto | MVP con bajo costo operativo; KPIs medibles desde día 1 |
| Competidores establecidos con precios más bajos | Alta | Medio | Diferenciación por UX, transparencia y referidos |
| Problemas regulatorios con KYC (privacidad) | Baja | Alto | Cifrado, URLs firmadas, separación de buckets |
| Falsificación de identificadores | Baja | Medio | Mod-10 + bloqueo manual + auditoría |
7. Conclusión¶
El proceso AS-IS es manual, opaco, lento y propenso a errores. El modelo TO-BE propone digitalizar toda la cadena (registro → compra → reporte → recepción → consolidación → pago → despacho → entrega) con foco en:
- Transparencia (costos, estados, cargos)
- Trazabilidad (eventos, auditoría, KYC)
- Eficiencia operativa (conciliación, colas, notificaciones)
- Crecimiento orgánico (referidos, niveles, crédito en Fase 2)
El sistema se justifica porque reduce costos operativos, mejora la experiencia del usuario, cumple normativa y abre la puerta a un modelo de crecimiento escalable.