¿PoC de pago o piloto gratuito? Cómo mantener el DX en serio
Los pilotos no remunerados suelen sonar atractivos porque reducen la fricción al principio. En la práctica, suelen eliminar justo los compromisos que hacen útil un proyecto de DX: un responsable de negocio, datos de muestra, criterios de aceptación y una decisión al final.
Para equipos B2B japoneses que necesitan pruebas antes de una inversión DX mayor, un PoC de pago pequeño suele ser más sano. Crea un proyecto real sin fingir ser una transformación completa.
El patrón no es exclusivo de Japón, pero aquí se ve con especial claridad: las compras corporativas son lentas, así que los proveedores ofrecen pilotos "gratis" para esquivar esa lentitud, y el trabajo resultante se queda sin financiación interna. Sin financiación interna, nadie rinde cuentas, no se asigna un responsable del sistema, no se solicita la autorización de datos y el piloto muere el último día del encargo, cuando no hay camino para renovar.
Qué cambia con el pago
Un PoC de pago no necesita ser grande. Necesita ser lo bastante serio como para que ambas partes protejan el alcance.
Un responsable de negocio asiste a las demos semanales
Los datos de muestra se preparan antes del kickoff
Los criterios de éxito quedan por escrito
Las exclusiones son visibles
La demo final conduce a una decisión
Esa estructura le da a la dirección algo concreto que evaluar. El pago es un mecanismo de compromiso, no un afán recaudatorio. Cuando el cliente tiene asociada aunque sea una partida de presupuesto modesta, el proceso interno cambia: legal revisa el DPA, IT aprovisiona un sandbox, el responsable de negocio bloquea tiempo en el calendario y el cuestionario de seguridad de verdad se responde. Nada de eso ocurre de forma fiable sin un código de presupuesto.
Un encargo de pago típico de nivel de entrada y lo que compra:
DX Readiness Audit (1 semana, ~$5-7k). Mapa de procesos, candidatos a automatización ordenados por viabilidad e impacto, estimación de ROI y una propuesta de sprint con alcance definido. Útil cuando el equipo aún no tiene claro qué construir.
Quick PoC (2 semanas, ~$12-18k). Prototipo funcional sobre un flujo de trabajo, un paso de IA acotado, dashboard de demo y un plan escrito de siguientes pasos con el coste y los plazos de prepararlo para producción. Útil cuando el flujo de trabajo se conoce pero faltan pruebas tangibles.
MVP Sprint (4 semanas, ~$25-35k). Aplicación interna o flujo de trabajo usable, integración real (o simulada), despliegue y monitorización básica. Útil cuando el PoC funcionó y hay un grupo piloto de usuarios listo.
Una referencia interna útil: si el coste del PoC es menor que dos semanas del tiempo del equipo que lo recibe, la conversación debería ir de valor, no de precio.
Qué evitar
La versión arriesgada de un piloto no tiene responsable de presupuesto, ni acceso a muestras reales del flujo de trabajo, ni un siguiente paso claro. Puede generar actividad sin evidencia.
Señales de alerta de que un piloto no remunerado va camino de no producir nada:
No hay un responsable de negocio concreto; solo un coordinador del equipo de innovación.
No hay datos de muestra representativos: "ya os enviaremos algo".
No hay cuestionario de seguridad porque el trabajo es "solo una demo".
Los criterios de aceptación se describen como "vamos a ver cómo va".
El presupuesto de continuación se describe como "según los resultados", sin una vía de aprobación comprometida.
El piloto se presenta internamente como una evaluación de proveedores, pero el siguiente paso está sin definir.
Si el equipo no puede asignar un responsable ni compartir datos representativos, el mejor primer paso es una auditoría de preparación DX. Una auditoría es más barata que un PoC, produce un artefacto escrito y saca a la luz pronto las decisiones que faltan. También es mucho más fácil de financiar que un sprint completo, lo que la convierte en una primera prueba de compras útil para ambas partes.
Una primera pregunta mejor
En lugar de preguntar si la IA puede ayudar en general, pregunta si un flujo de trabajo problemático puede volverse más rápido, más claro y más fácil de gestionar en dos a seis semanas. Esa es una pregunta que un PoC enfocado puede responder.
La forma correcta de pregunta para el primer encargo:
"¿Podemos reducir un 50% el tiempo medio de respuesta de los tickets de soporte de nivel 1 con una cola de respuestas redactadas por IA, manteniendo la aprobación humana?"
"¿Podemos extraer los siete campos obligatorios de las facturas entrantes de proveedores con al menos un 95% de recall y alimentarlos a la API contable existente?"
"¿Puede el equipo encontrar la cláusula correcta en nuestra biblioteca de políticas de 800 páginas en menos de 30 segundos, con citas verificables?"
Cada una de ellas es comprobable, financiable y decidible. Ninguna requiere un programa de transformación para empezar. Eso es lo que hace del PoC de pago el camino más honesto: compromete a ambas partes con una pregunta que de verdad se puede responder.