Cómo deben definir el alcance del primer acuerdo los proveedores de IA de voz y los partners de servicios

Un primer acuerdo de IA de voz liderado por un partner suele torcerse en un punto predecible: el cliente, el partner de servicios y el proveedor de la plataforma dan por hecho que una parte del trabajo corresponde a alguno de los otros. La solución es un alcance por escrito con un único responsable del descubrimiento, un solo tipo de llamada, un responsable designado para cada línea de trabajo, servicios del proveedor solo donde el acuerdo realmente los necesite y los servicios presupuestados por separado del uso.

Este es el proceso de definición del alcance que entregaríamos a un partner antes de que envíe su primer presupuesto. Si eres el cliente, también es la lista de cosas que debes pedir a tu partner que deje por escrito.

Resumen

• El partner se encarga del descubrimiento, porque es quien gestiona la relación con el cliente y opera el agente tras el lanzamiento.
• Limita el primer despliegue a un tipo de llamada, un punto de entrada, un sistema de registro y una ruta de transferencia.
• Recurre al soporte de implementación del proveedor cuando el riesgo está en la capa de la plataforma: telefonía del centro de contacto, condiciones contractuales enterprise o capacidad por encima de los límites estándar.
• Plasma el reparto en una tabla con un único responsable por fila, incluidas las filas que corresponden al propio cliente.
• Presupuesta la parte de servicios por separado del uso de la plataforma y confirma el coste de cualquier servicio del proveedor antes de presupuestar.
• Las comisiones, los tamaños mínimos de acuerdo y el precio de los servicios del proveedor son cuestiones que hay que pactar con el proveedor, no suposiciones que incluir en un presupuesto.

¿Quién debe encargarse del descubrimiento en un acuerdo liderado por un partner?

El partner. Es quien mantiene la relación con el cliente, redacta la declaración de trabajo y será quien arregle el agente en el tercer mes, así que el descubrimiento tiene que generar respuestas sobre las que el partner pueda entregar.

El proveedor se suma al descubrimiento para un conjunto limitado de preguntas: si los requisitos de telefonía, cumplimiento normativo y volumen del cliente encajan en un plan estándar o requieren un contrato enterprise. Resuélvelas antes de redactar el alcance, no después de que el cliente haya firmado.

El descubrimiento debe devolver estas respuestas por escrito:

• Tipos de llamada y volumen mensual de cada uno, a partir de los propios informes del cliente y no de una estimación.
• Punto de entrada: un número nuevo, un número existente o una transferencia desde un IVR o una plataforma de centro de contacto ya existente.
• Sistemas de registro en los que el agente debe leer o escribir.
• Adónde van las llamadas cuando el agente no puede ayudar, y en qué horario.
• Requisitos de cumplimiento normativo, como un BAA para datos de salud, condiciones contractuales personalizadas, límites de retención de datos o SSO.
• Quién, por parte del cliente, aprueba el guion del agente y da el visto bueno a la puesta en producción.
• Quién modifica el agente tras el lanzamiento y con qué frecuencia espera el cliente cambios.
• La métrica que determina si el primer despliegue ha funcionado.

Si las respuestas sobre cumplimiento o capacidad apuntan a condiciones personalizadas, la conversación con el proveedor se adelanta. En Retell, un MSA, DPA o BAA personalizado, el SSO y el control de acceso basado en roles figuran en el plan Enterprise, no en el de pago por uso, según la página de precios. Un acuerdo que necesite cualquiera de ellos es una conversación Enterprise desde el principio.

¿Qué debe incluir el primer despliegue?

Un tipo de llamada, resuelto lo bastante bien como para ampliarlo. Cómo elegir el tipo de llamada y probarlo con llamadas reales se explica en cómo evaluar una plataforma de agentes de voz antes de la puesta en producción. La tarea de definición del alcance aquí consiste en trazar la línea entre la fase uno y la fase dos.

Dos comprobaciones de alcance cambian el tamaño del desarrollo.

¿El sistema de registro es una integración nativa? La página de integraciones de Retell incluye HubSpot, Salesforce, Microsoft Dynamics 365, GoHighLevel y Zoho CRM como CRM; Zendesk para tickets de soporte; Calendly, Cal.com y GoHighLevel para la programación; y Google Drive, Microsoft OneDrive y Notion como fuentes de la base de conocimiento. Cualquier otra cosa es una función personalizada que llama a la API del propio cliente, lo que supone trabajo de desarrollo y debe presupuestarse como tal.

¿El cliente mantiene su telefonía actual? Retell se conecta a los operadores existentes mediante elastic SIP trunking o marcando una URI SIP, y su documentación incluye guías de configuración para Five9, Genesys Cloud, Amazon Connect y Avaya. Una integración con un centro de contacto implica al equipo de telefonía del cliente, así que incluye el nombre de esa persona en el alcance.

Incorpora una vía de pruebas desde el principio. Retell admite pruebas de simulación con casos de prueba evaluados y versiones del agente con etiquetas de entorno prod y staging, de modo que un cambio puede probarse en una nueva versión antes de trasladar a ella la etiqueta prod, que es la que sigue el número de producción.

¿Cuándo merece la pena recurrir a los servicios profesionales del proveedor?

Recurre al proveedor cuando el riesgo del acuerdo está en la capa de la plataforma y no en el negocio del cliente. Los partners conocen el proceso del cliente; el proveedor sabe cómo se comporta su plataforma en los casos límite.

La página de precios de Retell incluye el Soporte de implementación dedicado como complemento del plan Enterprise, junto con un account manager asignado y soporte 24/7 con un portal dedicado. Retell no publica un precio ni un tamaño mínimo de acuerdo para ese complemento, así que trata ambos aspectos como preguntas para el proveedor.

Señales de que la participación del proveedor compensa su coste:

• El agente está detrás de una plataforma de centro de contacto mediante SIP y las transferencias tienen que devolver las llamadas a colas atendidas por personas.
• El cliente necesita un MSA, DPA o BAA personalizado, o SSO.
• El cliente necesita precios por volumen, un servidor estable dedicado o una concurrencia muy superior a las 20 llamadas simultáneas que incluye por defecto un espacio de trabajo de pago por uso.
• Es el primer despliegue de este tipo para el partner y un error le costaría la relación con el cliente.

Señales de que el partner puede encargarse solo: una única ubicación, una integración nativa, un número nuevo o desviado y un volumen estándar. El plan de pago por uso de Retell incluye acceso completo a la plataforma sin compromiso de permanencia, lo que se adapta a ese tipo de acuerdo.

¿Cómo debe repartirse el trabajo entre partner y proveedor?

Plásmalo en una tabla con un responsable por fila. Las filas compartidas son donde se atascan los primeros acuerdos.

La configuración del espacio de trabajo determina gran parte de lo que viene después. Retell aísla los agentes, números, claves de API, miembros, webhooks y facturación por espacio de trabajo, y los roles se asignan por espacio de trabajo. Los detalles operativos, incluidos la atribución de la facturación y los niveles de soporte, están en cómo gestionar la IA de voz para clientes.

¿Cómo debe fijar un partner el precio de la parte de servicios?

Por separado del uso de la plataforma. El cliente debe ver tres conceptos: el uso de la plataforma, un desarrollo único y una cuota de gestión recurrente con un margen de cambios definido.

El uso en Retell es público: de 0,07 $ a 0,31 $ por minuto para agentes de voz en el plan de pago por uso, y precios personalizados en Enterprise. Repercutir el uso a precio de coste o con un margen es una decisión comercial. Los cuatro modelos que se sostienen en la renovación se comparan en cómo fijan las agencias el precio de los agentes de voz con IA.

Dos reglas para el primer acuerdo:

• Confirma el coste de cualquier servicio del proveedor antes de presupuestar. Si el acuerdo incluye soporte de implementación, averigua si se te factura a ti o al cliente, y si es fijo o se define por proyecto.
• Presupuesta la fase dos como una partida aparte. Los clientes suelen interpretar un primer presupuesto bajo como el precio total del programa.

¿Qué deben acordar partner y proveedor antes del primer presupuesto?

Las páginas para partners de Retell indican lo que obtienen los partners certificados: referencias de clientes potenciales, presencia en el Solution Partner Directory, co-marketing en los niveles superiores, acceso anticipado a nuevas funciones (sobre todo en los niveles superiores) y soporte dedicado para partners. No publican porcentajes de comisión, tamaños mínimos de acuerdo ni precios de servicios profesionales. Acuerda estos puntos por escrito con tu contacto de partners:

• Cómo se registran los acuerdos generados por el partner y los leads referidos por el proveedor, y qué ocurre cuando ambos intervienen con el mismo cliente.
• Las condiciones de comisión, margen o reparto de beneficios, y si el nivel de partner las modifica.
• Si existe un tamaño mínimo de acuerdo para las condiciones Enterprise o el soporte de implementación.
• Cómo se presupuesta el soporte de implementación y qué incluye.
• Quién ostenta el contrato de la plataforma: el partner o directamente el cliente.
• La ruta de escalado ante un problema de la plataforma durante la puesta en producción de un cliente.

Empieza por el programa de partners

Los partners que desarrollan sobre Retell pueden presentar su solicitud a través del Solution Partner Program; se evalúa a los solicitantes según sus competencias técnicas, su experiencia en el sector y su potencial para aportar valor al programa. Los clientes que quieran que un partner se encargue del primer despliegue pueden filtrar el Solution Partner Directory por región, idioma e integración. En cualquier caso, acuerda el alcance anterior antes del primer presupuesto y pon en marcha un tipo de llamada con llamadas reales antes de ampliar.

Lecturas relacionadas: Por qué las pruebas de carga deben seguir la ruta real de la llamada, el flujo de trabajo del CRM a la IA de voz y más guías en el centro Retell Learn.