Cómo pensar una plataforma para clientes y proveedores
Una plataforma que conecta clientes y proveedores puede parecer un conjunto de perfiles, solicitudes, cotizaciones y mensajes. Pero detrás de esas pantallas existe un sistema mucho más complejo: actores con intereses distintos, responsabilidades, decisiones y excepciones que deben funcionar como una sola operación.
Cuando una empresa decide digitalizar la relación entre sus clientes y proveedores, uno de los errores más frecuentes es comenzar imaginando las interfaces: un dashboard para el cliente, otro para el proveedor, una sección de solicitudes, quizá un chat y algunas notificaciones. El problema es que esas pantallas representan únicamente la superficie visible de una operación mucho más amplia.
Una plataforma de este tipo no conecta solamente usuarios. Conecta decisiones que generan consecuencias. Si un cliente modifica una solicitud, probablemente cambia el trabajo del proveedor. Si un proveedor rechaza un servicio, el cliente necesita una alternativa. Si existe un pago, también habrá confirmaciones, comisiones, cancelaciones, reembolsos o conciliaciones. Y si ocurre una excepción, alguien deberá intervenir para resolverla.
Por eso, una plataforma no debería comenzar diseñando dos interfaces. Debería comenzar diseñando la relación entre quienes participan en ella.
No son dos aplicaciones: es una sola operación
Pensar que existe una experiencia del cliente y otra completamente independiente para el proveedor suele llevar a productos fragmentados. En realidad, ambas experiencias pertenecen al mismo proceso y dependen constantemente una de la otra.
Un cliente puede crear una solicitud. Esa acción debe provocar algo del lado del proveedor: una oportunidad, una orden, una invitación o una tarea. El proveedor responde y esa respuesta modifica inmediatamente lo que observa el cliente. Después pueden aparecer una aceptación, una fecha programada, una entrega, una validación, una factura o una evaluación.
Cada interacción tiene una contraparte.
“En una plataforma de múltiples actores, cada acción de usuario es también una instrucción operativa para alguien más.”
Puedes escuchar este artículo aquí:
Aquí es donde herramientas como el service blueprint adquieren especial relevancia. No basta con entender lo que el usuario ve en pantalla. También hay que documentar los procesos, personas y sistemas que deben operar detrás para que esa experiencia pueda cumplirse. El frontstage puede parecer sencillo; el backstage rara vez lo es.
Primero define qué se intercambia
Antes de discutir funcionalidades conviene responder una pregunta mucho más importante: ¿qué intercambian realmente clientes y proveedores dentro de la plataforma?
Puede ser una cotización, una reservación, una orden de compra, una consulta, un proyecto, una disponibilidad, un servicio profesional, una entrega o información. Ese intercambio principal debería convertirse en la columna vertebral del producto.
Imaginemos una plataforma que conecta empresas con proveedores especializados. El cliente podría publicar una necesidad, recibir propuestas, comparar alternativas, seleccionar a un proveedor, aprobar entregables y cerrar el servicio. El proveedor necesitaría descubrir oportunidades relevantes, evaluar requerimientos, enviar una propuesta, gestionar el trabajo y documentar la entrega.
Hasta aquí el flujo parece sencillo. La complejidad aparece cuando comenzamos a preguntar qué puede ocurrir entre esos momentos. ¿Quién puede modificar una solicitud? ¿Hasta qué etapa? ¿Un proveedor puede retirar una propuesta? ¿El cliente puede renegociar condiciones después de aceptarla? ¿Qué ocurre cuando nadie responde? ¿Las propuestas tienen vigencia? ¿Quién decide que el trabajo fue completado? ¿Qué pasa cuando ambas partes no están de acuerdo?
Esas preguntas definen cómo debe comportarse el producto.
Mientras no tengan respuesta, diseñar pantallas significa representar visualmente una operación que todavía no está definida.
Diseña estados antes de diseñar pantallas
Las plataformas transaccionales funcionan mediante estados. Una solicitud puede estar en borrador, publicada, en revisión, asignada, en proceso, entregada, rechazada, cancelada o completada. Una cotización puede estar pendiente, aceptada, vencida o retirada. Un pago puede estar pendiente, autorizado, retenido, transferido, reembolsado o disputado.
Los nombres cambian según cada negocio, pero el principio permanece: el sistema necesita saber qué está ocurriendo, qué ocurrió antes y qué acciones están disponibles después.
Definir estos estados permite establecer permisos y transiciones. Un proveedor quizá pueda modificar una propuesta mientras el cliente no la haya aceptado, pero después deberá solicitar un cambio. Un cliente podría cancelar una orden durante determinada etapa, pero no cuando el proveedor ya realizó una parte sustancial del trabajo. Una entrega podría requerir aprobación antes de liberar un pago.
En productos que incorporan transacciones económicas, esta arquitectura se vuelve todavía más importante. Incorporar pagos no significa únicamente agregar un botón para cobrar. Pueden existir onboarding de proveedores, validación de cuentas, transferencias, comisiones, devoluciones, disputas, conciliaciones y procesos de riesgo. Cada uno introduce nuevos escenarios que el sistema debe reconocer y gestionar.
“La complejidad de una plataforma no está en cuántas pantallas tiene, sino en cuántas decisiones debe coordinar sin obligar al usuario a entenderlas.”
Puedes ver este artículo aquí:
Una interfaz bien diseñada oculta complejidad operativa. No elimina esa complejidad: la convierte en acciones claras para las personas que utilizan el producto.
Cada actor necesita decidir algo diferente
Cliente y proveedor pueden estar observando el mismo proceso, pero rara vez necesitan la misma información.
El cliente necesita comprender qué opciones tiene, cuánto cuestan, cuándo estarán disponibles, qué proveedor puede resolver mejor su necesidad y qué está sucediendo con aquello que contrató. El proveedor necesita evaluar qué solicitudes le interesan, cuáles puede atender, qué información necesita antes de comprometerse, cuáles son sus tareas pendientes y qué debe hacer para avanzar cada servicio.
Incluso cuando ambos observan el mismo objeto —por ejemplo, una orden— lo interpretan desde responsabilidades diferentes.
Por eso, diseñar dos dashboards casi idénticos y cambiar únicamente algunos botones suele ser una mala solución. Una mejor pregunta es: ¿qué necesita decidir esta persona en este momento del proceso?
Diseñar alrededor de decisiones y responsabilidades permite construir interfaces más claras que diseñar alrededor de módulos genéricos. La plataforma debería mostrar a cada actor la información suficiente para avanzar sin exponerle complejidad administrativa que no necesita conocer.
La confianza forma parte del producto
Cuando una plataforma coloca a dos partes en contacto, especialmente si antes no tenían una relación, aparece otra capa fundamental: la confianza.
Identidad, perfiles completos, experiencia, certificaciones, disponibilidad, precios, evaluaciones, evidencia de trabajos anteriores, condiciones comerciales, políticas de cancelación, mecanismos de reclamación y soporte dejan de ser elementos secundarios. Se convierten en componentes funcionales del sistema.
El cliente necesita confiar en quien realizará el servicio. El proveedor necesita confiar en la legitimidad de la oportunidad, en las condiciones planteadas y en la posibilidad de recibir correctamente su pago. La plataforma, a su vez, necesita mecanismos para reducir incertidumbre y hacer visibles las señales que permiten tomar mejores decisiones.
En plataformas con múltiples participantes también existe el reto de mantener suficiente actividad para que las relaciones generen valor. Tener cientos de proveedores registrados sirve de poco si los clientes no encuentran disponibilidad, y atraer clientes tampoco es suficiente si los proveedores no reciben oportunidades relevantes.
Una plataforma funciona cuando logra convertir participación en resultados.
Existe un tercer usuario: la operación interna
Cliente y proveedor suelen ocupar toda la atención durante el diseño, pero muchas plataformas necesitan un tercer universo de usuarios: las personas que administran el sistema.
Alguien tendrá que aprobar proveedores, revisar información, gestionar categorías, atender incidencias, intervenir en controversias, supervisar transacciones, consultar métricas, bloquear cuentas, modificar permisos o resolver situaciones que la automatización no pudo manejar.
Si estas capacidades no se diseñan desde el principio, el negocio termina creando una segunda operación fuera del producto. Los usuarios trabajan dentro de la plataforma, mientras el equipo interno resuelve problemas mediante WhatsApp, correos electrónicos, hojas de cálculo y modificaciones manuales.
Entonces aparece una contradicción: la empresa construyó una plataforma digital, pero sigue administrándola con procesos fragmentados.
Un buen producto no sólo mejora lo que ocurre frente al usuario. También debe hacer más eficiente aquello que sucede detrás.
Las excepciones revelan el producto que realmente necesitas
El happy path suele ser relativamente sencillo: alguien solicita, alguien responde, ambas partes acuerdan, el servicio se realiza y el proceso termina. Pero una plataforma real debe funcionar también cuando ese recorrido ideal se rompe.
¿Qué sucede si dos proveedores aceptan simultáneamente una oportunidad? ¿Si el proveedor deja de responder? ¿Si el cliente cambia el alcance después de aceptar una cotización? ¿Si la entrega llega incompleta? ¿Si una persona puede actuar como cliente y proveedor? ¿Si una empresa necesita varios usuarios con diferentes permisos? ¿Si una factura debe emitirse a otra razón social? ¿Si alguien cancela cuando el trabajo ya comenzó?
Estas situaciones no deberían descubrirse después de desarrollar el software.
Las excepciones ayudan a identificar decisiones que todavía no han sido documentadas. También permiten descubrir dónde será necesaria una intervención humana, qué acciones deberían quedar restringidas y qué información debe conservar el sistema para mantener trazabilidad.
Antes de llegar a wireframes de alta fidelidad conviene tener, al menos, un mapa de actores, el intercambio principal, el flujo general, los estados, permisos, excepciones y procesos administrativos.
Después de eso, las pantallas comienzan a tener sentido.
Pensar primero la operación cambia el producto
Una plataforma para clientes y proveedores puede terminar siendo un portal B2B, una red privada de abastecimiento, un marketplace, un sistema de contratación, una plataforma de mantenimiento, una solución para servicios profesionales o una combinación de varios modelos.
La tecnología y las funcionalidades específicas pueden cambiar, pero la pregunta estratégica permanece: ¿cómo debe coordinarse la relación entre todos los participantes para que el sistema produzca valor?
La respuesta rara vez empieza en Figma.
Empieza observando cómo funciona hoy la operación, dónde se pierde información, cuáles son las decisiones críticas, qué necesita conocer cada actor, qué criterios siguen los equipos aunque nunca los hayan documentado y qué situaciones obligan actualmente a una persona a intervenir.
A partir de ahí podemos decidir qué conviene automatizar, qué debe permanecer supervisado y qué interfaz necesita realmente cada usuario.
Porque las pantallas son la consecuencia visible de una operación definida. No deberían ser el punto de partida.
Una buena plataforma no es aquella que consigue colocar clientes de un lado y proveedores del otro. Es aquella que consigue que ambos avancen dentro de una misma operación con claridad, confianza, trazabilidad y el menor número posible de fricciones.
¿Tu plataforma necesita realmente más funcionalidades o necesita primero entender mejor cómo deben relacionarse clientes, proveedores y operación?
¿Tu idea necesita más claridad antes de convertirse en código? En Sr. Zorro App Design Studio te ayudamos a definir, validar y diseñar productos digitales listos para desarrollo. Conoce más en www.srzorro.com.
Escrito por: Editorial
Fuentes
Nielsen Norman Group — Service Blueprints: Definition. Una referencia para comprender la relación entre experiencia visible, procesos internos, personas y sistemas que hacen posible un servicio digital.https://www.nngroup.com/articles/service-blueprints-definition/
Nielsen Norman Group — 5 Steps to Service Blueprinting. Aborda cómo documentar acciones del usuario, procesos internos y recursos de soporte dentro de una experiencia de servicio.https://www.nngroup.com/articles/5-steps-service-blueprinting/
Nielsen Norman Group — Trust and Credibility: Ecommerce UX. Investigación sobre los elementos de experiencia que influyen en la percepción de confianza y credibilidad en productos digitales.https://www.nngroup.com/reports/ecommerce-ux-trust-and-credibility/
Stripe — Connect. Documentación sobre plataformas con múltiples participantes, onboarding, cuentas conectadas, pagos, transferencias y administración de transacciones.https://docs.stripe.com/connect
Sharetribe — How to Build a Two-Sided Marketplace. Referencia sobre dinámicas de oferta, demanda, confianza y liquidez en plataformas que conectan diferentes grupos de usuarios.https://www.sharetribe.com/how-to-build/two-sided-marketplace/
Comentarios