Un comprador de software puede ver una demostración impecable y aun así preguntarse cómo será la primera semana. ¿Entenderá el equipo el flujo de trabajo? ¿Qué sucede cuando alguien se queda atascado? ¿El producto se adapta a la forma en que la gente ya trabaja?
Los testimonios de SaaS son más útiles cuando responden a esas preguntas cotidianas. Las declaraciones sobre una plataforma innovadora o una solución potente pueden sonar positivas y, sin embargo, dejar al comprador con la misma incertidumbre.
Describe la primera tarea útil
Pregunta a los clientes qué intentaban lograr cuando empezaron. Un testimonio sobre cómo encontrar un documento compartido, completar un informe o responder a una solicitud de un cliente ofrece a los lectores una tarea que pueden reconocer.
La Historia de un cliente de Slack sobre los equipos de soporte de Intuit ilustra cómo una cuenta puede conectar el uso del software con un entorno de trabajo particular. El valor del ejemplo reside en el contexto operativo, no en la sugerencia de que otra empresa pueda asumir la misma escala o resultado.
Para tus propios clientes, captura las condiciones que rodean la tarea. A un trabajador independiente y a un equipo grande les puede gustar el producto por razones diferentes. Haz que esas diferencias sean visibles para que los lectores puedan evaluar la similitud con su propia situación.
Explica qué requirió la incorporación
"Fácil de empezar" deja mucho sin explicar. Una conversación de seguimiento puede revelar el detalle que otro comprador necesita:
Cliente: "Lo estábamos usando al final de la semana".
Entrevistador: "¿Qué estaba listo antes de que comenzara esa semana y quién ayudó con la primera tarea?"
La respuesta podría mencionar datos preparados, un colega que conocía el producto o soporte de incorporación adicional. Incluye la condición relevante en el relato publicado. Un comprador que empieza sin esa preparación necesita entender lo que el cliente hizo realmente, en lugar de asumir que el mismo cronograma se aplica automáticamente.
Guía de Notion para preparar a un equipo para la incorporación muestra que adoptar un software implica tomar decisiones antes de que las personas comiencen a usarlo. Un testimonio creíble puede reconocer ese trabajo sin volverse negativo.
Mantén una distinción entre las capacidades del producto y los servicios proporcionados bajo un acuerdo particular. Un cliente que recibió capacitación dedicada no debe utilizarse para dar a entender que todos los planes incluyen el mismo soporte.
Describe el soporte mediante una situación, no con un adjetivo
En lugar de preguntar si el soporte fue excelente, pregunte qué necesitaba el cliente y qué sucedió. ¿La respuesta explicó una limitación? ¿El equipo ayudó a identificar la configuración relevante? ¿Fue la solución alternativa adecuada para su tarea?
El relato de Slack sobre el flujo de trabajo de atención al cliente de Xero ofrece un ejemplo de cómo describir el trabajo de soporte a través del proceso que lo rodea. Para un testimonio más breve, conserve un evento comprensible en lugar de comprimir una historia compleja en una afirmación general.
Evite revelar información de la cuenta o problemas privados del cliente en la cita publicada. Confirme que la persona aprueba la redacción final y que cualquier atribución a la empresa está autorizada.
Mantenga actualizados los testimonios de software
Una cita sobre un flujo de trabajo puede volverse inexacta tras un cambio importante en el producto. Revise el plan, la función y el rol asociados con el testimonio antes de reutilizarlo en una página nueva. Conserve la fecha o el contexto cuando afecte a la interpretación.
Para un sitio web SaaS que utiliza Mirror App, las citas aprobadas pueden añadirse manualmente al widget de reseñas y colocarse junto a los casos de uso pertinentes. Un testimonio sobre un flujo de trabajo debe ir cerca de la explicación de dicho flujo. Debe respaldar una evaluación realista del software, sin presentarse como una garantía de retención, ingresos o ahorro de tiempo.
