PonteOnline by Akky

Diseño de producto con IA conversacional para emprendedores

Instantánea del cliente

  • Industria: Infraestructura digital / Servicios para emprendedores y pequeños negocios
  • Cliente: Akky, división de NIC México, que administra el dominio .mx desde 1989
  • Sede: México
  • Periodo: Mayo a septiembre de 2026 (Fase 1)
  • Equipo Axented: 1 Product Designer · 1 Diseñador UX/UI
  • Servicios: Estrategia de producto · PRD · UX conversacional · Design System · Demo funcional · Especificación de componentes
  • Herramientas: Claude · Claude Design · Miro · Jira
  • Aporte clave: Definir qué no debía hacer la IA del producto: reglas que hacen que MagIA recomiende solo lo que el usuario necesita.


El Desafío

Muchas empresas de infraestructura enfrentan el mismo problema: venden lo que la gente necesita, pero no lo que la gente busca. Un dominio o un correo profesional son la base de un negocio en internet. Pero un emprendedor no busca un dominio. Busca vender, verse profesional o conseguir clientes.

Akky, división de NIC México, la organización que administra el dominio .mx desde 1989, con alrededor de 1.38 millones de dominios registrados, enfrentaba ese problema. Quería llegar a un usuario que hoy no captura: la persona que nunca ha puesto su negocio en internet. Las plataformas que esa persona encuentra le ofrecen demasiadas opciones y lenguaje técnico. No sabe qué necesita, se abruma y abandona, sobre todo al momento de pagar.

El problema de fondo no era de pantallas, sino de sistema. El catálogo estaba organizado según lo que vende el proveedor. Nuestra investigación mostró que el usuario no llega por la infraestructura: llega por un resultado. Para ese usuario, el dominio no es lo que busca ni lo que lo atrae, y muchos no saben qué es.

El segundo reto vino del propio ritmo del proyecto. Entre mayo y septiembre, el PRD pasó por al menos cinco versiones, y cada versión dejaba sus propios guiones, glosarios y reglas. Iterar rápido era necesario, pero sin una regla para decidir qué fuente mandaba, cada decisión nueva se tendría que deducir cruzando versiones, en lugar de derivarla del sistema.

  • Desajuste de intención: el producto ofrecía infraestructura a personas que buscaban resultados.
  • Reglas dispersas: sin una fuente de verdad única, cada pantalla y cada guion se inferían.
  • Riesgo comercial: un asistente con IA tiende a recomendar todo lo que podría vender, aunque el usuario no lo haya pedido.

‍

Qué hizo Axented

Abordamos PonteOnline como un problema de reglas, no de interfaz. Antes de diseñar pantallas, consolidamos una sola fuente de verdad y decidimos qué debía hacer la IA del producto, MagIA, en cada momento de la conversación. Dos de esas decisiones definieron el producto.

Decisión 1: qué no debía ofrecer la IA conversacional

Lo que estaba sobre la mesa. La regla vigente era que MagIA siempre propusiera el dominio. Para un registrador, la regla tenía sentido: la matriz de dependencias del cliente lo recomendaba de inmediato después de casi cualquier producto.

Lo que vimos. Nuestra investigación de estrategia ya había mostrado que el dominio no es el gancho en ningún segmento y que muchos usuarios no saben qué es. Al construir el producto, lo vimos repetirse en tres lugares:

  • En la matriz: el dominio aparecía como recomendación inmediata casi en cada fila, siguiendo la lógica del catálogo y no la del usuario.
  • En el demo: la fricción se veía en pantalla, en el punto donde la conversación se desviaba del resultado que el usuario buscaba.
  • En un guion de MagIA: el problema estaba en la conversación misma.

Lo que decidió el cliente. Pusimos esa evidencia frente a Akky, y su equipo llegó a la conclusión por su cuenta: el dominio salió de la conversación en todos los journeys. Ahora MagIA recomienda presencia con una dirección temporal gratuita, y el dominio se ofrece en el pago, donde es un paso de compra y no un obstáculo de entrada.

La ventaja. La decisión mejora el producto en tres frentes:

  • Para el usuario: llega a un resultado, su página publicada en una dirección gratuita, antes de enfrentar un tecnicismo. El dominio aparece cuando ya vio su página publicada, no antes.
  • Para el negocio: el dominio no se pierde como venta. Aparece en el pago, cuando el usuario ya vio lo que construyó, y el correo lo suma de forma visible porque lo necesita.
  • Para el producto: los journeys se acortan y MagIA deja de empujar algo que el usuario no pidió, en línea con el principio de no vender lo que no busca.

Lo que hicimos después. Convertimos la decisión en reglas que la IA del producto puede seguir sin ambigüedad. Si el usuario quiere un dominio nuevo, tiene un journey propio. Si ya compró uno en otro lado, MagIA no le vende otro: lo ayuda a conectarlo. Mover un dominio desde otro proveedor queda en el Panel, fuera de la conversación inicial. Y como un correo profesional necesita dominio propio, al agregar correo en el pago el dominio se suma solo, visible en el resumen y con opción de deshacerlo.

La IA del equipo. Escribimos los guiones y la matriz final con IA, pero las reglas no las decidía la herramienta. Revisábamos cada guion contra la matriz, y ahí aparecían las desviaciones: MagIA volvía a proponer el dominio en journeys donde ya no debía, y se colaban tecnicismos que el diccionario del producto prohíbe, como "contraseña", "SSL" u "hosting". La corrección no fue editar guion por guion. Cambiamos el método: las reglas entraban como restricciones desde el inicio, no como correcciones al final.

La IA del producto sabía qué vender; lo que no sabía era cuándo callarse. Ese criterio lo pusimos nosotros, como reglas.

Decisión 2: límites para un asistente de ventas con IA

Akky pidió journeys cortos. La lectura literal era recortar guion por guion. Pero el problema no estaba en la longitud: un asistente de ventas con IA tiende a recomendar todo lo que tiene sentido, y cada recomendación extra aleja al usuario del resultado que vino a buscar.

Convertimos el pedido en un límite para la IA: en el chat, MagIA recomienda como máximo una cosa, y puede ser ninguna. Todo lo demás pasa al Panel, que sigue ofreciendo lo pendiente hasta que no quede nada. La regla vive en la matriz, así que cada journey nuevo la hereda sin tener que volver a negociarla.

‍

Soluciones Implementadas

Producto y reglas

  • PRD con fuente de verdad única: orden de prioridad explícito entre fuentes y lista de lo que quedó superado.
  • Arquitectura de 5 productos y 8 journeys: 5 productos con 14 funcionalidades que se adquieren por separado, y journeys organizados por intención del usuario.
  • Matriz por funcionalidad editable por el cliente: las reglas de recomendación viven ahí, no en los guiones.

Experiencia conversacional

  • Guiones de MagIA por journey: reacomodados de 13 guiones previos a los 8 journeys actuales.
  • Ruta del peor escenario (Angry Path): con notas de dónde hay que profundizar.
  • Diccionario de lenguaje: "dirección temporal gratuita" en lugar de "subdominio", "espacio para tu página" en lugar de "hosting".

Sistema visual

  • Design System en HTML y Markdown (.md): construido sobre el brief de marca, con reglas de uso.
  • Especificación de componentes: el diseño visual y la especificación de cada componente, entregados al equipo técnico del cliente para guiar el desarrollo.
  • Demo en HTML del camino ideal (Happy Path): con el Design System aplicado.
  • Instructivo para agregar un journey: intención, preguntas de diagnóstico, funcionalidades y conexión con los existentes.

‍

Resultados

La Fase 1 cerró con el entregable aceptado por el cliente. En cinco meses y con un equipo de dos personas, Akky recibió un producto definido y listo para construir. Lo entregamos como un sistema vivo, y el equipo de desarrollo del cliente ya itera con la matriz y el instructivo sin depender de nosotros.

  • Un producto que desarrollo puede construir sin adivinar: las reglas de cada producto, journey y recomendación están escritas, con una sola fuente de verdad, las fuentes viejas marcadas como superadas y una especificación por componente.
  • Un sistema más simple después de iterar: 13 guiones consolidados en 8 journeys, y un catálogo de 5 productos con 14 funcionalidades que se adquieren por separado.
  • Decisiones con su razón documentada: quien llegue después sabe qué se decidió y por qué, no solo qué se construyó. El PRD registra cada cambio por versión y su estado, y cada sesión con el cliente cerró con minuta.
  • Un handoff para personas y para agentes de IA: el Design System se entregó en HTML para el equipo y en Markdown para que un agente de IA pueda construir con él sin reinterpretarlo.
  • Un sistema que el cliente ya opera: el instructivo para agregar journeys y la matriz editable están en uso por su equipo de desarrollo.
PonteOnline no terminó con una IA que vende más, sino con una que sabe cuándo no vender. Ese criterio ya no depende de nosotros: vive en reglas que el cliente opera.

‍

KPIs

13 → 8 — Guiones previos consolidados en 8 journeys organizados por intención del usuario

5 productos · 14 funcionalidades — Catálogo que se adquiere por separado, con reglas en una matriz editable

5 meses · 2 personas — De la estrategia a un producto listo para construir, aceptado por el cliente

‍

Equipo y Modelo de Entrega

Product Designer

Definió qué debía hacer el producto y, sobre todo, qué no debía hacer su IA. Tradujo la investigación en 8 journeys organizados por intención del usuario, llevó la evidencia que permitió al cliente sacar el dominio de la conversación y escribió las reglas que gobiernan a MagIA. Dirigió a la IA del equipo con esas reglas como restricciones y dejó cada decisión documentada con su razón, para que el cliente construya y opere sin depender de Axented.


Diseñador UX/UI

Convirtió las reglas del sistema en interfaz. Construyó el Design System a partir del brief de marca y lo dejó en HTML y Markdown, listo para personas y para agentes de IA. Diseñó los estados de interfaz y el demo del camino ideal, que sirven como referencia de lo que desarrollo debe construir.


Modelo operativo

Entregas por hitos con sesiones de validación con Producto, Marketing y el equipo técnico del cliente. El backlog vive en Jira, con la misma estructura que el cliente usa para gestionar el proyecto, y cada sesión cierra con minuta y paquete de entregables.

Border
Border
Cuando estés listo

Tell us which process you'd like to fix.

Treinta minutos con un fundador o un ingeniero senior, no con un vendedor. Sin presentaciones. Si ninguno de nuestros servicios encaja, te lo decimos y te orientamos hacia algo útil.

La llamada se agenda directo en el calendario de un fundador, en tu zona horaria. WhatsApp se atiende en horario de Monterrey, de lunes a viernes, en español o inglés, normalmente en menos de una hora. O escribe a bernardo@axented.com.

Thank you! Your submission has been received!
Oops! Something went wrong while submitting the form.