Reconstrucción del portal Expert: sustentar una decisión estratégica en pruebas

Una herramienta explotada a fondo, un programa que cambia de escala

Las agencias partner del programa Expert acompañan a los comerciantes de PrestaShop en la creación, la migración y el mantenimiento de sus tiendas. Para animar esa red, la empresa se apoyaba en un portal construido sobre una herramienta PRM del mercado: registro de las agencias, gestión de las certificaciones, distribución de los leads, directorio público destinado a los comerciantes.

Dos años después de su despliegue, todos los equipos explotaban la herramienta a su máximo potencial: workflows, sincronizaciones, directorio, gestión de deals, scoring. Al mismo tiempo, el programa cambiaba de escala. Nuevo modelo de certificación, rediseño de la lógica de datos de cliente, ambición de convertir el ecosistema en una palanca de negocio medible en lugar de un centro de costos opaco. El portal debía sostener esa transformación. La estaba frenando.

Tres bloqueos debajo de la solicitud de reparación

En la superficie, una solicitud de mejora: filtros rotos en el directorio, páginas desactualizadas, agencias frustradas. En el fondo, tres bloqueos de otra naturaleza.

El techo estructural, primero. Todos los equipos usaban la herramienta correctamente, y la herramienta no podía dar más. Front bloqueado donde cada modificación pasaba por el soporte del proveedor, sincronización CRM de una sola vía, multilingüe que había que recapturar idioma por idioma. Un defecto de uso se corrige con formación. Un techo estructural no se corrige.

La ausencia de medición, después. Ningún dato confiable sobre las búsquedas, los clics, las solicitudes de contacto. El directorio era un agujero negro: incapaz de probar su valor, incapaz de probar su fracaso, y por lo tanto imposible de arbitrar de otra forma que por intuición.

El sesgo del costo hundido, por último. Años de inversión, procesos construidos alrededor de la herramienta, un contrato en curso. Todo empujaba a la organización hacia un enésimo esfuerzo de reparación, más cómodo de defender que un cuestionamiento de fondo.

La situación exigía algo distinto de un proyecto de rediseño: crear las condiciones de una decisión de inversión, sin datos para fundarla y contra la pendiente natural de la organización.

Preparar la decisión sin ser quien decide

Head of Product Design del proyecto, dentro de un colectivo que reunía producto, CRM, marketing, channel, tech y data, llevado en el día a día por una dupla producto-diseño.

El mandato: liderar el proceso que debía iluminar la decisión entre optimizar lo existente, comprar otra herramienta del mercado o construir. En concreto, definir y redactar el brief de diseño, estructurar las dos discoveries sucesivas (el directorio público, luego el portal en su conjunto), garantizar que la voz de todos los usuarios pesara en el expediente, la de las agencias y los comerciantes tanto como la de los equipos internos, y producir los artefactos sobre los cuales se tomaría la decisión.

Los límites eran claros: ni el presupuesto ni la decisión final, que correspondían a los sponsors. La responsabilidad recaía sobre la calidad de la preparación, con una expectativa precisa: un expediente de decisión defendible, en un tiempo acotado.

Objetivar, recalificar, construir la convicción

Objetivar antes de proponer. Frente a una herramienta cuestionada pero instalada, la primera batalla es factual: una docena de entrevistas con agencias, seis workshops con todos los equipos que explotan el portal, cinco recorridos clave reproducidos paso a paso, una auditoría externa de la experiencia y de la arquitectura, un benchmark de las alternativas. Ese trabajo estableció el hecho que lo cambió todo: los problemas no venían de una falta de uso sino de los límites de la herramienta misma. Nombrar esa diferencia frente a los sponsors fue el primer entregable del proyecto, antes de cualquier pantalla.

Recalificar la solicitud. La discovery del directorio sacó a la luz dos puntos ciegos. Ninguna medición de uso en ninguna parte: sin datos, cada discusión de mejora se jugaba por intuición. Y una canibalización SEO que nadie había calificado: la búsqueda orgánica más natural para encontrar un partner llevaba a otro directorio interno, el de los módulos. Una reparación de filtros no podía nada contra eso. La pregunta fue entonces reformulada, y asumida como tal en el brief: ¿queremos construir un producto medible, que cree valor para los comerciantes, las agencias y la empresa? Formulada así, pedía una decisión de fondo, no un lavado de cara.

Diseñar el backstage junto con la fachada. Las fricciones de las agencias (scoring opaco, leads sin seguimiento, información dispersa) eran en parte el síntoma de un problema interno: los Channel Managers, responsables de los portafolios de agencias, no disponían de ninguna vista consolidada y reconstruían la realidad a punta de correos y exportaciones. El brief de diseño estableció el principio: una experiencia fluida del lado interno es una condición de una experiencia lograda del lado partner. Cada recorrido de agencia de la experiencia objetivo se diseñó en espejo del recorrido interno que lo hace posible.

Construir la convicción sobre la marcha. Salir de una herramienta compromete contratos, migraciones y equipos: eso no se gana en una reunión de presentación de resultados. El dispositivo se pensó contra el efecto túnel: puntos cortos y regulares con los sponsors, aprendizajes y dudas compartidos a medida que aparecían, board de discovery abierto a todos. La reunión de decisión solo debía ser la formalización de una convicción ya construida.

Dos prototipos lado a lado en lugar de un informe más

Quedaba elegir cómo preparar la decisión final. Tres opciones.

Un informe comparativo clásico, con matrices y puntajes ponderados. Riguroso, pero sin agarre sobre el verdadero adversario: frente al costo hundido, cada cifra de una tabla se discute, y la opción del statu quo siempre sale viva.

Una prueba de usuario del prototipo objetivo. Útil para validar una experiencia, pero fuera de tema para la decisión: la duda de los sponsors no era sobre la deseabilidad de un mejor portal, era sobre la necesidad de dejar la herramienta para obtenerlo.

La tercera opción fue la elegida: poner dos artefactos lado a lado. De un lado, el prototipo de la experiencia reconstruida, con un recorrido de confianza para el comerciante, pruebas verificadas en los perfiles de agencia, un formulario de brief que califica la solicitud, un bucle de feedback que enriquece el sistema. Del otro, una simulación de lo que la herramienta existente permitiría en el mejor de los casos, construida con honestidad, parches y rupturas de recorrido incluidos. Esa honestidad era la condición de credibilidad del expediente: una caricatura construida para asustar habría destruido la confianza.

El criterio de validación se escribió antes de la presentación: ni un puntaje, ni un test, sino la reacción de los sponsors al ver los dos escenarios lado a lado. Una brecha de valor descrita en un informe se discute. Vuelta navegable, se constata.

El prototipado asistido por IA volvió viable esa elección: dos experiencias comparables y manipulables producidas en unos días, donde habrían hecho falta semanas. Ese uso, aprendido haciéndolo, sirve desde entonces de modelo para otros expedientes de decisión.

Una precisión de honestidad sobre el tempo, porque un relato demasiado pulido no le serviría a nadie: el expediente avanzó más rápido que la formalización. La convicción colectiva se consolidó artefacto tras artefacto, hasta una decisión que no sorprendió a nadie. Ese era el objetivo del dispositivo.

Una decisión tomada, capacidades duraderas

La decisión, primero. La organización salió de la lógica de reparación para formalizar una decisión estructural: dejar la herramienta del mercado al vencimiento del contrato y reconstruir. El expediente documentado constituye su traza: diagnóstico, opciones, pruebas, recomendación.

Las capacidades, después. El directorio público, la pieza más expuesta, fue reconstruido sobre prestashop.com, medible por diseño: plan de tracking, SEO e integración CRM especificados antes de la primera maqueta. El portal Expert propio siguió, desarrollado internamente, hoy en producción. Los equipos ahora modifican un recorrido partner sin abrir un ticket con un proveedor.

El agujero negro de datos del inicio recibió una respuesta estructural, entregada con la puesta en producción. Una North Star primero: las conexiones calificadas por mes, el valor del ecosistema reducido a un indicador único. Luego los KPI que la despliegan, medibles desde la V1: los inicios de sesión en el portal, con los primeros inicios de sesión aislados para seguir la ventana post-migración; los briefs de comerciante completados, que materializan el lead en la fuente; las solicitudes de contacto enviadas a las agencias; y el destino de cada lead, seguido por estado desde el primer contacto hasta el ganado o perdido. El conjunto cabe en un plan de tracking de unos treinta eventos que cubren once casos de uso de negocio, de la activación de una agencia al tratamiento de un lead, y en un dashboard de gestión especificado lote a lote, de lo vital a lo accesorio. Con una disciplina asumida: un período de baseline antes de cualquier umbral de alerta, porque un tracking nuevo no se interpreta, se observa. El programa que no podía probar nada ahora sabe exactamente qué debe medir.

La práctica misma, además, y está medida. La reconstrucción del portal fue la ocasión de transformar la forma de diseñar: la documentación y las evoluciones de diseño y front dirigidas de punta a punta orquestando la IA, en lugar de codificar en su lugar. El reporte de orquestación llevado durante la ventana de reconstrucción da la medida: 21 458 acciones de IA dirigidas, distribuidas en cinco verbos, explorar, actuar, estructurar, documentar, delegar. La distribución dice la postura: la ejecución se delega masivamente a la IA, la estructura y la documentación siguen siendo humanas, para que el producto se pueda seguir dirigiendo cuando uno ya no está en el circuito. Y la herramienta cambió en el camino, de un agente de código a otro, sin cambiar el método: la dirección no depende de la herramienta.

La organización, por último. El marco Build vs Buy vs Optimize sirve de referencia para las otras piezas del ecosistema. El principio de los recorridos en espejo, externo e interno diseñados juntos, se aplica a los proyectos siguientes. Y la preparación de decisiones con prototipos comparados se volvió una práctica que desborda este expediente.

El siguiente frente está abierto: transformar el directorio, ahora instrumentado, en un motor de conexión calificada entre comerciantes y agencias. El valor de un ecosistema no se mide por los perfiles que muestra, sino por las conexiones que crea.

Mi mandato terminó en agosto de 2026, y el proyecto se transmitió equipado para continuar sin mí: el portal en producción, la North Star y su plan de medición, el dashboard especificado, el registro de decisiones. Ese fue el criterio de diseño desde el primer día, y es la verdadera prueba de todo lo anterior.