Plantilla de RFP para soporte con IA: preguntas a proveedores, tabla de puntuación y prueba con tickets

¿Por qué la mayoría de las RFP de soporte con IA eligen al proveedor equivocado?

Porque puntúan lo que dice el proveedor en lugar de lo que hace la IA con tus tickets. Una RFP típica hace 80 preguntas, recibe 80 respuestas seguras de sí mismas y luego elige a quien dio la mejor demo. La demo usó los escenarios elegidos por el proveedor, sobre una base de conocimiento limpia, con un sales engineer al volante.

Yo construyo integraciones en eesel, así que veo el otro lado: las preguntas del comprador después de firmar el contrato. Casi nunca son sobre funciones. Son "¿por qué respondió así a ese ticket?", "¿por qué subió mi factura en noviembre?" y "¿por qué dice que sí a productos que no ofrecemos?". Cada una de ellas podría haber sido una pregunta de la RFP.

La solución es un orden de trabajo distinto, no más preguntas:

1. Primero los criterios. Todo lo que puede romper el acuerdo (certificación de seguridad, uso de datos, tu helpdesk, HIPAA) es un sí/no que se comprueba antes de que nadie puntúe nada.
2. Después las respuestas por escrito. El banco de preguntas de abajo, respondido por escrito y con pruebas.
3. Luego tus tickets. Los dos o tres que quedan ejecutan el mismo conjunto de prueba de tu historial.
4. El precio al final, a tu volumen. Cada proveedor rellena la misma fila de coste.

En las llamadas de ventas de eesel, lo que más se pide es entrenar la IA con los tickets pasados del propio comprador. Mi compañero Amogh lo dijo sin rodeos tras una serie de demos: "past ticket training strikes again". Los compradores ya saben que su propio historial es la prueba real. La mayoría de las plantillas de RFP simplemente no lo piden.

¿Qué incluye una plantilla de RFP para soporte con IA?

Diez secciones. Cada una corresponde a una decisión que tendrás que defender más tarde, ante tu director financiero, tu equipo de seguridad o tus agentes.

La sección 1 es la que los equipos se saltan, y es la que hace comparables las respuestas de los proveedores. Dales tus números reales: tickets al mes por canal, los 10 principales motivos de contacto, idiomas, helpdesk y qué tipos de ticket no quieres que la IA toque nunca. Una responsable de soporte lo dijo claro en una llamada con eesel: "There are certain tickets I don't want to go through AI." Pon esa lista en la RFP, no en una llamada posterior.

¿Qué preguntas debes hacer a los proveedores de soporte con IA?

Copia estas preguntas en tu RFP como preguntas por escrito. Para cada una he añadido cómo es una respuesta sólida, porque las respuestas débiles suenan todas parecidas y la diferencia está en el detalle.

Calidad de resolución y precisión

Esta sección recibe el mayor peso, y es donde los proveedores tienen más práctica. Ve más allá de la cifra de titular.

1. ¿Qué cuenta vuestra tasa de resolución? Respuesta sólida: una definición exacta, quién o qué decide que un ticket se resolvió, y si se incluyen el spam, los tickets cerrados automáticamente y los clientes que simplemente se fueron.
2. ¿Cuál es vuestra tasa de resolución en tickets como los nuestros? Respuesta sólida: resultados divididos por motivo de contacto y canal, con el tamaño de la muestra y el rango de fechas. Una única cifra combinada de todos los clientes no te dice nada.
3. ¿Qué hace cuando la base de conocimiento no tiene respuesta? Respuesta sólida: dice que no lo sabe y lo traspasa. Pídeles que lo demuestren.
4. ¿Responde alguna vez con el conocimiento general del modelo en lugar de con nuestro contenido? Respuesta sólida: no, o sí con un ajuste para desactivarlo. Un evaluador técnico en una llamada de ventas de eesel preguntó exactamente esto: si la IA recurre a algo como ChatGPT cuando no sabe, y si eso se puede desactivar.
5. ¿Cómo detectáis una respuesta incorrecta después del lanzamiento? Respuesta sólida: un proceso con nombre (muestreo, puntuación, alertas), además de dónde lo ves en el producto.
6. ¿Qué pasa cuando el proveedor del modelo cambia el modelo? Respuesta sólida: vuelven a ejecutar pruebas con tu historial antes de que el cambio te llegue, y te avisan.

Esa primera pregunta importa más de lo que parece:

En una prueba de eesel con tráfico real de Zendesk de comercio electrónico, el 22 % de los tickets entrantes era spam. Un proveedor que cuente cerrar spam como "resolución" puede sumar 22 puntos a su tasa sin responder a un solo cliente. La entrada sobre deflexión frente a tasa de resolución explica cómo nueve helpdesks cuentan esto de forma diferente.

Un operador en Reddit describió lo que pasa cuando nadie comprueba qué significa "resuelto":

"So we audited a week's worth of auto tickets and found 3 separate cases where the bot made up a policy that doesn't exist. The scary part is the customers believed what it said and walked away feeling that WE were wrong. It even marked the ticket as "resolved" so we didn't notice until they dropped a negative review."

quietkernel_thoughts, Reddit

Así que añade una séptima pregunta: ¿cómo contáis un ticket que el cliente reabre, o por el que vuelve a contactar, en un plazo de 7 días? Si la cifra del proveedor no los resta, mide cómo terminan las conversaciones, no si los problemas se resolvieron.

Traspaso y control

1. ¿Qué tickets podemos excluir por completo, y cómo? Respuesta sólida: por etiqueta, formulario, canal, segmento de cliente o tema, definido por ti, no mediante un ticket al equipo de soporte del proveedor.
2. ¿Puede empezar redactando respuestas para los agentes antes de enviar nada? Respuesta sólida: sí, con un interruptor por tema o canal para pasar de borrador a envío.
3. ¿Qué ve la persona cuando se produce el traspaso? Respuesta sólida: un resumen, lo que ya intentó y las fuentes que usó, escrito en el ticket.
4. ¿Puede un cliente llegar a una persona en cualquier momento? Respuesta sólida: sí, y puedes ver con qué frecuencia lo piden.

La versión más clara de esto que he visto vino de un responsable de CX de una marca directa al consumidor que gestionaba unos 7.000 tickets al mes:

"The AI will never be able to answer 100% of the questions, but if it tries and just answers 'sorry I don't know this,' I cannot go and check all my 7,000 tickets to see if the AI actually made a good answer. Then the point is a little bit gone. I need an AI who is only handling the tickets that it's confident to handle and all the other ones, leave them alone."

Eso es un requisito, así que escríbelo como tal: "La IA solo debe responder a tickets que pueda contestar con nuestro contenido, y debe dejar todos los demás intactos para una persona". Después, pruébalo. Mi entrada sobre buenas prácticas de traspaso de agentes de IA cubre cómo es un traspaso limpio.

Integración con el helpdesk y acciones

Este es mi trabajo diario, así que seré directo: "se integra con Zendesk" puede significar cualquier cosa, desde un agente completo que etiqueta, enruta y responde dentro de los tickets hasta un widget que lee tu centro de ayuda y nada más.

1. ¿Funciona dentro de nuestro helpdesk como un agente, o a su lado? Respuesta sólida: lee y escribe tickets, etiquetas, campos y notas internas en tu helpdesk, con una lista de cuáles exactamente.
2. ¿Qué acciones puede realizar, no solo responder? Respuesta sólida: una lista con nombre (consultar un pedido, actualizar un campo, emitir un reembolso bajo un límite), con cómo se autoriza y se registra cada una.
3. ¿De qué aprende? Respuesta sólida: centro de ayuda, macros, tickets pasados, documentos internos, cada uno opcional y filtrable. Pregunta si puedes elegir qué tickets pasados lee (rango de fechas, etiquetas).
4. ¿Qué pasa cuando la API de nuestro helpdesk está caída o lenta? Respuesta sólida: reintentos, sin respuestas duplicadas y un registro que puedas leer.
5. ¿Con qué rapidez responde? Respuesta sólida: tiempos medidos para chat y correo con tráfico real. Un comprador hizo una evaluación de 67 pruebas, encontró las respuestas sólidas y luego se fue porque el widget de chat era lento y se bloqueaba. La velocidad pertenece a la tabla de puntuación.

Si usas un helpdesk concreto, pide como referencia a un cliente que use ese mismo helpdesk. Compara lo que dice cada proveedor con lo que hace la IA propia de tu helpdesk: los análisis de precios de Zendesk AI, precios de Freshdesk Freddy AI y precios de Gorgias AI son buenas referencias.

Seguridad, privacidad y uso de datos

La mayor parte de esta sección es de aprobado/suspenso. Los acuerdos que he visto atascarse en esta fase lo hicieron por un único motivo cada uno: ningún informe SOC 2, una revisión interna de ISO que el proveedor no pudo superar, o ningún acuerdo de asociado comercial (BAA) de HIPAA. Averígualo en la semana uno, no en la seis.

1. ¿Qué certificaciones tenéis hoy y cuáles están en curso? Pide el informe o una carta puente, y el alcance. "SOC 2 Type II en curso" y "informe SOC 2 Type II disponible bajo NDA" son respuestas distintas.
2. ¿Se usan nuestros datos para entrenar algún modelo, vuestro o de un proveedor? Respuesta sólida: un no claro, en el contrato. Lee el detalle: el centro de confianza de Zendesk dice que su IA generativa no se entrena con datos de clientes, pero los datos de servicio depurados sí entrenan sus propios modelos de aprendizaje automático entre cuentas.
3. ¿Dónde se almacenan y procesan nuestros datos, y con qué subencargados? Respuesta sólida: una lista, con regiones.
4. ¿Podéis redactar números de tarjeta y otros datos personales antes de almacenarlos? Una empresa de medios que evaluaba eesel hizo de esto su principal objeción incluso antes de empezar una prueba.
5. ¿Firmáis un BAA de HIPAA, y en qué plan? Solo si manejas datos de salud, pero si lo haces, es un criterio.
6. ¿Qué pasa con nuestros datos cuando nos vamos? Respuesta sólida: exportación en un formato con nombre, eliminación con confirmación y un plazo.

Un cuestionario de seguridad estándar no capturará todo esto por sí solo. Un comprador de una empresa B2B SaaS de 200 personas expresó bien la brecha:

"My company (200 people, B2B SaaS) is starting to use AI vendors for customer support and internal tools. Our procurement process is basically "fill out security questionnaire, get SOC 2, done." But I'm realizing SOC 2 doesn't cover AI-specific stuff. Like what happens when the vendor updates their model and it starts giving wrong answers? What if the training data had customer info in it?"

Alieezeee, Reddit

Por eso la pregunta sobre el cambio de modelo de la sección de precisión debe ir junto a los criterios de seguridad, y no solo en la revisión del producto.

Para la versión completa, usa la lista de seguridad para proveedores de soporte con IA como anexo de la RFP, y la guía de SOC 2 y RGPD si tu equipo de seguridad es nuevo con proveedores de IA.

Precios y unidades facturables

Las respuestas aquí parecen comparables y no lo son. Un proveedor factura por resolución, otro por conversación, otro por crédito, otro por puesto, y tres no publican ningún precio. Pregunta esto:

1. ¿Qué es exactamente una unidad facturable? Consigue la definición por escrito.
2. ¿Quién decide que una conversación cuenta, y podemos verlo y disputarlo?
3. ¿Qué pasa en nuestro mes de más actividad? Pide la factura con el doble de tu volumen normal.
4. ¿Hay un exceso de consumo, y está activado por defecto?
5. ¿Están limitados los aumentos de precio durante la duración del contrato? Un equipo de soporte de hardware que evaluaba eesel había visto cómo el precio de un proveedor anterior se más que duplicaba, y quería esta vez un bloqueo de precio por escrito.
6. Rellena esta fila: nuestro volumen de tickets por mes de los últimos 12 meses, presupuestado a vuestras tarifas.

La unidad de facturación cambia quién paga por el fracaso:

Esa celda inferior izquierda es ahora la pregunta más importante de la sección. Desde el 18 de mayo de 2026, Zendesk clasifica cada conversación de IA en tres niveles, y solo una "verified resolution" consume tu asignación. El propio modelo de Zendesk toma esa decisión, 72 horas después del primer correo o 2 horas después del inicio de un chat de mensajería. Eso es justo contigo en un sentido (no pagas por las escaladas), pero aun así deberías preguntar cómo auditar los veredictos.

Decagon, que permite a los clientes elegir cualquiera de los dos modelos, argumenta contra la facturación por resolución en su propio blog de precios: "You never want to be in a situation where you're arguing over what a 'resolution' is." Sierra va en la dirección contraria con los precios basados en resultados, donde los resultados se acuerdan con cada cliente.

En Hacker News, respondiendo a una startup que vendía facturación basada en resultados, un ingeniero señaló la pregunta que debería responder todo presupuesto por resultados:

"can you clearly explain how you will measure and track the outcomes? That's the key detail that matters. Relying on customers to self-report is not sufficient, and an automated self-report-system is not a true improvement."

mushufasa, Hacker News

Así se ven las tarifas públicas para el mismo mes. Mueve los controles deslizantes a tus cifras:

Dos cosas saltan a la vista cuando juegas con esto. El precio por resolución baja cuando la IA resuelve menos, así que un presupuesto bajo puede esconder un agente débil. Y la diferencia entre proveedores cambia por completo con tu tasa de resolución, por eso se presupuesta después de la prueba con tickets, no antes. Para un análisis más profundo, consulta el coste real por resolución y el desglose de precios de Agentforce.

Implementación y soporte

1. ¿Qué necesitáis de nosotros, en horas, por rol? Respuesta sólida: una estimación del tiempo de operaciones de soporte, ingeniería y seguridad, no "esfuerzo mínimo".
2. ¿Cuánto tarda en estar activo el primer tipo de ticket? Respuesta sólida: una fecha ligada a un alcance, con lo que podría retrasarla.
3. ¿Quién se encarga del ajuste después del lanzamiento? Respuesta sólida: una persona con nombre, con lo que incluye el precio.
4. ¿Cuáles son los motivos más habituales por los que se estancan vuestros despliegues? Un proveedor con despliegues reales tiene una respuesta concreta y honesta. Una vaga es una señal de alerta.
5. ¿Podemos pagar menos mientras nos ponemos en marcha? Un director financiero en una llamada de ventas de eesel pidió precios reducidos durante la implementación y dijo "this is not just for you, but for any tech vendor." Es una petición normal.

La guía de implementación y la lista de errores de implementación son útiles para enviar al responsable de tu proyecto.

Contrato y salida

1. ¿Podemos exportar nuestras conversaciones, ajustes y resultados de pruebas? ¿En qué formato?
2. ¿Cuál es el plazo de preaviso, y hay una penalización por salida anticipada?
3. ¿Qué pasa si el primer caso de uso no alcanza el objetivo acordado? Respuesta sólida: un remedio por escrito (piloto ampliado, crédito o el derecho a irte).

Si estás sustituyendo a un proveedor de IA en lugar de comprar el primero, añade a tus lecturas la guía para cambiar de proveedor de soporte con IA.

¿Cómo debes puntuar a los proveedores de soporte con IA?

Ejecuta primero los criterios. Quien no pase uno queda fuera, por buena que fuera la demo. Luego puntúa al resto de 1 a 5 en cada fila y multiplica por el peso.

Criterios (aprobado/suspenso, antes de puntuar): certificación o informe requerido disponible, compromiso contractual de no entrenar con tus datos, tu helpdesk compatible, residencia de datos que necesitas, BAA de HIPAA si manejas datos de salud, exportación de datos al salir.

Aquí hay dos decisiones deliberadas. La prueba con tickets pesa más que las respuestas por escrito y el traspaso juntos, porque es la única fila a la que el proveedor no puede llegar escribiendo. Y la velocidad tiene su propia fila, porque un widget de chat lento pierde acuerdos que las respuestas precisas habían ganado. La tabla de puntuación para pilotos de soporte con IA tiene una versión más larga si quieres subpuntuaciones.

¿Cómo pruebas a los proveedores con tus propios tickets?

Esta es la sección 9 de la RFP, y es la que yo defendería con uñas y dientes. Así se ejecuta para que los resultados sean comparables.

1. Extrae un conjunto de prueba de los últimos 90 días. De 100 a 200 tickets resueltos, muestreados entre tus principales motivos de contacto en proporción al volumen. Quita todo lo que no puedas compartir.
2. Añade a propósito los difíciles. De 10 a 20 tickets donde la respuesta honesta es "no" o "eso no lo ofrecemos", más algunos clientes enfadados y algunos que requieran una acción (reembolso, cambio de pedido).
3. Da a cada proveedor el mismo conjunto y el mismo conocimiento. La misma exportación del centro de ayuda, las mismas macros. Sin escenarios elegidos por el proveedor.
4. Puntúa cada respuesta frente a lo que tu equipo envió realmente. Correcta y utilizable tal cual, correcta pero necesita edición, incorrecta o traspasada correctamente.
5. Informa de varias cifras, no de una. Precisión, tasa de envío sin cambios, tasa de respuestas incorrectas, tasa de traspaso y tiempo de respuesta.

El paso 5 es donde sale la verdad. En una prueba de eesel con tráfico real de Zendesk de comercio electrónico (284 chats más una comprobación cruzada de 100 tickets), la IA alcanzó un 93 % de precisión en la clasificación y detectó todos los tickets de spam. Pero los agentes enviaron sus borradores sin cambios solo el 12 % de las veces. Cuando el equipo profundizó, alrededor del 65 % de las reescrituras eran por longitud y tono (los agentes recortaban borradores de 8 a 15 frases a 1 a 3), y solo alrededor del 5 % eran por errores de hecho. Una cifra habría dicho "genial" o "inútil". Cinco cifras dijeron "precisa, demasiado larga, arregla el tono".

Los tickets de "no honesto" del paso 2 importan más de lo que parece. Un equipo técnico B2B contó a eesel en una llamada de ventas que un bot había confirmado "sí, damos soporte a tu modelo de coche" para marcas que no estaban en su base de datos, porque la base de conocimiento decía "we support all models". Esa es exactamente la clase de respuesta que una demo de proveedor nunca muestra.

Este es el paso en torno al cual está construido eesel. La habilidad de simulación de helpdesk toma 20 tickets que tu equipo resolvió recientemente, redacta su propia respuesta para cada uno, la compara con lo que envió tu equipo, agrupa los resultados por tema y no envía nada a los clientes:

Fíjate en qué dice ese informe que es la brecha: no la redacción, sino las acciones. En aproximadamente la mitad de los tickets coincidentes aún hacía falta que una persona hiciera algo en un sistema interno. Ese es el tipo de hallazgo que quieres antes de firmar, porque te dice por qué integraciones preguntar. Si un proveedor no puede ejecutar algo así con tu historial, pregúntale cómo lo sabrás entonces. La guía de pruebas de agentes de soporte con IA profundiza en cómo construir el conjunto de prueba.

Una prueba más que vale la pena tomar prestada, de un hilo de Reddit sobre qué debería demostrar una demo en vivo:

"Make them do the demo with a knowledge base that's deliberately outdated by like 6 months, and see if the agent just confidently spits wrong info or admits it don't know. That's the real test for me"

Right_Smile_4412, Reddit

Tu base de conocimiento real ya está algo desactualizada en algún punto, así que esta no es una pregunta trampa. Es el caso normal.

¿Qué publican los proveedores de soporte con IA antes de que envíes la RFP?

Puedes rellenar parte de la RFP tú mismo a partir de las páginas de los proveedores. Esto es lo que encontré en el sitio de cada proveedor en octubre de 2026:

Tres de seis no publican precio, lo cual es normal en la venta a grandes empresas, pero significa que tu RFP tiene que pedir a cada uno la misma fila de coste. Mi recopilación de los mejores agentes de atención al cliente con IA cubre más proveedores si tu lista larga es más amplia.

¿Qué errores cometen los equipos con las RFP de soporte con IA?

• Enviar 200 preguntas. Los proveedores responden a cuestionarios largos con texto copiado del anterior. 40 preguntas afiladas obtienen mejores respuestas que 200 genéricas.
• Dejar que los proveedores elijan los escenarios de la demo. Todos los proveedores quedan bien con sus propios ejemplos. Usa tus tickets.
• Comparar presupuestos con unidades distintas. Por resolución y por conversación no se pueden comparar hasta que ambos se presupuestan sobre tu mes.
• Tratar "en curso" como "hecho". Una certificación en curso puede estar bien para ti, o puede ser un criterio. Decídelo antes de la demo, no después.
• Saltarse el mes de más actividad. Presupuesta tu pico, no tu media. El precio por unidad sube con tu volumen.
• Dejar fuera a los agentes. Las personas que van a editar los borradores de la IA deberían puntuar la prueba con tickets. Detectarán problemas de tono que un responsable que lee resúmenes no verá.

El punto del peor cliente merece repetirse, porque es el más fácil de saltarse:

"test it as your worst customer not your best one vague question, typo in it, missing half the context. if it handles that you're probably fine. most people only test the clean version and then wonder why it breaks on real customers"

ShotOil1398, Reddit

¿Cómo respondería eesel a esta RFP?

Ya que te he dicho que hagas preguntas difíciles, aquí van las respuestas de eesel a las que suelen decidir, incluidas las que podrían descartarlo.

• Qué es: un compañero de IA para el helpdesk que trabaja dentro de tu helpdesk como un agente más: redacta o envía respuestas, etiqueta y enruta tickets, y aprende de tu centro de ayuda, tus macros y tus tickets pasados. Se conecta a Zendesk, Freshdesk, Gorgias, Help Scout, HubSpot, Front y Salesforce, entre otros.
• Unidad de facturación: un crédito por ticket o chat que gestiona, sin importar cuántas respuestas. Los planes van de $299 por 500 créditos a $1,749 por 5.000, sin tarifas por puesto. El exceso cuesta $0.80 por crédito y está desactivado salvo que lo actives, con un tope que fijas tú. Un plan gratuito tiene 100 créditos y no necesita tarjeta.
• Seguridad: auditoría SOC 2 Type II en curso, con el periodo de observación iniciado el 1 de octubre de 2026. Si necesitas hoy un informe terminado, es un criterio que eesel aún no cumple. Los BAA de HIPAA están en Enterprise. eesel no entrena ni ajusta modelos con tus datos.
• Prueba con tickets: integrada, con tus propios tickets resueltos, antes de que nada llegue a un cliente.

Cómo se ve en producción, según historias de clientes publicadas:

• Finanzas reguladas, primero borrador. smava, una empresa alemana de comparación de préstamos, ejecuta tres agentes de eesel en un mismo Zendesk: uno categoriza cada ticket, otro redacta a partir de la biblioteca de macros y otro prepara respuestas listas para el cliente. Son 27.000 tickets gestionados en un mes y 15.300 borradores de respuesta, y eesel nunca los envía por sí mismo.
• Respuestas solo a partir de tus documentos. Una empresa de automatización industrial puso su biblioteca técnica detrás de un chat que responde solo desde los documentos, enlaza su fuente y admite cuando no tiene ninguna. Cada ticket de soporte llega con un borrador para que lo edite un ingeniero.
• Volumen con un plan fijo. SamCart ejecuta un agente en tickets de Freshdesk y otro en el chat de su sitio web, respondiendo a partir de 280 artículos del centro de ayuda con un plan de 8.000 interacciones al mes.

Prueba eesel como uno de los proveedores de tu RFP

Si estás redactando una RFP de soporte con IA este trimestre, pon a eesel en la lista corta y haz que ejecute primero la sección 9. Conecta tu helpdesk, pídele que simule con tus tickets resueltos recientemente y tendrás un informe puntuado por motivo de contacto antes de cualquier llamada de ventas, sin que se envíe nada a los clientes. Después exígele los mismos criterios y la misma fila de coste que a todos los demás.

Prueba eesel gratis, o reserva una demo si tu equipo de seguridad quiere ver primero los controles.