SAM’S CLUB (WALMART MÉXICO)
Jerarquía comercial: sistema centralizado de autorizaciones
Un solo módulo para saber quién autoriza precios, promociones y órdenes de compra, y gestionar suplencias.
- Research
- Workshops
- Arquitectura de información
- Iniciativa
- Módulo centralizado para administrar la jerarquía comercial y definir quién autoriza precios, promociones y órdenes de compra.
- Mi rol
- Product Designer. Lideré la investigación y el diseño de la experiencia.
- Duración
- Febrero - junio 2025.
01.Resumen
En Sam’s Club México, la cadena de tiendas mayoristas de Walmart, muchas decisiones comerciales requieren la aprobación de un rol específico, como un precio especial para una compra por volumen, una promoción con un descuento alto o una orden de compra fuera de lo habitual. Para saber quién debía aprobar cada caso no había una fuente única. Cada área lo resolvía a su manera y cada módulo de la plataforma configuraba a sus aprobadores por separado.
Lideré la investigación y el diseño de un módulo centralizado para administrar la jerarquía comercial, definir quién autoriza cada tipo de solicitud y gestionar suplencias. Realicé 18 entrevistas con perfiles de las áreas involucradas, diseñé la solución y validé los flujos de autorizaciones y suplencias en 8 pruebas de usabilidad. El diseño se entregó a desarrollo y quedó en espera de su implementación.
02.Contexto y problema
La estructura comercial de Sam’s Club México se organiza en tribus, que son grandes grupos de categorías como Fresh y Perecederos o Abarrotes e Impulso. Cada tribu se divide en squads con compradores, asistentes de compras, resurtidores, gerentes y directores. Varias operaciones de la plataforma interna, como los precios por volumen, las promociones, las órdenes de compra o las transferencias de mercancía entre tiendas, requieren que alguno de esos roles autorice antes de avanzar. El objetivo es evitar errores que terminan en ventas con margen inadecuado, merma o exceso de inventario.
Sin embargo, la jerarquía comercial, es decir, quién reporta a quién y quién puede aprobar cada tipo de solicitud, solo existía en un directorio en Excel que se actualizaba a mano cada mes y se publicaba en un portal interno. La plataforma no tenía una fuente única de información que pudiera usar. Cada módulo tenía su propia configuración de quién aprueba, sin conexión con los demás, y no había un responsable definido de mantenerla actualizada.
Las 18 entrevistas de la investigación mostraron el costo de esa dispersión:
- •Las autorizaciones estaban repartidas entre distintas herramientas y el correo.
- •No llegaban avisos de solicitudes pendientes. En el gestor de precios, el módulo donde se solicitan y autorizan los cambios de precio, si nadie respondía en 24 horas, la solicitud pasaba al siguiente nivel o se rechazaba sola.
- •No había un proceso formal de suplencias. Se resolvían con el mensaje de fuera de oficina en Teams, por correo, por chat o de palabra.
- •Cuando alguien cambiaba de puesto, el cambio tardaba en verse en el directorio, porque dependía de la actualización mensual.
- •En algunos módulos, quien hacía una solicitud podía aprobarla él mismo.
03.Mi rol y con quién trabajé
Trabajé con producto, business analysts y developers. Mis líderes de investigación y diseño acompañaron el proyecto como mentoras, validando el enfoque y los entregables, y content design participó en la revisión del lenguaje de las pantallas.
Lideré la investigación de principio a fin. Además de las entrevistas, facilité workshops con líderes de las áreas para comprender cómo se organizaba la estructura comercial. Con esa base diseñé el flujo y las pantallas del módulo, y los validé con usuarios. Presenté los hallazgos a los stakeholders y las propuestas de diseño al equipo de desarrollo, para acordar el alcance antes de avanzar.
04.Objetivos
Centralizar la jerarquía comercial en una sola fuente de información que los módulos de la plataforma pudieran usar.
Reducir errores en precios, promociones y órdenes de compra por falta de validación jerárquica.
Mejorar los tiempos de respuesta en las autorizaciones y formalizar la gestión de suplencias.
Desde la investigación, entender quién aprueba qué, cómo se escalan las autorizaciones y dónde se detenían las solicitudes.
05.Decisiones y en qué evidencia me apoyé
Usé IA para agilizar el análisis del discovery, siempre revisando cada resultado frente a lo observado en las sesiones. En la etapa de diseño también la usé para explorar alternativas de pantallas.
La información sobre quién autoriza qué estaba dispersa entre un Excel, la configuración de cada módulo y el conocimiento de cada persona.
Varias de las personas entrevistadas coincidieron en que la solución ideal era un solo lugar, organizado por persona y no por actividad. Por eso concentré todo en un único módulo, con cuatro secciones para administrar la jerarquía, consultarla, configurar las autorizaciones y gestionar las suplencias.
La primera versión del acceso no funcionó. En las pruebas, ninguno de los tres usuarios del flujo de autorizaciones relacionó el submenú “Jerarquías organizacionales” con la configuración de autorizaciones. Con content design, renombramos la sección como “Jerarquías, autorizaciones y suplencias” y añadimos una descripción breve de lo que se puede hacer en ella.
Para la consulta partí del organigrama que reconstruí en los workshops con los líderes. En las entrevistas apareció la confusión sobre a quién dirigir una autorización, agravada por homónimos dentro de la empresa, y la petición de un directorio organizado por área y responsabilidad. La vista muestra la estructura como un organigrama por división, con buscador por persona o rol, y permite descargarla por área para compartirla con otros equipos.
La administración de la jerarquía quedaría a cargo de una sola persona, la que actualizaba el directorio en Excel, con una suplente para sus ausencias. Como primera etapa, mientras se evaluaba la integración con el sistema de altas y bajas de recursos humanos, la resolví con una tabla editable similar a Excel, el formato con el que ella ya trabajaba, porque la hipótesis era que un formato conocido facilitaría la adopción. Cada fila se edita directamente, el sistema valida los campos antes de guardar y la pantalla indica la fecha de la última actualización.
Los mapas de autorización mostraron que las aprobaciones ya seguían una lógica de niveles: según el monto o el porcentaje de descuento, la solicitud llega a un gerente, a un subdirector o a un director. Diseñé la configuración de autorizaciones con esa misma lógica, en una tabla para cada módulo con cuatro niveles de impacto (bajo, medio, alto y crítico), los criterios de cada nivel y el rol que autoriza.
En las pruebas, los usuarios entendieron los niveles y la lógica de configuración, y de ahí salieron dos ajustes. Se eliminó la columna “Forecast por categoría”, un término técnico de planeación de inventario que dos de los tres usuarios no comprendieron. Además, el tiempo de respuesta pasó a expresarse como una hora de corte, por ejemplo “mismo día a las 2:00 p. m.”, que era como lo entendían.
Las suplencias eran informales y no había forma de saber quién estaba cubriendo a quién. Diseñé un flujo para asignar un suplente por módulo y periodo, con una validación previa que detecta conflictos, como un suplente que también estará ausente, una persona que ya causó baja o alguien sin permisos para autorizar en ese módulo. Cada caso se señala con un mensaje específico y un color de estado.
En las pruebas, los usuarios completaron el flujo, pero aparecieron tres ajustes. Tres de cinco pidieron poder editar o cancelar una suplencia ya registrada, por ejemplo si regresaban antes de lo previsto. Otros tres no entendieron las etiquetas de estado. Y tres consideraron innecesaria la columna “Acción por tiempo excedido”, porque escalar al siguiente nivel ya se da por hecho. A partir de eso se añadieron las opciones de editar y cancelar, se reescribieron las etiquetas y se eliminó la columna.
06.Limitaciones y restricciones
- •La idea era que la jerarquía se actualizara automáticamente a partir del sistema interno en el que recursos humanos registra las altas y bajas del personal. Todavía se estaban evaluando las limitaciones técnicas de esa integración, así que el diseño contempla la actualización manual.
- •El flujo de administración no llegó a validarse con usuarios. Solo dos personas lo iban a usar, y sus agendas no permitieron programar las sesiones.
- •Al inicio, la iniciativa contemplaba tanto la jerarquía comercial como la operativa, que corresponde a las tiendas. Por prioridad de negocio, el alcance se redujo a la comercial.
- •La muestra de las pruebas fue pequeña, con 3 usuarios en autorizaciones y 5 en suplencias, por la disponibilidad de las agendas.
07.Impacto
El diseño se entregó a desarrollo, con los flujos de autorizaciones y suplencias validados en pruebas de usabilidad y ajustados a partir de sus hallazgos.
La investigación dejó documentados el organigrama de la jerarquía comercial y los flujos de autorización de cuatro módulos, que sirvieron de base para el diseño.
Al cierre de mi participación, el módulo estaba en espera de su implementación, así que este caso documenta la investigación y las decisiones de diseño, no resultados en producción.
08.Qué aprendí
Involucrar a content design desde el inicio evita retrabajo. Ninguno de los tres usuarios encontró la configuración de autorizaciones por cómo se llamaba el submenú, y el acceso se resolvió al trabajar los textos con content design después de las pruebas. Con su participación desde el principio, ese problema se habría detectado antes.
Un directorio no explica cómo funciona una organización. El Excel decía quién era quién, pero no quién aprobaba qué ni cómo se escalaba. Eso solo apareció en los workshops con los líderes y en los mapas de autorización.
Lo que no salió: el flujo con más riesgo de adopción, la administración de la jerarquía, fue justo el que quedó sin validar. Si lo repitiera, lo probaría antes o, ante agendas complicadas, buscaría un formato más ligero, como una prueba asíncrona.
