Respuestas de soporte
Cada ticket recibe un borrador basado en su propio centro de ayuda: una consulta de reembolso lleva su plazo real y una de configuración, sus pasos reales. El agente lo revisa de un vistazo en lugar de reescribirlo. Paga por uso, sin suscripción.
Ejecútela online
Ejecute esto en nuestros servidores con su cuenta. Las herramientas gratuitas corren en su navegador; esta cobra de su saldo del KIT según el precio de arriba.
A una cola de cuarenta tickets abiertos no le importa que la mitad sea la misma pregunta sobre restablecer contraseña, formulada de cuarenta maneras distintas.
Por qué se atascan las colas de soporte
Los equipos de soporte rara vez se retrasan porque las respuestas sean difíciles. Se retrasan porque volver a escribir la misma respuesta, con palabras lo bastante nuevas para que no parezca copiada, lleva varios minutos por ticket, y esos minutos se multiplican en una cola. Lo típico es una mañana en la que la mitad de los tickets son la misma pregunta sobre cómo restablecer la contraseña, formulada de mil maneras. Una respuesta genérica generada no lo arregla: si el borrador ignora lo que dice su centro de ayuda, el agente tiene que comprobar cada frase antes de enviarlo, y eso a menudo es peor que empezar de cero.
Borradores anclados en lo que su empresa dice de verdad
Aquí el borrador se apoya en el material que usted aporta, como páginas de políticas, respuestas guardadas y tickets ya resueltos, de modo que refleja sus condiciones reales y no una invención que suena creíble. Importa porque una política de devolución equivocada o un paso de solución erróneo cuestan la confianza del cliente en un solo mensaje. Los equipos con turnos rotativos lo usan para que la respuesta sea la misma atienda quien atienda. Los productos con clientes en varias regiones redactan desde un único centro de ayuda y un agente bilingüe revisa antes de enviar. Y cuando un borrador sale pobre o dudoso, indica un hueco: falta en el centro de ayuda una respuesta que conviene escribir.
Qué puede hacer con ella
Respuestas consistentes con muchos agentes rotando
Una empresa con personal de soporte que rota usa borradores anclados para que una respuesta de reembolso o de envío se mantenga igual sin importar qué agente esté de turno.
Soporte multilingüe sin un equipo completo por idioma
Un producto con usuarios en varias regiones redacta respuestas ancladas al mismo centro de ayuda, y luego un agente bilingüe las revisa antes de enviarlas en el idioma del cliente.
Señal de un hueco en la documentación
Cuando un borrador vuelve pobre o inseguro, eso indica que al centro de ayuda le falta una respuesta que vale la pena documentar para la próxima vez.
Preguntas frecuentes
¿Inventa la respuesta por su cuenta?
No, el borrador se ancla al contenido de su centro de ayuda que usted proporciona, por lo que la precisión del material de origen importa más que la redacción del ticket mismo.
¿Puede enviar la respuesta de forma automática?
No, devuelve un borrador para que un agente humano lo revise y lo envíe; nada llega a un cliente sin ese paso de revisión.
¿Funciona con tickets en distintos idiomas?
Puede redactar a partir de un ticket en varios idiomas si el contenido de su centro de ayuda cubre el mismo tema, aunque conviene que un revisor bilingüe confirme el tono antes de enviar.
¿Puedo procesar de una vez el backlog de tickets de todo un día?
Sí, cada ticket se envía como su propia solicitud asíncrona, así que un backlog es un lote de solicitudes y no un trabajo gigante único.
¿Se conservan mis datos del ticket y del centro de ayuda después?
No, los datos enviados y los resultados se eliminan después del período de retención y nunca se usan para entrenamiento.
Herramientas relacionadas
Para desarrolladores — acceso por API
Todo lo de esta página está disponible por programación. Esta sección es para equipos que quieren integrarlo en sus sistemas; el resto puede usar la herramienta de arriba sin más.
Endpoint de API
¿Prefiere automatizarlo? Un POST autenticado crea la tarea; el resultado llega por webhook o enlace firmado. La misma capacidad también se ejecuta aquí en la web, por email y desde Telegram — y pronto también desde nuestra app.
Llámela desde su stack
curl -X POST https://api.kit.forhosting.com/text/support-reply \
-H "Authorization: Bearer $KIT_KEY" \
-H "Content-Type: application/json" \
-d '{"text":"El informe trimestral cerró con 1,2 M€ de ingresos."}'const res = await fetch("https://api.kit.forhosting.com/text/support-reply", {
method: "POST",
headers: {
"Authorization": `Bearer ${process.env.KIT_KEY}`,
"Content-Type": "application/json"
},
body: JSON.stringify({
"text": "El informe trimestral cerró con 1,2 M€ de ingresos."
})
});
const { task_id } = await res.json();import os, requests
res = requests.post(
"https://api.kit.forhosting.com/text/support-reply",
headers={"Authorization": f"Bearer {os.environ['KIT_KEY']}"},
json={
"text": "El informe trimestral cerró con 1,2 M€ de ingresos."
},
)
task_id = res.json()["task_id"]<?php
$res = file_get_contents("https://api.kit.forhosting.com/text/support-reply", false, stream_context_create([
"http" => [
"method" => "POST",
"header" => "Authorization: Bearer " . getenv("KIT_KEY") . "\r\nContent-Type: application/json",
"content" => '{"text":"El informe trimestral cerró con 1,2 M€ de ingresos."}',
],
]));
$task = json_decode($res, true);body := bytes.NewBufferString(`{"text":"El informe trimestral cerró con 1,2 M€ de ingresos."}`)
req, _ := http.NewRequest("POST", "https://api.kit.forhosting.com/text/support-reply", body)
req.Header.Set("Authorization", "Bearer "+os.Getenv("KIT_KEY"))
req.Header.Set("Content-Type", "application/json")
res, _ := http.DefaultClient.Do(req)Ejemplo de solicitud
{
"text": "El informe trimestral cerró con 1,2 M€ de ingresos."
}Ejemplo de respuesta
{
"task_id": "tsk_a1b2c3d4e5f6a1b2c3d4e5f6",
"type": "text.support_reply",
"status": "queued",
"_links": {
"result": "/tasks/tsk_…/result"
}
}La API es asíncrona: la llamada devuelve un task_id al instante y el resultado llega por webhook. El polling está limitado a 1 req/s por tarea.
Precio
Precio publicado — sin tokens ni créditos inventados. Una tarea fallida no se cobra.
Límites
max_tokens | 20000 |
Errores
| HTTP | Código | Significado |
|---|---|---|
401 | unauthorized | API key ausente o inválida. |
402 | insufficient_balance | El saldo no cubre el precio de la tarea. |
404 | unknown_type | El tipo de tarea no existe. |
429 | rate_limited | Demasiadas peticiones. Use el webhook en vez de sondear. |
422 | task_failed | La tarea falló tras 3 reintentos. No se cobra. |
Notas técnicas
Este endpoint lee el ticket y el contenido de su centro de ayuda, y redacta una respuesta que un agente puede enviar con solo revisarla, no reescribirla.
La cola que nadie logra vaciar
Los equipos de soporte casi nunca se atrasan porque las respuestas sean difíciles, sino porque escribir la misma respuesta, con palabras lo bastante frescas para no sonar copiada y pegada, toma minutos reales por ticket, y esos minutos se multiplican rápido en una cola larga. Una respuesta genérica de inteligencia artificial que ignora lo que realmente dice su centro de ayuda suele ser peor que no tener borrador, porque el agente igual tiene que verificar cada dato antes de enviarla. text.support_reply se construyó justo para cerrar esa brecha: redacta a partir de sus propias respuestas documentadas, no de una suposición.
Cómo se arma un borrador
El borrador se ancla al material que usted proporciona —páginas de política, macros, tickets ya resueltos— de modo que refleja su ventana de reembolso real o sus pasos de configuración reales, en lugar de una invención que solo suena plausible. Haga POST a /text/support-reply con el texto del ticket y una referencia al contenido de su centro de ayuda, reciba un task_id de inmediato y obtenga la respuesta redactada por webhook firmado o mediante un enlace firmado válido por 24 horas cuando la tarea asíncrona termine.
Anclar la respuesta es lo esencial
Las respuestas de soporte son inusuales entre los textos generados porque equivocarse tiene un costo directo: una política de reembolso incorrecta o un paso de solución de problemas equivocado erosiona la confianza en una sola respuesta. La generación anclada —fijar un borrador a pasajes de origen específicos en lugar de generar libremente— es el enfoque pensado exactamente para ese riesgo, y por eso este endpoint pide de entrada el contenido de su centro de ayuda en lugar de trabajar solo con el ticket.
Dónde decide todavía una persona
El resultado es un borrador, no un envío automático: un agente lo revisa, ajusta el tono cuando el ticket llega caldeado, y lo envía. Los equipos suelen conectar este endpoint a su mesa de ayuda existente para que aparezca un borrador en cuanto se asigna un ticket, reduciendo el tiempo de primera respuesta sin quitar de en medio a la persona que sabe cuándo procede una excepción. Con precio por solicitud más por ticket, el costo escala con el volumen igual que lo hace una cola, y una tarea que falla nunca se cobra.
Casos de integración
Borradores de primera respuesta en horas pico
Un equipo de soporte pasa cada ticket entrante por el endpoint para que los agentes abran una respuesta redactada y apegada a la política, en lugar de un editor en blanco durante el pico de la mañana.
Preguntas técnicas
¿Cómo genera una respuesta la API de respuestas de soporte al cliente?
Envíe el ticket y el contenido de su centro de ayuda por POST a /text/support-reply, guarde el task_id y reciba la respuesta redactada por webhook o mediante un enlace firmado válido por 24 horas.
¿Es gratis la API de respuestas de soporte al cliente?
No, no hay plan gratuito ni prueba; cuesta $0.003 por solicitud más $0.0135 por ticket, y una tarea fallida nunca se cobra.
¿Ya está disponible este endpoint?
Sí, está activo y aceptando solicitudes desde ya.