Un portal de cliente personalizado recupera su coste en el momento en que las actualizaciones dejan de vivir en su bandeja de entrada. El error en el desarrollo de portales de cliente es tratarlo como la construcción de una plataforma. Entregue la versión mínima que elimine los tres correos que más se repiten, y amplíela una vez que los clientes realmente inicien sesión.
Ahora mismo usted es la API de estado de cada proyecto. Un cliente escribe «¿alguna novedad?» y usted interrumpe el trabajo real para capturar una pantalla, pegar un enlace y tranquilizarle de que todo va bien.
Probablemente haya parcheado esto con carpetas compartidas en Drive, un enlace de WeTransfer, un Calendly y una hoja de cálculo que solo usted sabe leer. Esa solución aguanta hasta un puñado de clientes. Esta guía explica cuándo un portal supera a otra suscripción SaaS, la v1 que merece la pena construir primero, el stack que mantiene bajo el coste de mantenimiento y el momento en que la inversión se recupera.
- Construya para tres funciones: estado, documentos y la acción que los clientes siguen pidiéndole por correo. Todo lo demás es v2.
- Compre cuando el flujo de trabajo sea genérico, construya cuando el flujo de trabajo sea su negocio. Un portal que refleja cómo entrega realmente su servicio es la parte que ningún SaaS vende.
- Un primer portal cuesta entre 20.000 € y 50.000 €, entregado en semanas. La mayor parte de ese precio paga autenticación, permisos y trabajo de fiabilidad. Las pantallas son la parte barata.
- El retorno es operativo: menos correos de estado, entregas más rápidas y tiempos de respuesta que se pueden medir.
Qué reemplaza realmente un portal de cliente
Un portal de cliente es un único espacio autenticado donde el cliente ve su trabajo con usted y actúa sobre él. Sin tecnicismos, reemplaza un conjunto de herramientas que ya está pagando.
La solución habitual antes de un portal combina una carpeta compartida en Google Drive, un hilo de correo por cliente, un enlace de WeTransfer cuando los archivos son grandes, un Calendly para la agenda y una hoja de cálculo que solo usted entiende. Cada herramienta funciona por separado. Juntas tienen fisuras: los enlaces caducan, se envía la versión incorrecta y nadie responde a «¿dónde estamos?» sin su intervención.
Un portal reduce todo eso a las tres funciones por las que los clientes siguen escribiéndole.
- Estado. El cliente ve la fase actual sin preguntar, por lo que el correo «¿alguna novedad?» deja de llegar.
- Documentos. Carga y descarga en un único lugar con versiones y protegido por contraseña, de modo que el archivo correcto es el único archivo.
- Acción. La única tarea que siguen pidiéndole: aprobar un borrador, dar el visto bueno a una fase o enviar la siguiente información.
La mayoría de los equipos cruzan esta línea sin darse cuenta. Si las carpetas compartidas y una hoja de estado han empezado a costarle horas facturables, ese es el momento de definir el alcance de la construcción. webvise desarrolla portales de cliente personalizados sobre un stack diseñado para mantener bajo el coste de mantenimiento, y la llamada de descubrimiento define el alcance de la v1 antes de escribir una sola línea de código.
Cuándo un portal personalizado supera a otra suscripción SaaS
Existe suficiente SaaS de portales de cliente en el mercado. HubSpot tiene portales, SuiteDash y Copilot venden productos específicos para ello, y Notion o Google Sites pueden simularlo. Compre uno de esos cuando la interacción con sus clientes sea genérica: compartir un documento, recopilar un archivo, mostrar una factura.
Construya un portal personalizado cuando el flujo de trabajo sea el producto. Si los pasos por los que avanza un cliente son propios de su forma de entregar, una herramienta genérica solo los modela con un apaño, y ese apaño es lo que el cliente percibe cada vez que inicia sesión.
Esta es la decisión de construir frente a comprar aplicada a una herramienta concreta. El marco completo de construir frente a comprar cubre la versión general. A continuación, la decisión según cada situación.
| Su situación | Opción más económica | Por qué |
|---|---|---|
| Compartir archivos y mostrar facturas, sin personalización | Comprar un SaaS de portal de cliente o usar HubSpot | Necesidad genérica, herramienta genérica, menor coste inicial |
| Un proceso de varios pasos fijo por el que avanzan los clientes | Construir un portal personalizado | Los pasos son su negocio, y una herramienta genérica impone compromisos que los clientes notan |
| Pocos clientes, bajo volumen, archivos ocasionales | No hacer nada todavía, ordenar Drive y el correo | Una construcción no se recuperará con este volumen |
| Reintroduce los mismos datos en dos sistemas | Construir y conectar los sistemas con una API | El portal elimina la doble entrada, que es donde se pierden las horas |
Qué construir primero: la v1 que recupera la inversión
La forma más rápida de malgastar el presupuesto de un portal es entregar una plataforma. La versión que recupera la inversión es pequeña y específica, delimitada a un flujo de trabajo que se ejecuta cada semana.
Construya un único objeto y el ciclo alrededor de él. Para una agencia ese objeto es un proyecto, para una entidad financiera es una solicitud, para una clínica es un caso. Añádale inicio de sesión, un estado, un espacio para documentos y una notificación cuando cambie el estado. Eso es toda la v1.
- Autenticación y roles. El cliente ve solo sus datos, su equipo lo ve todo. Aquí es donde hay que hacerlo bien.
- Un objeto con una línea de tiempo de estado. El cliente observa cómo avanza por las fases sin enviar un solo correo.
- Carga y descarga de documentos. Con versiones, protegidos por inicio de sesión y con un registro de quién hizo qué y cuándo.
- Notificaciones por correo. Un cambio de estado envía un único correo, de modo que nadie inicia sesión para descubrir que no ha cambiado nada.
Las funciones que parecen imprescindibles en la reunión inicial suelen ser las que conviene aplazar. A continuación, qué dejar para más adelante y por qué esperar no tiene coste.
| Tentador en v1 | Entregar en | Por qué esperar |
|---|---|---|
| Chat integrado en el portal | v2 o nunca | El correo ya funciona, y el chat añade carga de moderación y notificaciones |
| Facturación y pagos al cliente | v2 | Los pagos quedan fuera del ciclo de estado de la v1, y Stripe se incorpora una vez que los clientes inician sesión |
| Aplicación móvil nativa | Quizás nunca | Un portal web rápido y responsivo cubre alrededor del 95 % del uso de los clientes |
| SSO y permisos empresariales | Cuando un cliente enterprise lo solicite | Sin retorno hasta que alguien lo requiera de verdad |
El stack que mantiene bajo el coste de mantenimiento de un portal
Un portal tiene una vida útil de años, por lo que el coste de construcción es menor que el de mantenimiento. El stack determina ese segundo número, y un portal construido con parches resulta caro la primera vez que algo falla.
Los portales desarrollados por webvise funcionan sobre Next.js y React, de modo que el frontend y el backend comparten una única base de código. tRPC proporciona APIs con tipos seguros, lo que significa que un campo renombrado rompe la compilación en lugar de la producción. PostgreSQL con Drizzle almacena los datos, y Better Auth gestiona el inicio de sesión y los roles. Stripe cubre los pagos cuando llega la facturación, Resend envía las notificaciones, y todo se despliega en Vercel directamente desde un commit.
Dos cifras importan para una herramienta de cliente. Debe cargar en menos de 1,2 segundos con una conexión normal y obtener una puntuación superior a 90 en Lighthouse, porque una herramienta lenta se abandona y los clientes vuelven a escribir por correo. Los proyectos de webvise se ajustan a ese estándar y se entregan con un informe de rendimiento medido en el sistema en producción.
Cuándo se recupera la inversión y cuándo no
Un primer portal de cliente cuesta aproximadamente entre 20.000 € y 50.000 €, la misma horquilla que el nivel de portal de cliente en nuestra guía de costes de aplicaciones web personalizadas. El retorno es operativo.
Cuente las horas que su equipo dedica cada semana a responder «¿alguna novedad?», reenviar archivos y reintroducir datos entre sistemas. Un portal elimina la mayor parte de eso, y también elimina el traspaso fallido que silenciosamente cuesta un cliente. Cuando esas horas son reales, un portal en esta horquilla se recupera en menos de un año.
La inversión no se recupera con bajo volumen. Con un puñado de clientes y archivos ocasionales, una carpeta compartida ordenada y una plantilla de correo clara superan a una construcción personalizada. Las señales de que ha superado esa solución son operativas y aparecen en sus números antes de aparecer en una reunión.
Si las actualizaciones de clientes siguen viviendo en su bandeja de entrada, identifique el objeto y las tres funciones que cubriría su portal, y luego defina el alcance de la v1 según el volumen real que tiene. webvise desarrolla portales de cliente personalizados sobre el stack anterior y define ese alcance de la v1 en una breve llamada de descubrimiento. Dé el primer paso en webvise.