La oferta del implementador, en su totalidad: configura empresas en afka y recibe pagos durante doce meses

Hay una brecha en el mercado que tiene una forma que todos reconocen y un nombre que casi nadie usa. Las empresas quieren agentes de IA que funcionen: la cola de soporte crece, el pipeline está estancado, el fundador responde tickets por la noche. Y esas mismas empresas no tienen a la persona que se sentará, conectará las herramientas, establecerá los límites y acompañará el primer trabajo hasta el final. El software existe. Las manos, no.

Esa brecha es un trabajo. Llamamos deployer a la persona que lo hace: una persona o agencia que configura empresas en afka dentro de su propio workspace y cobra por cada mes que el cliente permanece. Este artículo es la oferta completa, por escrito. No es un adelanto para una llamada, ni un portal de socios detrás de un formulario. Los términos, el método y el razonamiento, en público.

Qué hace realmente un deployer

Un deployment no es un proyecto de integración. Son una o dos sesiones de trabajo con un ritmo que los playbooks describen paso a paso.

La primera hora son preguntas. Qué diez tipos de tickets llenan la bandeja de entrada. Qué deals se quedaron en silencio. Cuáles son realmente los criterios imprescindibles para el puesto abierto. El cliente tiene estas respuestas; nadie las ha escrito nunca. El deployer las escribe, porque la lista decide qué gestiona primero el agente y qué se queda con una persona.

Luego se conectan las herramientas mediante conectores gestionados. afka nunca recibe contraseñas de terceros: el cliente autoriza cada herramienta y puede revocarla desconectándola. Este es el paso que la gente espera que sea difícil, y es el más sencillo de la lista.

Luego viene la conversación que separa un deployment de una instalación: autonomía y límites, acordados en voz alta. El agente empieza en Revisión, los reembolsos esperan aprobación, los límites son números que el cliente dice con su propia boca, y el deployer muestra que esos límites se aplican en código y no en un prompt. Un límite que se puede esquivar con palabras no es un límite.

Luego llega el momento en que el cliente entiende el producto: un trabajo real, de principio a fin, mientras observa. Un ticket real resuelto. Un pipeline visiblemente más limpio. Una lista clasificada donde cada puntuación lleva su cita. No una demo con datos de muestra: su cola, su deal, su rol.

El artefacto de entrega es el propio registro de auditoría.

La entrega es el último paso, y se hace con el registro de auditoría abierto: quién hizo qué, cuándo, a qué coste y qué decisiones esperaron a una persona. El cliente se va siendo dueño del dial de autonomía. El deployer se va con un cliente que vio el trabajo ocurrir en lugar de escucharlo descrito.

Los términos, expuestos una vez

Ganas el 30 por ciento de la suscripción del cliente durante doce meses desde la primera factura pagada, con atribución de primer contacto durante 90 días. Tu tarifa de implementación es tu propio negocio y se queda contigo. afka no publica proyecciones de ingresos: los términos son los términos.

Ese párrafo aparece palabra por palabra en cada página de playbook, y es deliberadamente breve. No hay una escalera de niveles que escalar, ni cuota que defender, ni tarifa de certificación. Tanto si un deployment te lleva una tarde como una semana, lo que cobras por tu propio tiempo es un asunto entre tú y tu cliente.

Los cinco playbooks, publicados

El método no está restringido, porque el método es la oferta. Un playbook por función de negocio, cada uno con el perfil del cliente, el mapa del equipo, la entrevista de skill-pack, los cinco pasos de la primera sesión, el ritmo semanal, la sección de dinero y las preguntas que los clientes hacen realmente:

Despliega el agente de soporte: de una bandeja de entrada saturada a tickets resueltos. Despliega el agente de ventas: trabajo de pipeline que funciona sin que una persona lo conduzca. Despliega el agente de recruiting: una lista clasificada y filtrada en lugar de una avalancha de candidatos. Despliega el agente de tienda: compradores atendidos y el back office gestionado. Despliega el agente de contenido: LinkedIn gestionado como infraestructura GTM.

Por qué el método es público

Un documento restringido puede prometer cualquier cosa. Una página pública tiene que ser verdad, porque cualquiera puede confrontarla con el producto que describe. Publicar los playbooks nos cuesta el misticismo de un programa de socios y nos compra algo mejor: un deployer que ha leído exactamente en qué consiste el trabajo antes de comprometerse, y un cliente que ha leído exactamente qué está comprando. Ambos llegan con las expectativas correctas, que es la única base sobre la que puede sostenerse una relación de doce meses.

Hay una segunda razón, y no es ningún secreto. Un futuro deployer busca cómo configurar un agente de soporte de IA para un cliente, y el playbook es la respuesta que encuentra. Captar deployers es una tarea de contenido, y la propia oferta es el contenido.

A quién le encaja, y a quién no

Le encaja a agencias que ya tienen la confianza del cliente: agencias de marketing cuyos clientes no paran de preguntar sobre IA, consultores de operaciones, empresas de servicios IT cuyo trabajo de retainer está menguando. Le encaja a operadores que configuraron un agente dentro de su propia empresa y se dieron cuenta de que ahora tienen una habilidad que sus colegas no dejan de pedirles prestada. El hilo común no es un perfil técnico. Es pararse frente a un cliente, hacer las preguntas de la primera hora y ser de confianza para recibir las respuestas.

No le encaja a nadie que busque ingresos pasivos. El 30 por ciento es recurrente; el trabajo que lo genera no es pasivo. Un deployment es trabajo real con un cliente mirando, y los playbooks no pretenden lo contrario en ningún momento.

La página de deployers contiene el acuerdo y tu enlace. Los playbooks contienen el método. Entre los dos, esa es la oferta completa.