# Caso Fudo — Diagnóstico gratuito con calificación

Nov 5, 2026 · @Fabricio Guzzo

## a. Problema, segmento e hipótesis

El objetivo no es generar más cuentas sino más cuentas que paguen. Con pauta, el CAC ronda USD 200 y una herramienta gratuita atrae también a quien ya tiene sistema y solo quiere el resultado.

**País y segmento.** Argentina primero: mercado de origen de Fudo, un solo set de fuentes (Google, Instagram, PedidosYa, Rappi), un idioma y una moneda. Segmento: restaurante, bar o cafetería independiente de 1 a 5 locales que opera sin sistema, con papel/Excel o con un sistema básico.

**Cómo filtro.** El diagnóstico de presencia online es el anzuelo; antes del resultado, el dueño responde 4 preguntas cerradas (menos de 20 segundos): cómo registra ventas hoy, cuántos locales tiene, si recibe pedidos por delivery o WhatsApp y si es quien decide. Reglas ordenadas, gana la primera que se cumple:

| Respuesta | Segmento | CTA |
| --- | --- | --- |
| 6 o más locales | Fuera | Hablá con el equipo comercial |
| Ya usa otro software de gestión | Medio | Compará Fudo con tu sistema actual |
| No es el dueño | Medio | Compará Fudo con tu sistema actual |
| Papel o sistema básico + delivery/WhatsApp | Alto | Creá tu cuenta gratis en Fudo |
| Resto | Medio | Compará Fudo con tu sistema actual |

Todos ven su nota completa: no castigamos al usuario; lo que cambia es el CTA.

**Hipótesis.** H1: un dueño completa el diagnóstico si tarda menos de 60 segundos. H2: 4 preguntas separan a quien puede pagar sin hundir la finalización. H3: el segmento alto paga a 60 días a 15 % o más (base 10 %).

**Regla con variante medible.** Que un local solo de salón y sin sistema pague como uno con delivery es una hipótesis a validar con datos. Por eso la regla de alto encaje tiene dos variantes (A exige delivery, B no) controladas por un switch; la variante viaja en los eventos y en el UTM, y el pago a 60 días por variante define cuál queda.

## b. Por qué esta solución

Mantengo el diagnóstico sugerido y le agrego calificación, porque resuelve las dos mitades del problema. El diagnóstico atrae a cualquier dueño con una pregunta que le importa ("¿cómo me ven en internet?") y sin pedirle nada a cambio. La calificación separa a quien tiene el dolor que Fudo resuelve de quien solo quiere la nota.

Descarté una calculadora de comisiones de apps de delivery: filtra mejor, pero atrae solo a quien ya vende por apps y genera menos tráfico. También descarté ocultar el resultado a quien no califica: baja la finalización y el boca a boca. Filtrar en el CTA conserva el valor de la herramienta para todos y concentra el esfuerzo de conversión donde hay chance de pago.

## c. Distribución

Ordenado por costo, de menor a mayor:

1. **Web propia de Fudo (costo cero).** Entrada desde home, blog y precios. Exponer el 10 % de las 80.000 visitas mensuales da 8.000 visitas para el experimento.
2. **Outbound con diagnóstico pregenerado.** A partir de listados públicos de restaurantes, enviar por Instagram o email "Hicimos el diagnóstico de tu local: 58/100" con un enlace que abre el formulario precargado. Es el canal de mayor intención; exige opt-out y respetar normas antispam.
3. **SEO y AEO.** Contenido que responde preguntas reales de dueños ("cómo conseguir más reseñas en Google", "cuánto cobra PedidosYa") con la herramienta embebida y datos estructurados FAQ para aparecer en respuestas de IA.
4. **Boca a boca.** El resultado se comparte por WhatsApp con la nota en el texto y un enlace limpio, sin el nombre del local, para que quien lo recibe haga su propio diagnóstico.
5. **Alianzas.** Cámaras gastronómicas, contadores de gastronómicos y distribuidoras de bebidas, que pueden ofrecerlo como regalo de valor a su cartera.
6. **Pauta.** Solo para validar mensajes, no como canal principal.

## d. Qué recorté y por qué

| Afuera | Por qué |
| --- | --- |
| APIs reales (Google Places, apps de delivery) | Google pide facturación; el scraping de delivery tiene riesgo legal y de términos de uso. Se documenta fuente y costo. |
| Backend, base de datos, login, guardado de leads | No hacen falta para validar la hipótesis: se mide con eventos y UTMs. |
| Otros países e idiomas | Primero validar en un mercado. |
| PDF descargable, email del informe, panel admin con usuarios | Mejoras de conversión posteriores, no validan nada nuevo. |
| Diseño visual | No puntúa; HTML semántico y CSS nativo, accesible. |

Adentro quedó lo mínimo para probar la tesis: un país, una página (formulario → 4 preguntas → resultado → CTA por segmento), datos simulados reproducibles, eventos de medición, CTA con UTMs y un panel `/control` para alternar la variante de la regla.

## e. Cómo lo construí

**Stack:** Astro + TypeScript + CSS nativo, sitio estático publicado en plan gratuito. Sin frameworks de interfaz ni backend: el flujo no necesita estado complejo ni servidor.

**Arquitectura pensada para cambiar sin tocar código.** Ítems, pesos, preguntas, reglas y switches viven como datos en `src/data/`; la lógica en `src/lib/` son funciones puras (diagnóstico, calificación, hash). Cambiar un peso o una regla es editar una línea; un switch nuevo aparece solo en `/control`.

**Datos simulados y reproducibles.** Las notas salen de un hash del nombre y la ciudad: el mismo local obtiene siempre el mismo resultado. Todas las fuentes del prototipo son simuladas y la interfaz lo indica.

**Método con IA, dentro de cuotas gratuitas.** Separé criterio de ejecución: la estrategia, la estructura de archivos, los contratos de tipos y las reglas se definieron con Claude (plan gratuito); el código lo escribió Gemini 3.8 Flash en Google Antigravity CLI con prompts cerrados, uno por paso, sin dejarle decisiones de diseño. Cada prompt quedó registrado con hora, resultado y consumo de cuota en `docs/prompts/`, y cada resultado se revisó con `git diff` antes del commit. Un primer prompt que pedía al modelo proponer la estructura se descartó: gastaba cuota en decisiones que me corresponden.

## f. Cómo lo mediría

**Línea de base (pauta):** 80.000 visitas → 1,2 % → 960 cuentas → 10 % → 96 clientes pagantes por mes, con CAC ≈ USD 200.

**Embudo instrumentado:** `diagnostico_iniciado` → `calificacion_completada` (segmento, respuestas y variante de regla) → `resultado_visto` → `cta_click` → cuenta creada en fu.do (UTM con segmento y variante) → activación a 7 días → pago a 60 días. `compartir_click` mide el boca a boca. Ningún evento envía el nombre del local.

**Experimento de lanzamiento (escrito antes de lanzar).** Cuatro semanas en Argentina, 10 % del tráfico web expuesto al diagnóstico y el resto como control.

| Paso | Supuesto | Diagnóstico (8.000 visitas) | Control (8.000 visitas) |
| --- | --- | --- | --- |
| Completa el diagnóstico | 40 % | 3.200 | — |
| Crea cuenta | 8 % de quienes completan · 1,2 % en control | 256 | 96 |
| Alto encaje | 60 % de las cuentas | 154 | — |
| Paga a 60 días | 15 % alto · 8 % resto · 10 % control | ≈ 31 | ≈ 10 |

Hipótesis: el grupo expuesto genera tres veces más clientes pagantes por cada 1.000 visitas que el control. Como el pago tarda 60 días, la decisión temprana se toma con la activación a 7 días.

**Reglas de decisión fijadas de antemano:** si el pago del alto encaje queda por debajo de 10 %, la calificación no discrimina y se revisan las preguntas. Si las cuentas "fuera de segmento" superan el 20 %, se ajusta el mensaje de entrada. Si la variante B no baja el pago del alto encaje por debajo de 15 % y suma volumen, pasa a ser la regla por defecto.

## g. Qué haría después

**Datos reales, por fuente:**

| Ítem | Fuente real | Restricción |
| --- | --- | --- |
| Perfil de Google y reseñas | Google Places API (búsqueda + detalle del lugar) | Requiere cuenta con facturación; costo por llamada |
| Instagram | Búsqueda pública; Meta Graph API solo para cuentas que autoricen | Acceso limitado sin autorización del dueño |
| Web o carta propia | Consulta directa al dominio | Sin restricciones relevantes |
| PedidosYa y Rappi | Páginas públicas | Términos de uso restrictivos; requiere revisión legal o acuerdo |

**Costo por diagnóstico:** con Google Places como fuente principal, del orden de centavos de dólar por diagnóstico (a confirmar con la tarifa vigente). Aun multiplicado por diez, el costo por cliente pagante del canal queda muy por debajo de los USD 200 de la pauta.

**Próximos pasos:**

1. Conectar Google Places API: es la fuente con más peso (50 % de la nota) y la más simple de integrar.
2. Registrar el segmento y la variante en el alta de cuenta, para medir pago por segmento sin depender de UTMs.
3. Asignar la variante de regla al azar por visitante (hoy se alterna desde `/control` para validar el mecanismo).
4. Pregenerar diagnósticos para el outbound.
5. Expandir a México una vez validado en Argentina.

**Entregables:** prototipo publicado en \[URL a completar\]; repositorio con el código, la estrategia (`docs/ESTRATEGIA.md`), las decisiones (`docs/DECISIONES.md`) y el historial de prompts (`docs/prompts/`).