respuestas de la postulación
01 · 1324/1500 caracteres
¿Cuál es el problema que aborda tu startup?
El canal tradicional —almacenes, botillerías y minimarkets de barrio— sigue moviendo una parte central del consumo diario en Chile, pero se atiende con herramientas que no conversan entre sí: el vendedor pasa una vez por semana, el pedido se cierra por WhatsApp, el stock se lleva de memoria y la promoción se conoce cuando ya pasó.
Para el almacenero el costo es concreto: quiebres justo de los SKU que más rotan el fin de semana, plata inmovilizada en productos que no salen, merma en frío y perecibles, y pedidos mínimos que lo obligan a comprar más de lo que necesita. Nadie le devuelve información: no sabe qué le están pidiendo sus vecinos y no encuentra, ni qué le conviene reponer primero.
Para el distribuidor y la marca el costo es de visibilidad: la data llega agregada y tarde, no se sabe por qué se cayó un pedido, la demanda insatisfecha nunca se registra —el vecino pide algo, no está, y esa venta desaparece sin dejar rastro— y las rutas se arman por frecuencia histórica y no por necesidad real.
Las apps del canal (BEES, miAndina, Embonor) digitalizaron el pedido de cada compañía por separado, pero el almacenero debe entrar a varias, aprender interfaces distintas y aun así seguir coordinando por WhatsApp. La conversación, que es donde realmente ocurre el comercio de barrio, sigue fuera del sistema.
02 · 1354/1500 caracteres
¿Cuál es la solución que ideaste para resolver el problema identificado?
altiropo es una capa de comercio agéntico que se instala sobre la conversación que el canal ya usa: WhatsApp y chat. El almacenero le habla a Almi, su agente, en lenguaje natural —"lo de siempre", "me quedé sin bebida de 1.5", "qué me conviene pedir para el fin de semana"— y recibe bloques accionables: su bodega estimada, el pedido armado, alertas de quiebre y merma, y la confirmación al distribuidor.
No reemplazamos BEES, miAndina ni Embonor: los orquestamos. altiropo mantiene catálogo, precios y reglas de cada distribuidor y convierte la conversación en un pedido válido en el sistema que corresponde, consolidando en una sola interacción lo que hoy son varias apps.
Del otro lado, el vecino también conversa: pide su compra de siempre, ve las ofertas del almacén y, cuando algo no está, esa demanda insatisfecha queda registrada. Ese registro es el activo: por primera vez el almacenero y la marca ven qué se pidió y no se pudo vender, por SKU, por barrio y por día.
Arriba corre la capa de datos: memoria por comercio con base vectorial aislada por tenant, mix anti-quiebre, alertas de cadena de frío y vencimiento, y consolidación de rutas por cercanía. Cada decisión del agente queda trazada —observa, aprende, actúa, verifica, mejora— para que la marca audite cómo se generó cada recomendación. El producto está construido y operando hoy.
03 · 750/800 caracteres
¿De qué manera tu solución es innovadora frente a lo que ya existe?
Lo existente digitalizó el formulario de pedido: mismo catálogo, misma lógica de app, una por compañía. altiropo cambia la interfaz por conversación y agrega dos cosas que hoy no existen en el canal.
Primero, agencia: el agente no espera que el almacenero busque; propone el pedido según rotación, quiebre y calendario del barrio, y lo ejecuta con confirmación.
Segundo, la demanda insatisfecha como dato. Hoy, cuando un vecino pide algo que no está, esa venta se pierde sin registro. Nosotros la capturamos en la conversación del vecino y la devolvemos al almacenero y a la marca como señal de reposición y de portafolio.
A eso se suma orquestación multimarca —un solo hilo sobre varias apps— y trazabilidad auditable de cada decisión del agente.
04 · 442/500 caracteres
¿Cómo tu solución ayuda a afrontar el desafío seleccionado? Incluye datos o evidencia que lo respalden.
El sub-desafío es conocer mejor al cliente. altiropo genera esa data donde hoy se pierde: la conversación. Cada interacción deja SKU pedido, hora, barrio y, clave, la demanda insatisfecha que ninguna app registra. En el canal tradicional prácticamente todo el pedido nace en WhatsApp y nunca queda estructurado. Con 50 almacenes en 4 meses entregamos a la compañía un panel de demanda real por SKU y barrio, con la causa de cada pedido caído.
05 · 1010/1500 caracteres
Describe el modelo de negocios detrás de tu propuesta.
Modelo mixto, en tres líneas.
1) SaaS al distribuidor o embotellador: suscripción mensual por almacén activo en la red, que cubre el agente del almacenero, la orquestación de pedidos y el panel de demanda. Es el ingreso recurrente y predecible.
2) Fee por transacción sobre el pedido cursado a través de altiropo, alineado al resultado: cobramos cuando el pedido ocurre. Esto baja la barrera de entrada del piloto y escala con el volumen del canal.
3) Datos e inteligencia comercial: reportes de demanda insatisfecha, mix por barrio y efectividad de promociones, vendidos como capa premium a la marca. No vendemos datos personales: entregamos señales agregadas por SKU y territorio.
Para el almacenero el uso del agente es gratuito, porque él es la fuente del dato y el usuario que sostiene la red. altiropo no toma inventario ni compra producto: opera sobre la logística existente del distribuidor, por lo que el costo marginal por almacén incorporado es bajo y el margen crece con la densidad de la ruta.
06 · 895/1500 caracteres
¿Cuál es tu principal métrica de tracción de venta a la fecha?
Nuestra métrica principal es pedidos cursados por conversación: interacciones que terminan en una orden confirmada dentro del agente, sin que el usuario salga a otra app.
Hoy tenemos prototipo en uso con usuarios finales reales y ventas acumuladas en el rango de $1 a $10.000.000 en los últimos 12 meses, provenientes de comercios que operan su catálogo y sus pedidos sobre la plataforma. Cada pedido queda registrado como orden con monto, SKU e items, de modo que la métrica es auditable y no declarativa.
Junto a ella seguimos tres indicadores de salud del canal: tasa de conversión de conversación a pedido, ticket promedio por pedido conversacional y demanda insatisfecha registrada por semana, que es el dato que ninguna app del canal captura hoy.
En el piloto, la meta es llevar esas métricas de un puñado de comercios a 50 almacenes con medición semanal comparada contra su línea base.
07 · 1016/1500 caracteres
Describe a tu equipo
[Completar con nombres reales antes de enviar. Estructura sugerida por integrante: nombre · rol en el piloto · años de experiencia · logro verificable · % de dedicación.]
Fundador y responsable de producto: [nombre], [años] años en comercio digital y desarrollo de producto, responsable de haber construido y puesto en operación la plataforma que se presenta en esta postulación (catálogo, agentes, pedidos y trazabilidad ya funcionando). Dedicación [%].
Desarrollo e infraestructura de agentes: [nombre], responsable de la capa de agentes, memoria vectorial por comercio e integraciones con los sistemas del canal. Dedicación [%].
Operación en terreno: [nombre], responsable del levantamiento y acompañamiento de los almacenes del piloto, con experiencia en el canal tradicional y relación directa con almaceneros y distribuidores. Dedicación [%].
El equipo llega con producto construido, no con una idea: el riesgo del piloto no es técnico, es de adopción, y por eso la dedicación mayor está puesta en terreno.
08 · 1037/1500 caracteres
¿Cuál es el piloto que buscas realizar?
Un piloto de 4 meses con 50 almacenes de una misma ruta de distribución, en una comuna acotada, para probar una hipótesis concreta: si el almacenero pide por conversación, el pedido se hace más frecuente, con menos quiebres, y la compañía obtiene por primera vez data de demanda real del barrio.
Alcance: cada almacén recibe su agente Almi por WhatsApp, con el catálogo y las reglas comerciales del distribuidor cargadas. El agente arma el pedido sugerido, avisa quiebres y vencimientos, y cursa la orden al sistema del distribuidor. En paralelo, los vecinos de esos almacenes pueden pedir por conversación, y toda demanda no satisfecha queda registrada.
Deliberadamente elegimos 50 y no 500: queremos evidencia limpia y comparable contra la línea base de esos mismos locales, con acompañamiento en terreno real y no una adopción declarada.
Métricas de éxito: % de almacenes activos semanalmente, pedidos por conversación sobre el total, variación de frecuencia y ticket, quiebres evitados y volumen de demanda insatisfecha capturada.
09 · 1033/1500 caracteres
¿Cómo planeas implementar el piloto?
Mes 1 — Preparación. Integramos catálogo, precios y reglas del distribuidor; definimos la ruta y los 50 almacenes; levantamos la línea base de cada local (frecuencia, ticket, quiebres) con la data de la compañía. Trabajo conjunto con la contraparte operativa.
Mes 2 — Activación en terreno. Alta puerta a puerta: nuestro equipo visita cada almacén, deja el agente andando en su WhatsApp y hace el primer pedido junto al almacenero. La adopción no se pide por mail, se acompaña.
Mes 3 — Operación y ajuste. El agente opera de forma autónoma: pedido sugerido, alertas de quiebre y merma, consolidación de entregas por cercanía. Iteramos semanalmente con lo que aparece en las conversaciones y sumamos el canal vecino en los almacenes que van más rápido.
Mes 4 — Medición y cierre. Comparamos contra la línea base, entregamos el panel de demanda insatisfecha por SKU y barrio, y presentamos el caso de escalamiento a la ruta completa.
Todo el piloto se ejecuta sobre la plataforma ya construida; no hay desarrollo de base pendiente.
10 · 995/1500 caracteres
¿Qué necesitan de la empresa para implementar el piloto?
1) Acceso a una ruta real: la definición de una comuna y de los 50 almacenes del canal tradicional que atiende el distribuidor, con su información de frecuencia y visita.
2) Catálogo y reglas comerciales vigentes: SKU, formatos, precios de canal, mínimos de pedido, promociones y condiciones de crédito, en el formato que la compañía tenga disponible.
3) Una contraparte operativa: una persona del distribuidor que valide que los pedidos generados por el agente entran correctamente al flujo logístico, con una reunión semanal de seguimiento.
4) Integración con el sistema de pedidos: acceso técnico —API, archivo o el canal que la compañía prefiera— para cursar las órdenes hacia el sistema existente. Podemos operar también en modo archivo si la integración directa toma más tiempo.
5) Autorización y respaldo de marca para contactar a los almaceneros por WhatsApp, que es lo que hace creíble la invitación en terreno.
6) La línea base de esos locales para medir el impacto sin discusión.
11 · 981/1500 caracteres
¿Cuál es el impacto estimado de su solución en el piloto de 4 meses?
Sobre 50 almacenes en 4 meses, nuestras metas son:
· 70% de los almacenes activos semanalmente en el agente al cierre del piloto.
· 50% de los pedidos de esos locales cursados por conversación.
· Aumento de 15% en la frecuencia de pedido respecto de la línea base, por la sugerencia proactiva antes del fin de semana.
· Reducción de 20% de los quiebres en los SKU de alta rotación, medidos por alerta emitida versus quiebre reportado.
· 100% de la demanda insatisfecha registrada: cada producto pedido y no vendido queda con SKU, fecha y barrio, dato que hoy simplemente no existe.
· Un panel entregado a la compañía con demanda real por SKU y territorio, y con la causa de los pedidos caídos.
Para el almacenero el impacto es tiempo y plata: menos vueltas para pedir, menos quiebres del producto que sí vende y menos merma. Para la compañía, un canal que por primera vez devuelve información en vez de solo recibir cajas, y una base para decidir la expansión a la ruta completa.