Una consultora vende algo intangible: el tiempo, el conocimiento y la atención de gente inteligente. El resultado de ese trabajo suele dispersarse entre el correo, las unidades compartidas y las hojas de cálculo, y el cliente nunca sabe del todo en qué punto está su proyecto. Una plataforma de entrega al cliente lo reúne en un solo sitio: muestra el avance, lleva los entregables por la aprobación y da al socio una vista de toda la cartera en lugar de otra bandeja de entrada más.
Por nuestra experiencia, lo difícil no es diseñar un portal bonito, sino conciliar la comodidad del cliente con una separación férrea de datos entre clientes y una facturación limpia. Es un proyecto de ingeniería, no cosmético. Aunque no quieras montar tu propio departamento de TI, aportamos a los ingenieros que diseñan, construyen y mantienen esa plataforma junto a tu equipo de entrega.
¿Por qué una consultora necesita su propia plataforma de entrega?
Las herramientas de proyecto estándar gestionan bien las tareas internas, pero flojean justo en lo que el cliente ve y toca. La consultoría tiene su propia forma: cada cliente es un mundo aparte con sus datos, sus reglas de confidencialidad y su ritmo de aprobación, y una herramienta genérica obliga a compromisos en los que el cliente ve demasiado o demasiado poco.
Una plataforma de software para servicios profesionales hecha a medida permite fijar esas reglas a tu manera. El cliente recibe un único punto de entrada, con tu marca, a su proyecto; tú mantienes el control sobre lo que es visible, y el equipo deja de quemar horas montando informes de estado.
¿Qué es exactamente un portal de proyecto para el cliente?
Es la parte que el cliente ve, y la que más le importa. Un portal de proyecto para el cliente reúne lo que antes viajaba como adjuntos:
- el estado actual del proyecto y los próximos hitos,
- los entregables listos para revisión, en aprobación y aprobados,
- los documentos, decisiones y acuerdos con su historial de cambios,
- un canal de comunicación anclado a una tarea concreta, no a un hilo de correo.
Por debajo, un backend garantiza que cada cliente vea únicamente su parcela; el portal es solo la punta, y el trabajo real ocurre en la capa de datos.
¿Cómo se diseña el flujo de revisión y aprobación de entregables?
Aquí es donde la plataforma se paga sola, porque la aprobación es el punto por el que más se escapan el dinero y el tiempo. Cada entregable debería llevar un estado explícito y un camino claro:
- un borrador visible solo para el equipo,
- una entrega al cliente con notificación y plazo para comentarios,
- comentarios y una ronda de revisión registrados contra una versión concreta,
- una aprobación con fecha, persona y firma digital o confirmación,
- un cierre que pueda disparar un hito o una factura.
La clave es que cada transición deje rastro: quién, cuándo y sobre qué versión, de modo que «pero si esto lo aprobaste en marzo» sea una entrada de registro y no una discusión.
¿Cómo seguir los hitos y el alcance sin que se desborde?
El alcance en consultoría tiende a crecer, y cada petición extra parece inofensiva hasta que las sumas todas. La plataforma debería atar los hitos a entregables concretos y al alcance acordado, para que las desviaciones salgan a la luz de inmediato y no en el momento de facturar. Cuando un cliente pide algo fuera del contrato, el sistema permite marcarlo como cambio de alcance, valorarlo y pasarlo por aprobación, en vez de absorber en silencio el trabajo y el margen.
¿Cómo separar los accesos entre muchos clientes, en la práctica?
Este es el corazón de la plataforma y el sitio más fácil de estropear. La separación multi-tenant de datos significa que los datos de un cliente nunca pueden filtrarse a otro, ni siquiera por un descuido de un programador. En la práctica usamos una de dos estrategias: aislamiento lógico en una base compartida, donde cada registro lleva un identificador de tenant y se filtra a nivel de consulta y de permisos, o aislamiento total con una base o un esquema por cliente allí donde lo exige un regulador. Encima de eso aplicamos el control de acceso en el backend, no escondiendo elementos en la interfaz, porque un botón oculto no es una salvaguarda. Esta base la fijamos al principio, porque meter un aislamiento real en un sistema ya en marcha sale mucho más caro que diseñarlo desde el primer día.
¿Cómo construir roles y permisos para que cada uno vea solo lo suyo?
Los roles son el idioma en el que describes quién puede hacer qué, y una plataforma de consultoría necesita al menos unos cuantos mundos claramente separados:
- un socio o director de entrega con vista sobre toda la cartera,
- el equipo de proyecto, acotado a sus propios encargos,
- el cliente, que ve únicamente su proyecto y sus entregables,
- roles de invitado para subcontratistas o expertos, con acceso estrecho y limitado en el tiempo.
Unos permisos bien diseñados trabajan en silencio: cada uno simplemente ve exactamente lo que debe. Los diseñamos como un modelo coherente de roles y reglas, no como un montón de excepciones añadidas con el tiempo.
¿Por qué una plataforma de consultoría necesita trazas de auditoría y versionado?
Porque el trabajo de consultoría puede acabar en disputa, y la memoria humana es selectiva. Una traza de auditoría completa registra quién subió un documento, quién lo aprobó y cuándo cambió el alcance, de modo que una reclamación se encuentra con hechos y no con suposiciones. El versionado de entregables funciona igual: cada iteración de un informe o de un modelo se conserva, así que siempre sabes qué versión vio y aprobó el cliente. En sectores regulados esto suele ser un requisito y no un extra, porque un auditor no pregunta cuál es el estado ahora, sino cuál era en una fecha concreta.
¿Qué competencias aportamos y en cuánto tiempo se incorpora el equipo?
Una plataforma así la construye gente con un perfil concreto, que reunimos alrededor de tu proyecto y no «por si acaso»:
- un arquitecto de soluciones que fija el modelo multi-tenant, los permisos y las integraciones,
- desarrolladores backend (p. ej. Java, .NET, Node) responsables de la lógica, las API y los datos,
- desarrolladores frontend que construyen el portal del cliente y los paneles internos,
- un especialista DevOps que levanta la nube, el CI/CD y los entornos,
- apoyo de QA y UX donde importan por igual la seguridad y el uso diario.
Trabajamos como partner nearshore desde Polonia, así que operamos en una zona horaria cercana y entramos en las revisiones de código y en las reuniones sin una larga puesta en marcha. La búsqueda contra un brief suele cerrarse en unas tres semanas, y verificamos las competencias antes de empezar.
¿Cómo lo hacemos en RITS?
Lo tratamos como un producto pensado para durar años, no como un despliegue puntual:
- empezamos por el modelo de datos y la separación de clientes, porque es la decisión más difícil de revertir después,
- asignamos los roles al alcance y formamos el equipo en torno al stack en el que quieres trabajar,
- unimos portal, backend y nube en un conjunto mantenible,
- nos quedamos después del lanzamiento, desarrollando la plataforma como equipo dedicado o como refuerzo de equipo.
Lo más frecuente es entregarlo como software a medida construido por nuestro equipo y, cuando solo necesitas cerrar una brecha de competencias, como refuerzo de equipo. Que falte un caso de éxito en tu nicho exacto no significa que falte la competencia: aplicamos la misma ingeniería allí donde la confidencialidad y los múltiples tenants son el día a día.
¿Por dónde empezar con una plataforma de entrega al cliente?
Empieza por el momento más doloroso de tu entrega, normalmente la aprobación de entregables o la falta de transparencia de estado para el cliente. Describe el camino que debería recorrer un entregable desde el borrador hasta la firma, y qué datos tiene que ver el cliente y cuáles no puede ver nunca de otro cliente. Eso define el alcance de la primera versión, el modelo multi-tenant y los roles que necesitas. Las diferencias entre modelos de colaboración las describimos en nuestro artículo sobre modelos de colaboración en TI.
¿Vas a construir una plataforma de entrega al cliente para tu consultora? Hablemos - ajustaremos el equipo y la arquitectura a tu modelo de entrega.