El diagnóstico de sitios web SaaS que tu agencia puede reutilizar sin hacer que los clientes parezcan iguales

Summary

¿Cuántas veces en este trimestre has hecho exactamente la misma llamada de descubrimiento —las mismas preguntas sobre el producto, el cliente, el competidor— para dos clientes que insistían en que eran completamente diferentes? Ya sabes que las respuestas serán diferentes, pero las funciones que cada sitio SaaS debe cumplir no lo son. Cada sitio web de producto SaaS es un pequeño conjunto de máquinas que realizan las mismas tareas: explicar qué hace el producto, mostrar cuánto cuesta, decir a los desarrolladores cómo integrarlo, responder a las objeciones que detienen una compra y demostrar que la empresa es creíble. Un diagnóstico repetible que audite esas cinco funciones sobrevivirá al contacto con cualquier cliente, porque las funciones no cambian. El sistema que construyes alrededor de él es lo que te permite pasar de un proyecto al siguiente sin empezar de cero. Lleva menos tiempo que tu proceso de descubrimiento actual, da al cliente una razón clara para confiar en ti y produce un entregable que no parece una plantilla, porque las preguntas son estándar pero las respuestas son específicas.

¿Cuántas veces en este trimestre has hecho exactamente la misma llamada de descubrimiento —las mismas preguntas sobre el producto, el cliente, el competidor— para dos clientes que insistían en que eran completamente diferentes? Ya sabes que las respuestas serán diferentes, pero las funciones que cada sitio SaaS debe cumplir no lo son. Cada sitio web de producto SaaS es un pequeño conjunto de máquinas que realizan las mismas tareas: explicar qué hace el producto, mostrar cuánto cuesta, decir a los desarrolladores cómo integrarlo, responder a las objeciones que detienen una compra y demostrar que la empresa es creíble. Un diagnóstico repetible que audite esas cinco funciones sobrevivirá al contacto con cualquier cliente, porque las funciones no cambian. El sistema que construyes alrededor de él es lo que te permite pasar de un proyecto al siguiente sin empezar de cero. Lleva menos tiempo que tu proceso de descubrimiento actual, da al cliente una razón clara para confiar en ti y produce un entregable que no parece una plantilla, porque las preguntas son estándar pero las respuestas son específicas.

'Mis clientes son demasiado diferentes para un solo sistema'

Aplica el mismo diagnóstico de cinco puntos a cada cliente antes de escribir una palabra de copy o abrir una herramienta de diseño. Las diferencias que hacen especiales a tus clientes —industria, audiencia, modelo de precios— se asientan sobre una base compartida. Un SaaS de nóminas y una herramienta de programación de redes sociales no tienen nada en común excepto las cinco funciones que cada página está realizando. Si auditas esas funciones, encontrarás los mismos patrones en los mismos lugares.

Página o sección	Lo que tu cliente suele pedir	Lo que realmente ocurre en la página
Muestra de funciones	'Muestra cada función que construimos'	Mostrar el resultado que obtiene el usuario, no solo la función. Las imágenes como capturas de pantalla, GIF o vídeos deben demostrar un momento en que el producto cambia la forma de trabajar de alguien.
Precios	'Haz que los precios sean fáciles de leer'	El comprador se ve obligado a decidir qué plan es para él. Los niveles deben leerse como una progresión que guía la elección, no como una lista plana de precios.
Documentación de API	'Nuestros desarrolladores lo encontrarán en la documentación'	A menudo es la primera prueba que un desarrollador ejecuta al evaluar si se puede confiar en el producto. La claridad aquí es una característica, no un lujo.
Sección de preguntas frecuentes	'Responde preguntas para que bajen las llamadas de soporte'	Lo último que lee un comprador antes de hacer clic en un botón. Debe abordar las objeciones de precios y los casos límite, no solo preguntas genéricas de la empresa.
Prueba social	'Pon los logotipos'	La evidencia de que las afirmaciones hechas anteriormente son verdaderas. Los logotipos y los testimonios son indicadores de confianza, no decoración.

Un diagnóstico no es una plantilla. Es un conjunto de preguntas que haces en cada página: ¿esto hace que el comprador entienda qué hace el producto?, ¿hace que el siguiente paso sea obvio?, ¿responde a la objeción que está bloqueando la venta? Cuando haces estas preguntas con un cliente presente, el cliente te ve como la persona que entiende su mercado, y no como la décima agencia que mostró una presentación de diapositivas. La investigación sobre sitios web SaaS señala a empresas como HubSpot, Slack y Zendesk como ejemplos de secciones de preguntas frecuentes bien organizadas, y a Stripe, GitHub y Twilio como estándares de claridad en documentación. Ninguna de esas empresas llegó allí tratando las preguntas frecuentes como un montón de tickets de soporte. Las trataron como una superficie de conversión. Esa es la actitud que tu diagnóstico debe aportar a cada cliente.

Considera a un cliente que vende software de inventario y a otro que vende software de nóminas. El diagnóstico a menudo revela las mismas tres carencias: la página de funciones menciona módulos en lugar de resultados, la página de precios no justifica el salto entre planes y las preguntas frecuentes responden a preguntas de soporte en lugar de dudas de compra. Como has visto estas carencias en ambos, sabes exactamente qué pedir en la etapa de diseño. El cliente ve un proceso específico, no genérico. Escribe el diagnóstico como un PDF de una página con una puntuación del 1 al 5 para cada función y una nota para cada una. Compártelo con el cliente antes del inicio del diseño. Esto te da un vocabulario compartido y convierte la auditoría en un entregable por el que puedes cobrar. Este es el núcleo de un sistema repetible, y tenemos un recorrido aparte sobre cómo configurar ese sistema aquí.

'Hará que nuestro trabajo parezca el de los demás'

Estandariza las preguntas que haces, no las respuestas que entregas. El diagnóstico te da una rúbrica de puntuación, no un diseño. La investigación sobre muestras de funciones SaaS muestra que utilizan imágenes como capturas de pantalla, GIF o vídeos, pero el contenido de esas imágenes es diferente para cada producto. La función de informes de salarios en una herramienta de RR. HH. y la función de escaneo de códigos de barras en software de inventario nunca se verán iguales. Lo que permanece constante es la pregunta que planteas a tu mente estratégica: '¿Esta página muestra el resultado, o solo la función?'

El formulario de admisión de un médico no hace que todos los diagnósticos sean iguales; hace que el médico sea fiable. Tu marco es el formulario de admisión. El cliente sigue recibiendo un sitio web personalizado, pero tú obtienes un diagnóstico repetible. Lo que realmente hará que tu trabajo parezca genérico es la falta de un diagnóstico, porque sin él recurres a la misma imagen principal, el mismo diseño de tres columnas de funciones, la misma estructura de página de inicio que usaste en el último proyecto solo para avanzar rápido. El diagnóstico te obliga a justificar la estructura a partir de la evidencia, de modo que cada sitio sea estructuralmente diferente donde debe serlo.

En la práctica, esto significa que el diagnóstico podría decirte que empieces la página de funciones de un cliente con un vídeo de un asistente de importación y la de otro con un GIF de un constructor de informes de arrastrar y soltar. La estructura de la página sigue siendo la misma, pero los recursos, el copy y el ritmo son únicos. El cliente ve un trabajo personalizado; tú ves un proceso repetible. Cuando presentas el diagnóstico a un cliente, demuestras que sabes lo que todo sitio SaaS debe hacer. Eso es una propuesta más fuerte que 'crearemos un diseño único'. El diseño es consecuencia del diagnóstico, no el punto de partida.

'No tenemos tiempo para auditar todas las páginas'

Haz la versión enfocada de 90 minutos, no una auditoría completa. La mayoría de los procesos de descubrimiento de las agencias ya son una auditoría, solo que desestructurada. Dedicas cuarenta y cinco minutos a una llamada de descubrimiento que cubre antecedentes, competidores y 'qué quieres obtener de esto', y luego pasas semanas reaccionando. El diagnóstico lo invierte: puntúas las cinco funciones, enumeras las correcciones de mayor impacto y pasas al diseño. Ahorra tiempo porque dejas de rehacer trabajo después de la primera revisión de diseño. Las correcciones más baratas son las que haces antes de que alguien vea píxeles.

Aquí tienes una división concreta de 90 minutos: el bloque uno (30 minutos) revisa la página de inicio y la página de funciones en busca de las cinco funciones. El bloque dos (30 minutos) revisa rápidamente la página de precios y las preguntas frecuentes. El bloque tres (15 minutos) comprueba si la documentación de la API responde a '¿puedo extraer los datos?', y los últimos 15 minutos enumeran las correcciones principales y el responsable de cada una. No necesitas leer cada página de arriba a abajo; necesitas averiguar si la función se está cumpliendo. Si la página de precios no tiene preguntas frecuentes, el diseño se aprobará más rápido si lo detectas antes de maquetar la cuarta columna de precios. Si la documentación de la API está escrita según un estándar interno en lugar del estándar del desarrollador, lo sabes antes de informar al redactor.

En un proyecto, el diagnóstico reveló que el comprador objetivo tenía pavor a la migración de datos. La pregunta frecuente que añadimos para esa respuesta costó dos horas de redacción. Sin el diagnóstico, ese miedo nos habría acompañado durante el diseño, el desarrollo y hasta una sobrecarga de soporte posterior al lanzamiento. La versión de 90 minutos no es una fase que precede al proyecto; es la primera fase del proyecto. También te da una forma honesta de estimar: sales de la sesión con una lista de lo que existe y lo que no, de modo que la propuesta que escribes se basa en evidencia, no en suposiciones.

'Mi cliente no técnico no necesita documentación de API'

Usa un árbol de decisión, no una lista de verificación: si el producto tiene una API pública o una historia de integración, la documentación de la API es una página central; si no, omítela conscientemente. La investigación sobre documentación de API es contundente: empresas como Stripe, GitHub y Twilio marcan el estándar de claridad documental porque sus desarrolladores son, en efecto, los compradores. Si tu cliente tiene una integración orientada a desarrolladores, la documentación no es una conveniencia para desarrolladores; es un dispositivo de confianza que se sitúa junto a la página de precios. Un cliente no técnico puede que nunca la mire, pero el desarrollador que evalúa una compra sin duda lo hará.

El árbol de decisión es parte del sistema. Cuando el cliente dice 'no tenemos una audiencia de desarrolladores', haz una pregunta: '¿alguna parte de tu integración requiere que un desarrollador conecte el producto con otro sistema?' Si es así, la documentación se queda. Si no, la omites y pones el esfuerzo en las preguntas frecuentes y la prueba social. Aplica la misma lógica a la prueba social: para un cliente, una fila de logotipos es suficiente; para otro, se requiere un testimonio detallado con resultados medibles. El diagnóstico te dice cuál, en lugar de recurrir por defecto a todos los logotipos que puedas recopilar. Esa elección es lo que hace que el marco sea repetible sin ser rígido. Si necesitas averiguar qué significa 'claridad' en la práctica, esta guía sobre documentación de API recorre la estructura.

'Pero mi cliente quiere una lista de funciones, no resultados'

Cuando el cliente dice que quiere mostrar sus funciones, pídele que nombre la tarea de usuario que cada función desbloquea. La suposición común es que la muestra de funciones es donde se gana la venta. El diagnóstico sugiere lo contrario: en un sitio SaaS típico, la página de precios es donde ocurre el cálculo mental final, y las preguntas frecuentes son donde se resuelve la última objeción. La muestra de funciones es esencial, pero su tarea es estrecha: mostrar el momento en que el producto se vuelve valioso. Una lista larga de funciones con un párrafo debajo de cada una no logra eso.

Los clientes se resisten a esto porque una lista se siente tangible y fácil de aprobar. Pero una página con cincuenta funciones produce un visitante que hojea, y un visitante que hojea tu página de funciones ya ha movido su atención a la tabla de precios. El trabajo de tu sistema es hacer que el cliente se sienta cómodo con la disyuntiva: no estás eliminando funciones, las estás moviendo a donde serán leídas. Una pregunta frecuente bien ubicada que diga 'nos integramos con las herramientas que ya usas' a menudo hace más trabajo que una página de funciones que dice lo mismo bajo el título equivocado. Este es el matiz que la mayoría de los artículos omiten, y es precisamente el tipo de disyuntiva que un diagnóstico puede hacer explícita.

El diagnóstico también te da una razón defendible para oponerte a la expansión del alcance. Cuando un cliente pide añadir otra fila de funciones a la página de inicio, puedes señalar la tabla y decir 'el trabajo de esa página es mostrar resultados, no catalogar funcionalidades'. Un constructor de páginas genérico podría generar una cuadrícula de funciones, pero no puede decidir si la cuadrícula debe ser reemplazada por un vídeo o una sección de preguntas frecuentes. Esa decisión es el verdadero producto, y es la razón por la que un marco no mercantiliza tu trabajo.

'Ya tenemos un proceso interno'

Si tu agencia tiene un proceso para la página de inicio o una lista de verificación para la página de precios, la objeción suele ser que no se quiere reemplazar. No tienes que hacerlo. El diagnóstico de cinco funciones no es un reemplazo de tu proceso creativo; es un front-end que lo alimenta. El problema con la mayoría de los procesos internos es que son invisibles. Viven en la cabeza del diseñador sénior. El diagnóstico externaliza el proceso para que un miembro junior del equipo pueda hacer la primera pasada, y tú puedas revisarlo en minutos. Esa es la repetibilidad que realmente necesitas en una agencia con múltiples clientes.

Un proceso visible también cambia la conversación con los clientes. En lugar de 'tenemos un proceso de diseño propietario', puedes decir 'ejecutamos un diagnóstico contra las cinco funciones que todo sitio SaaS debe cumplir, y luego diseñamos en torno a los hallazgos'. La primera frase es una caja negra que pone nerviosos a los clientes. La segunda es un método claro que los invita. El diagnóstico se convierte en parte de tu historia de ventas, no solo en una herramienta de producción.

'El cliente dice que el sitio actual está bien'

El diagnóstico sigue funcionando si el cliente no quiere nada más que una actualización. Te da una línea de base. Puntúas el sitio actual y demuestras que una página específica está fallando en una función específica. Puedes decir: 'Tu página de preguntas frecuentes está organizada, pero no responde a la pregunta que tu equipo de ventas escucha cada semana', y eso es una razón basada en hechos para cambiar, no una preferencia estética. Esta suele ser la forma más suave de empezar un rediseño: no le estás diciendo al cliente que su sitio es feo, le estás diciendo que una función no se está cumpliendo.

Esto también te protege del fallo común en el que un cliente insiste en mantener un elemento querido de la página de inicio que perjudica la conversión. El diagnóstico te da el vocabulario para decir 'ese elemento no cumple ninguna de las cinco funciones', y el cliente puede ver la evidencia. La objeción ya no es una cuestión de gusto.

El diagnóstico es el producto

La repetibilidad no consiste en meter a todos los clientes en la misma plantilla. Se trata de ejecutar un proceso estándar que saque a la luz lo que es único en cada cliente. El diagnóstico de cinco funciones lleva menos de dos horas, da a tu equipo un lenguaje común y le da al cliente una lista clara de decisiones. La agencia que puede prometer un diagnóstico coherente puede conseguir un cliente en una semana y entregar en un mes, no porque el trabajo sea más fácil, sino porque el descubrimiento es predecible. Y cuando el cliente pregunta por qué necesitas hacer tantas preguntas, la respuesta es simple: no estás haciendo una audición, estás diagnosticando.

Para una mirada más profunda sobre cómo la muestra de funciones y la página de precios deberían funcionar juntas, y por qué persisten los mitos en torno a ellas, consulta esta guía para desmentir mitos.