Un piloto B2B SaaS es una evaluación acotada en la que un cliente potencial prueba un producto existente en un flujo de trabajo concreto para decidir si comprarlo. Primero, acuerda qué necesita aprender el comprador, quién hará el trabajo, cómo lo mediréis y cuándo decidiréis. Esta guía incluye un brief, un registro de intentos y una evaluación de ejemplo que puedes usar sin registrarte.
Elige un piloto solo si puede responder a la pregunta del comprador
Pregunta: ¿Qué necesitarías observar para decidir si este producto encaja en tu trabajo? Una respuesta útil podría ser si dos responsables de cuentas pueden preparar un traspaso de cliente completo sin que el fundador tenga que corregirlo. Eso se puede comprobar. Una petición vaga de explorar la plataforma necesita primero una conversación sobre el alcance.
Un piloto añade trabajo para ambas partes. Si una demostración ya resuelve la duda y el comprador está listo para comprar, otra evaluación puede limitarse a retrasar la decisión. Si el obstáculo es un presupuesto no disponible o un requisito de datos sin aprobar, el acceso al producto por sí solo no lo resolverá.
Distingue el propósito del piloto del descubrimiento y la beta
Las empresas usan piloto, prueba y prueba de concepto de formas distintas. Definid juntos el trabajo en lugar de confiar en la etiqueta. Aquí, un piloto evalúa un producto utilizable en el flujo del comprador y termina con una decisión de compra. Una prueba de concepto técnica puede ser más limitada: comprobar si funciona una integración o un requisito técnico.
Una relación con un socio de diseño ayuda a dar forma a un producto que aún necesita aprendizaje y desarrollo. Una beta permite observar el uso inicial y detectar problemas. Ambas pueden conducir a un piloto comercial, pero los comentarios, la asistencia y el entusiasmo no demuestran una compra. Explicita el propósito de cada relación y la aportación esperada.
Si todavía estás decidiendo para quién es el producto, empieza por las guías de socios de diseño o entrevistas de descubrimiento enlazadas al final. Este plan comienza con un comprador plausible y un flujo que tu producto actual ya puede intentar resolver.
Acuerda las condiciones de inicio antes de empezar a contar el tiempo
- Un flujo: identifica la tarea, quién la realiza y qué queda fuera. Evita evaluar todas las funciones en toda la empresa a la vez.
- Un usuario y un comprador: identifica quién probará la tarea, quién juzgará su utilidad y quién aprueba la compra. Una persona puede ocupar varios roles; compruébalo en lugar de suponerlo.
- Entradas utilizables: confirma las muestras de trabajo, los accesos y los permisos necesarios para un intento real. Registra un requisito bloqueado por separado de un fallo del producto.
- Una referencia inicial: registra cómo se hace hoy el mismo tipo de tarea, incluyendo tiempo, errores y ayuda. Define el método de medición antes de comparar resultados.
- Capacidad de ambas partes: acuerda quién hace la configuración, cuánto soporte se ofrece y qué solicitudes a medida quedan excluidas.
- Un calendario: elige inicio, revisión intermedia y fecha de decisión con suficiente trabajo normal para observar la pregunta. No existe una duración universal de 14, 30 o 90 días.
Copia el brief y complétalo con el comprador
Copia los campos en blanco en tu documento. La columna completada utiliza HandoffKit, un producto ficticio para traspasar cuentas de clientes, y Northstar Studio, una agencia ficticia. Todas las organizaciones, fechas, cifras y conclusiones del ejemplo son inventadas para explicar el método. No es un caso de cliente de Soloop ni una referencia recomendada.
El brief es un plan operativo. Registra las condiciones comerciales y de tratamiento de datos en el acuerdo que corresponda; esta tabla no es una plantilla de contrato. En pantallas pequeñas, desplaza las tablas horizontalmente para leer todas las columnas.
| Dimensión | Tu piloto | Piloto ficticio de HandoffKit |
|---|---|---|
| Decisión | [Pregunta del comprador y decisión pendiente] | ¿Pueden los responsables preparar traspasos utilizables con menos trabajo activo, lo suficiente para considerar la compra? |
| Personas | [Usuarios, evaluador, comprador y responsable del proveedor] | Dos responsables de cuentas lo usan; operaciones evalúa; el propietario aprueba el gasto; el fundador configura. |
| Alcance | [Flujo, muestra y exclusiones] | Cinco traspasos en un equipo; sin integración con CRM ni migración histórica. El comprador comprueba que se parecen al trabajo habitual. |
| Referencia | [Método actual, observaciones y fuente] | Cinco traspasos anteriores: 28, 35, 27, 32 y 28 minutos activos; media de 30. Registro cronometrado del responsable, con la misma regla de inicio y fin que el piloto. |
| Criterios | [Resultado, umbral, evidencia y evaluador] | Al menos cuatro de cinco traspasos sin corrección del fundador; media de tiempo activo de esas finalizaciones independientes de 24 minutos como máximo; ningún campo obligatorio ausente en lo entregado. |
| Calendario | [Condición de inicio, comienzo, revisión y decisión] | Configuración lista el 12 de octubre; uso del 13 al 23; revisión el 19; decisión el 26. Fechas elegidas según el trabajo disponible del equipo. |
| Soporte | [Configuración, límite de soporte y exclusiones] | Una sesión de configuración y hasta dos horas de soporte del fundador. Registrar cada corrección. Las nuevas integraciones requieren otra decisión. |
| Compra posterior | [Tarifa del piloto, alcance/precio posterior y confirmación] | Se exime la tarifa de esta evaluación acotada; el alcance y precio de la implantación de pago se tratan aparte. El propietario aún no ha aprobado el presupuesto. |
| Salida | [Comprar, nueva prueba acotada o terminar; responsables de acceso y materiales] | Revisar juntos la evaluación y las aprobaciones. Si se termina, cerrar el acceso de prueba; operaciones y fundador confirman el tratamiento acordado de los materiales compartidos. |
Decide si el piloto será de pago y qué demostraría ese pago
Elige las condiciones según el trabajo y el proceso del comprador. Un piloto con configuración importante o soporte dedicado necesita una conversación comercial antes de empezar. Una evaluación gratuita y limitada puede ser razonable si ambos podéis dedicar tiempo y tú puedes asumir el coste del aprendizaje. Ninguna modalidad resuelve una pregunta confusa o la ausencia de un evaluador.
Escribe qué incluye, qué aporta el comprador, qué ocurre al finalizar y cómo se considerará una compra posterior. Si ofreces descontar el importe del piloto de una futura compra, indícalo. No adoptes una tarifa o duración para grandes empresas de otra guía como si fuera adecuada para tu producto.
Registra por separado la tarifa del piloto, la decisión de suscripción posterior y el uso recurrente. Pagar por evaluar demuestra esa transacción; no demuestra renovación, retención ni funcionamiento independiente en otras cuentas. Del mismo modo, que un promotor interno quiera continuar no implica que el presupuesto esté aprobado.
Registra los intentos reales, incluida la ayuda del fundador
Usa una fila por intento real. Registra ID, fecha, condiciones iniciales, evidencia de finalización, esfuerzo activo, interrupciones y ayuda. Separa el tiempo de espera del trabajo activo. Identifica la evidencia que inspeccionaste y marca las estimaciones y recuerdos como información declarada.
En el piloto ficticio, los cinco traspasos llegan al destinatario con la información requerida. Uno solo lo consigue después de que el fundador arregle manualmente la exportación. Incluir ese intento más rápido pero asistido en la media ocultaría la dependencia del soporte.
| Dimensión | Tiempo y ayuda registrados | Evidencia de finalización |
|---|---|---|
| P01 | 22 minutos activos; sin corrección del fundador | El destinatario comprueba los campos obligatorios en el traspaso entregado. |
| P02 | 12 minutos activos del usuario; el fundador arregla la exportación aparte | Entrega correcta tras la reparación; el tiempo del fundador consta en las notas de soporte. Finalización asistida. |
| P03 | 30 minutos activos; sin corrección del fundador | Entrega con los campos obligatorios; el usuario vuelve a introducir contexto duplicado. |
| P04 | 24 minutos activos; sin corrección del fundador | Entrega con los campos obligatorios; comprobación del destinatario registrada. |
| P05 | 28 minutos activos; sin corrección del fundador | Entrega con los campos obligatorios; el usuario vuelve a introducir el contexto. |
Interpreta los resultados según los criterios acordados
En los cinco intentos ficticios, el tiempo medio del usuario es 23,2 minutos: (22 + 12 + 30 + 24 + 28) / 5. Parece inferior al objetivo de 24 minutos, pero este se refería expresamente a las finalizaciones independientes. Su media es 26 minutos: (22 + 30 + 24 + 28) / 4. El criterio de tiempo no se ha cumplido.
La media independiente es cuatro minutos menor que la referencia ficticia de 30 minutos: una observación útil para esta muestra. Sin embargo, su tamaño reducido y seleccionado, las diferencias entre tareas y el aprendizaje durante el piloto impiden tratar la diferencia como una estimación causal o como un resultado prometido a otros clientes.
| Dimensión | Criterio acordado o pregunta abierta | Resultado |
|---|---|---|
| Uso independiente | Al menos cuatro de cinco traspasos sin reparación del fundador | Cumplido en esta muestra: P01, P03, P04 y P05; P02 sigue siendo asistido. |
| Trabajo activo | Finalizaciones independientes con media de 24 minutos como máximo | No cumplido: 26 minutos. No sustituir por la media de 23,2 que incluye ayuda. |
| Integridad | Ningún campo obligatorio ausente en las entregas | Cumplido en las comprobaciones de los cinco resultados, incluido el reparado. No demuestra fiabilidad general. |
| Carga de soporte | ¿Podría el fundador atender más cuentas de forma sostenible? | Desconocido con estas filas únicamente. Revisar el registro separado de configuración y reparaciones antes de decidir la implantación. |
| Compra | ¿El comprador autorizado aprueba alcance y precio? | Pendiente: el propietario no ha aprobado presupuesto. No consta compra de suscripción. |
Termina con una compra, una nueva prueba acotada o un cierre
En la reunión final, muestra la evidencia antes de discutir impresiones. Pregunta al evaluador si los registros describen su experiencia y después al comprador qué decisión puede tomar. El encaje del producto y la preparación para comprar pueden diferir; mantén ambos visibles.
En el caso ficticio, el fundador propone eliminar la entrada duplicada y repetir traspasos comparables. Es solo una propuesta. El comprador no ha aceptado más trabajo ni aprobado gasto, así que el resultado correcto es: primera evaluación terminada; criterio de tiempo incumplido; nueva evaluación y compra sin decidir. Finaliza el acceso inicial según lo acordado, salvo que ambas partes lo modifiquen expresamente.
- Avanza hacia la compra cuando el comprador elija el alcance y las condiciones ofrecidos. Registra el siguiente paso real y su responsable; marca el pago solo cuando se confirme.
- Haz otra prueba únicamente si importa una incertidumbre concreta, ambas partes acuerdan qué cambiará y existe una nueva fecha de cierre. La falta de presupuesto no justifica soporte gratuito ilimitado.
- Termina si el flujo no encaja, siguen faltando requisitos, la carga de soporte supera lo que puedes ofrecer o el comprador rechaza la propuesta. Registra el aprendizaje sin llamar a esa cuenta un cliente convertido.
Lleva una pregunta de investigación pendiente a Soloop
Usa el brief y la evaluación por tu cuenta y después identifica una pregunta que las fuentes públicas sí puedan responder. Por ejemplo: ¿Qué alternativas usa este tipo de agencia para traspasar clientes y qué configuración necesitan? Investigar puede ayudar a definir el alcance y las preguntas posteriores; el cliente todavía debe mostrar su propio flujo.
Brief para copiar: Mi producto es [URL o demo] para [rol y flujo]. Un comprador potencial necesita evaluar [tarea concreta]. Investiga [una pregunta] usando [URL de fuentes públicas o alcance]. Compara las alternativas pertinentes, adjunta enlaces y fechas de consulta, y separa las afirmaciones comerciales de las observaciones y lo desconocido. Termina con las preguntas que debo verificar con el comprador antes de acordar un piloto.
El manual de Soloop describe investigación de mercado y competidores con informes y los enlaces recopilados en Tasks. Abre el resultado y comprueba las fuentes que afectan a decisiones importantes. Comparte solo material autorizado. Tú y el comprador gestionáis el piloto, recogéis evidencia de uso y tomáis la decisión comercial; esta guía no acredita un servicio automático de gestión de pilotos.
El enlace a Soloop abre la entrada pública y no transfiere este brief ni tus notas de clientes. Un documento completo ya es un resultado útil aunque nunca abras un espacio de trabajo de Soloop.
Fuentes y límites
Fuentes consultadas el 7 de octubre de 2026. El brief, el registro, los umbrales, los cálculos y la evaluación ficticia son ejemplos editoriales originales de Soloop. No se han probado en un estudio con clientes. Revisa el manual al elegir una tarea y adapta el piloto al trabajo real del comprador, sin adoptar las fechas o metas del ejemplo.
Andrew Verboncouer, de Headway, describe cómo planificar un piloto B2B, recoger una referencia inicial y mantener revisiones de feedback. Su artículo relata experiencia práctica; no valida los resultados ficticios de esta guía.
Headway: cómo organizar un piloto de softwareLa entrevista de First Round explica cómo elegir un piloto en torno a la preocupación real del comprador, con proceso y requisitos definidos. Puede añadir fricción cuando el cliente ya podría decidir la compra.
First Round: preguntas habituales sobre salida al mercadoSoloop documenta investigación con fuentes públicas y resultados de tareas. Los accesos del comprador, las mediciones de uso y las decisiones comerciales siguen correspondiendo al fundador y al cliente.
Manual del producto Soloop