Aprende a planificar, redactar y publicar una página de transparencia para startups: qué compartir, qué evitar, estructura de la página, actualizaciones y plantillas prácticas.
Una página de transparencia es un lugar público y único en tu web donde explicas cómo funciona la empresa: qué estáis construyendo, cómo fijáis los precios, cómo tratáis los datos de clientes y qué pueden esperar las personas cuando algo falla.
No es una página de marketing llena de promesas vagas, ni tampoco un documento para contar absolutamente todo. El objetivo es claridad práctica: dar a clientes, candidatos y socios el contexto suficiente para confiar en vuestras decisiones y usar el producto con menos sorpresas.
Una buena página de transparencia es:
Una página de transparencia no es:
/terms) o de la política de privacidad (/privacy)Las startups usan la transparencia para:
Ayuda cuando podéis comprometeros con promesas sencillas y actualizaciones consistentes.
Puede perjudicar si publicáis:
Comparte solo lo que podáis respaldar con responsabilidad clara y un hábito de actualización. Si no podéis mantener una hoja de ruta pública al día, publica principios de priorización en su lugar.
En cuanto a extensión y estructura, apunta a una página (o conjunto pequeño de páginas) de alrededor de 3.000 palabras: suficiente para ser útil, lo bastante corta para mantenerse legible. Divídela en secciones claras con un índice y anclas para que la gente vaya directo a lo que necesita.
Una página de transparencia no puede responder bien a todas las preguntas a la vez. Si lo intentas, se convierte en una pared de texto —o peor, en un conjunto de afirmaciones vagas que no generan confianza.
Elige el grupo al que más necesites tranquilizar ahora y escribe para ellos primero:
Puedes incluir secciones para otras audiencias, pero la primaria debe marcar el tono, el nivel de detalle y lo que enfatizas.
La página debería responder claramente un pequeño conjunto de preguntas que tu audiencia ya se hace, por ejemplo:
¿Puedo predecir cuánto me costará? (ver /pricing)¿Cómo gestionáis las caídas y el soporte?¿Qué datos recogéis sobre mí y por qué?¿Cómo tomáis decisiones de producto — y escucháis a los usuarios?Sé explícito sobre los límites. Zonas comunes para no compartir incluyen secretos comerciales, datos personales de empleados/clientes y detalles de seguridad operacional (p. ej., configuraciones internas exactas).
Termina este paso con una línea que puedas mantener:
«Esto es lo que compartimos, por qué lo compartimos y con qué frecuencia lo actualizamos.»
Una página de transparencia solo funciona si la gente puede encontrarla rápido y repasarla con confianza. Trátala como documentación de producto: fácil de localizar, fácil de escanear y predecible en cada visita.
Usa una ruta corta y obvia como /transparency. Pon el enlace en el footer (junto a Privacy, Terms, Security) y considera un segundo punto de entrada en el menú About si lo tienes. La consistencia importa: una vez publicada la URL, mantenla estable.
Si ya tienes páginas relacionadas, conéctalas con enlaces relativos claros (p. ej., /pricing, /security, /privacy) para que los lectores verifiquen detalles sin buscarlos.
Un orden práctico que funciona para la mayoría:
Qué cubre esta página (párrafo de intro)
Historia + principios operativos (por qué existís, cómo decidís)
Equipo + cómo trabajáis (quién hace qué, cómo construís)
Precios + expectativas de facturación (cómo se cobran los cargos, casos límite)
Métricas (con cuidado) (qué medís y por qué)
Hoja de ruta + changelog (qué viene, qué ha cambiado)
Privacidad + seguridad (en lenguaje llano) (tratamiento de datos, controles clave)
Soporte + expectativas de fiabilidad (horarios, SLA si los hay, enlace a status)
Puedes reordenar según tu negocio (p. ej., pon seguridad más arriba si vendes a equipos regulados).
Si la página supera unas pocas pantallas, incluye un índice cerca de la parte superior con enlaces a cada sección. Mantén las etiquetas simples («Precios», «Hoja de ruta», «Seguridad») para que el escaneo sea fácil.
Añade una línea de «Última actualización» en la parte superior y declara una cadencia como «Revisado mensualmente» o «Actualizado dentro de los 7 días tras cambios importantes». Asigna un propietario interno (rol o equipo) para que las actualizaciones no se paren.
Cierra la página con una acción: «¿Preguntas? Escríbenos a [email protected]» o enlaza a un formulario ligero (p. ej., /contact). Los lectores no deberían preguntarse dónde pedir aclaraciones.
Una página de transparencia funciona mejor cuando explica no solo lo que creéis, sino cómo operáis realmente.
La misión es vuestro porqué en una o dos frases: a quién servís y qué intentáis cambiar.
Los valores son creencias que queréis mantener (p. ej., «respeto», «velocidad», «calidad»). Los comportamientos son acciones observables que prueban esos valores (p. ej., «respondemos a cada solicitud de soporte en 1 día laborable»). La gente confía más en comportamientos que en eslóganes.
Comparte el momento simple que llevó a la creación: el problema que encontrasteis, por qué las opciones existentes no funcionaban y la primera versión que lanzasteis. Manténlo concreto y centrado en el cliente.
Si queréis la versión larga, enlázala: ver /about.
Usa estos prompts para escribir unos pocos principios en lenguaje claro:
Añade 3–5 compromisos como:
Enlaza detalles de soporte donde haga falta (p. ej., /careers para cómo contratáis y trabajáis).
La gente confía en personas. Una página de transparencia no debe parecer un documento sin rostro; debe mostrar quién es responsable del producto y cómo se toman decisiones.
Empieza con una visión general del liderazgo y roles clave: fundadores, líder de producto, líder de ingeniería, responsable de soporte, responsable de seguridad/privacidad y asesores, solo si han aceptado figurar.
Céntrate en roles:
Evita datos personales como direcciones, teléfonos o cualquier cosa que invite a contacto no deseado. La meta es rendición de cuentas, no exposición.
Incluye una sección corta de «principios de trabajo» que explique cómo colaboráis día a día:
Esto ayuda a los clientes a entender por qué unas peticiones avanzan rápido y otras requieren revisión.
Si estáis contratando, compartid lo básico del proceso: etapas típicas, plazos aproximados y qué se evalúa (portafolio, resolución de problemas, comunicación). Enlaza a /careers para ofertas abiertas y detalles.
Si ya tenéis información en otro sitio, enlazadla en vez de duplicarla (p. ej., vuestra historia y misión en /about).
Los precios pueden generar confianza o frustración rápidamente. El objetivo aquí no es duplicar la tabla de precios, sino fijar expectativas en lenguaje llano para que la gente pueda auto‑evaluarse y evitar sorpresas.
Usa nombres simples y describe para quién va cada plan. Enfócate en lo que incluye a alto nivel (no en cada característica).
Por ejemplo:
Si el precio depende del uso, dilo claramente (p. ej., «precio por usuarios», «precio por uso» o «precio por ambos»).
Resume lo básico en un solo lugar:
Si varía por plan o región, indícalo desde el inicio.
Si tenéis complementos comunes (asientos extra, espacios de trabajo adicionales, límites superiores de uso), describid cómo funcionan las mejoras (inmediatas vs. en el siguiente ciclo de facturación) y si las degradaciones se aplican de inmediato o después.
A la gente no le molestan tanto los cambios de precio como las sorpresas. Compartid principios (p. ej., «conservamos el precio para clientes existentes durante X meses» o «avisamos por email y en la app al menos Y días antes»). Solo comprometéos a plazos que podáis cumplir.
Para el desglose completo, mantened los detalles en la página de precios: /pricing.
Las métricas pueden generar confianza rápidamente, pero solo si son entendibles, comparables en el tiempo y no dañinas para la empresa o clientes. El objetivo no es «mostrarlo todo», sino ofrecer algunas señales que ayuden a juzgar fiabilidad, impulso y encaje.
Evita números que revelen estrategia sensible (ingresos exactos, caja disponible, lista de clientes) o que se puedan interpretar mal (totales vanidosos sin contexto). Si una métrica puede provocar especulación, churn o copia por parte de competidores, probablemente no debe ser pública.
Cuando no sean apropiados valores exactos, publica:
Un conjunto pequeño de métricas operativas suele funcionar bien:
Para cada métrica, incluye una frase sobre por qué importa y otra sobre cómo se mide (ventana temporal, fuente de datos y definición). «Tiempo de respuesta» debe especificar si es primera respuesta o tiempo hasta resolución.
Añade una nota corta como: «Las métricas pueden revisarse a medida que mejora la instrumentación.» Si cambiáis definiciones (p. ej., nueva herramienta de analítica), marca la fecha y explica qué cambió para que los lectores no piensen que intentáis ocultar una caída.
Una hoja de ruta y un changelog convierten «estamos construyendo» en algo que los clientes pueden seguir. También reducen preguntas repetidas del soporte y establecen expectativas sanas sobre lo que es probable que ocurra.
Mantenla ligera. Tres opciones comunes:
Si mantenéis páginas separadas, enlazadlas desde la página de transparencia (p. ej., /roadmap).
Los items deben presentarse como intenciones, no promesas. Añade una nota corta en la parte superior explicando:
Este párrafo previene decepciones y mantiene la confianza cuando cambian prioridades.
Un changelog no necesita cada ajuste menor. Centraos en:
Mantén las entradas breves y con enlaces a documentación profunda. Si vive en otro lugar, enlaza a /changelog.
Di exactamente cómo compartir feedback—email, formulario in‑app o foro. Si permitís votación, explicad cómo influye (señal, no garantía) y con qué frecuencia revisáis las solicitudes.
La página de transparencia debe responder las preguntas que la gente se hace antes de registrarse: «¿Qué datos recogéis?», «¿Quién puede verlos?» y «¿Cuánto tiempo los guardáis?» Si los usuarios no encuentran respuestas claras rápido, asumirán lo peor.
Abre con una sección «a simple vista» y luego apunta a las políticas formales para el texto legal completo. Por ejemplo:
Luego enlaza directamente a /privacy y /terms para las versiones completas.
Sé específico sobre:
Evita promesas vagas como «nos tomamos la seguridad en serio»—describe las medidas prácticas.
Explica protecciones en alto nivel (cifrado en tránsito, acceso por privilegio mínimo, actualizaciones regulares), pero no publiques detalles que ayuden a un atacante (reglas de firewall exactas, diagramas internos, URLs de administración).
Incluye una ruta de reporte como [email protected] y qué puede esperar el informante (tiempo de acuse de recibo, cómo gestionáis divulgaciones). Si tenéis política de divulgación de vulnerabilidades, enlázala (p. ej., /security).
La transparencia no es solo compartir números: es hacer predecible la experiencia diaria del cliente. Una buena página dice cómo obtener ayuda, con qué rapidez respondes y qué significa «fiable» para tu producto.
Enumera los canales reales que monitorizáis: email, chat in‑app, centro de ayuda, foro comunitario o teléfono (si ofrecéis). Incluye solo lo que atendéis activamente. Si hay soporte por cuenta para planes de pago, dilo claramente.
Añade plazos de respuesta típicos que podáis cumplir. Por ejemplo: «Respondemos en 1 día laborable» es mejor que «en 1 hora» si eso no es fiable.
Si tenéis un camino de escalado, descríbelo simplemente: qué cuenta como urgente, cómo deben marcarlo los clientes y cuándo es apropiado. Evitad prometer gestor de incidentes dedicado salvo que realmente lo ofrezcáis.
Explica dónde verán las actualizaciones del servicio y qué esperar durante un incidente: frecuencia de actualizaciones, qué información compartís (impacto, sistemas afectados, soluciones alternativas) y cuándo publicaréis un resumen post‑incidente.
Si publicáis historial de uptime e incidentes, enlazadlo: ver /status.
Si vuestra política de reembolso o gestión de quejas está definida públicamente, resúmela en unas líneas y enlaza la política completa. Incluye los puntos clave: elegibilidad, plazos y cómo solicitar revisión.
Una página de transparencia solo genera confianza si se mantiene precisa. La forma más sencilla de mantenerla creíble es tratarla como un documento vivo con propiedad clara y una rutina de actualizaciones.
Una página de transparencia es una página pública (a menudo en /transparency) que explica cómo opera tu empresa en términos prácticos: expectativas de precios, soporte/confiabilidad, enfoque de la hoja de ruta y cómo gestionas los datos.
Su objetivo es reducir sorpresas y acelerar la confianza, no sustituir a /terms o /privacy.
Publícala cuando puedas comprometerte con un puñado de promesas claras y tengas a alguien que pueda mantener la página actualizada.
Si no puedes mantener una hoja de ruta pública o métricas al día, publica tus principios de decisión y la cadencia de actualización, y añade los detalles más adelante.
Elige una audiencia primaria y escribe para ella primero:
Puedes incluir secciones secundarias, pero la audiencia primaria debe moldear la estructura y el nivel de detalle.
Resume un pequeño conjunto de "preguntas de confianza" y respóndelas de forma directa (normalmente 3–5):
Evita cualquier cosa que cree riesgo o rompa la confianza:
Si no podéis compartir detalles, explicadlo y definid el límite en una frase.
Usa una URL corta y estable (comúnmente /transparency) y enlázala donde la gente la busque:
/privacy, /terms y /securityAñade un índice con enlaces internos si la página ocupa más de unas pocas pantallas.
Resume las expectativas de facturación en lenguaje claro y luego apunta a la página de precios completa.
Suele ser útil aclarar:
Enlaza a /pricing para números exactos.
Publica solo métricas que sean fáciles de interpretar y seguras para compartir.
Opciones útiles:
/status)Añade una breve frase de contexto por métrica: por qué importa y cómo se mide.
Usa un formato que podáis mantener, por ejemplo:
Añade una nota breve que diga que los elementos de la hoja de ruta son intenciones, no garantías, y que las prioridades pueden cambiar según el aprendizaje, la confiabilidad o las restricciones. Enlaza a /roadmap y /changelog si existen.
Haz visible la «frescura» y asigna propiedad.
Configuración simple:
Si algo no puede actualizarse inmediatamente (razones legales/seguridad), publica un marcador breve y actualiza tras la revisión.
¿Puedo predecir cuánto me costará? (enlace a /pricing)¿Qué pasa durante las interrupciones y cómo obtengo ayuda? (enlace a /status si lo tenéis)¿Qué datos recogéis y por qué? (enlace a /privacy)¿Cómo decidís qué construir a continuación? (enlace a /roadmap o explica principios)Si una pregunta aparece con frecuencia en ventas/soporte, debería estar aquí.