Parq.ai

Cada cliente operaba con distintas ubicaciones, proveedores, acuerdos de servicio y reglas de negocio. El reto era sostener esa variabilidad en un producto coherente, sin crear interfaces independientes para cada configuración.

Junto con Producto, Operaciones e Ingeniería, traduje requerimientos de negocio en estructuras de información, modelos de interacción y diseños de alta fidelidad. La revisión y la iteración alineaban la experiencia propuesta con las restricciones operativas antes del desarrollo.

Para Site Plans, estructuré mapas infográficos con medidas aproximadas para representar estacionamientos, carriles y zonas operativas. Así conecté los flujos digitales con el movimiento de vehículos y la capacidad del espacio físico.

Fleet Management, Workflows, Tickets, órdenes de trabajo, transporte, Pricing y Readiness compartían el activo y su historial como referencia. La navegación y los patrones de contexto conectaban estas áreas sin exigir que las personas interpretaran la arquitectura del sistema.

Exploré vínculos explícitos entre activos, tickets y órdenes de trabajo para seguir un problema entre registros, actividades, responsables y condiciones de SLA sin perder el contexto del activo.

El Exception Engine evaluaba condiciones de las órdenes de trabajo y generaba tickets con una secuencia de responsables. Diez disparadores configurables contemplaban trabajo sin asignar, detenido, envejecido o incompleto. Los estados verde, amarillo y rojo comunicaban urgencia; el umbral documentado de amarillo era 70–99% y el rojo comenzaba en 100%.

Las reglas de Asset Readiness dependían de lógica por cliente que Operaciones no podía consultar ni modificar sin Ingeniería. Expresé la configuración mediante reglas en lenguaje natural, contemplando múltiples condiciones, advertencias, conflictos, cambios manuales, reglas migradas y validación.

Consultar un precio exigía localizar la actividad y el proveedor, abrir el SLA, buscar el margen y calcular el importe final a mano. La experiencia propuesta reunía las vistas de cliente, lote y actividad, con cálculos desde el costo del proveedor más margen o desde el precio al cliente hacia el costo interno. El PRD fijó consultas en menos de diez segundos como objetivo, no como resultado medido.

El PRD de Vendor Performance organizó la salud del proveedor, los tiempos de respuesta, el retrabajo, el cumplimiento de SLA, el tiempo fuera de servicio y las comparaciones de costo alrededor de decisiones que requerían atención operativa.

La evolución hacia una plataforma multicliente incorporó activos compartidos, propiedad distribuida, alianzas, acceso entre clientes, permisos, posesión, SLAs y trazas de auditoría. Estos requerimientos ampliaron el diseño desde flujos individuales hacia bases empresariales reutilizables.

Desarrollé y mantuve patrones reutilizables de navegación, tablas, filtros, formularios y comunicación de estados en 7+ áreas centrales del producto. El sistema ofreció una base consistente para nuevos flujos y configuraciones.

Los diseños pasaban por revisión de Producto, refinamiento e implementación, con ajustes posteriores conforme evolucionaban los requerimientos operativos.

Estas cifras describen el contexto operativo de la plataforma, no una mejora medida atribuible al diseño.

La claridad en un producto empresarial depende de hacer explícitas las relaciones, diseñar para las excepciones y mantener patrones reutilizables conforme crece el sistema.