Una migración del chatbot del sitio tiene éxito cuando el sustituto conserva las tareas que los visitantes siguen necesitando y hace visibles todas las que no admite antes del cambio. Mover un archivo exportado o cambiar un código de inserción no demuestra esa continuidad. Empieza con un registro de respuestas actuales, páginas fuente, acciones y vías de contacto. Decide qué puede conservar el sustituto, qué hay que reconstruir y qué debe permanecer en otro sistema.
Para un sitio pequeño puede bastar una hoja práctica en lugar de un gran proyecto de migración. La distinción importante es entre sustituir respuestas basadas en información pública y sustituir toda una operación de asistencia. Una herramienta que responde desde páginas publicadas puede servir para lo primero y dejar sin resolver la consulta de cuentas, las citas, la asignación de agentes o el historial de conversaciones.
Autor: Achla AI, organización. Revisión: 14 de octubre de 2026. Esta guía combina documentación primaria actual con una hoja original para conservar comportamientos, preparada con ayuda de IA. Los ejemplos son hipotéticos; no se midieron migraciones de clientes, disponibilidad del servicio ni comparativas de rendimiento. El objetivo es ayudar al propietario del sitio a tomar una decisión de sustitución con un alcance definido.
¿Qué estás sustituyendo realmente?
Empieza por la experiencia que ofreces actualmente al visitante. «Tenemos un chatbot» es demasiado amplio para ser un requisito útil. En un sitio significa responder sobre horarios. En otro incluye identificar clientes, leer pedidos, cambiar citas y conectar conversaciones con empleados.
Escribe una tarea con las palabras del visitante: «¿Qué documentos debo llevar?» Después registra de dónde procede la respuesta y qué sucede a continuación. Una página pública de preparación puede respaldar una respuesta informativa. «¿Qué documentos he subido ya?» exige contexto personal y otro límite de acceso, aunque ambas preguntas contengan «documentos».
Separa la exactitud de la fuente de la decisión de migrar. Si la página pública está desactualizada, conservar la respuesta antigua no es el objetivo correcto. Haz que el responsable habitual corrija la fuente autorizada y evalúa el sustituto con esa información aprobada. Nuestra guía del chatbot basado en contenido del sitio explica las fuentes y la recuperación de información; este artículo trata de la continuidad al cambiar de proveedor.
Enumera también la interfaz actual. Un botón flotante, un recuadro insertado y un campo de búsqueda existente son recorridos diferentes. Registra las páginas donde está disponible cada uno y la vía habitual de contacto o búsqueda que sigue funcionando cuando el chatbot no puede ayudar.
Crea un registro para conservar comportamientos
Usa una fila por cada tarea importante del visitante, no por cada función del proveedor. La siguiente hoja es un marco original de planificación, no una afirmación sobre las herramientas de migración de ningún proveedor.
| Campo | Qué registrar | Por qué cambia la decisión |
|---|---|---|
| Tarea del visitante | Una pregunta o acción representativa sin datos sensibles | Define el comportamiento que merece conservarse |
| Fuente aprobada | URL pública actual y hecho que respalda | Separa pruebas útiles de una respuesta antigua |
| Comportamiento actual | Respuesta, cita, acción o destino de contacto | Revela lo que perdería el visitante |
| Dependencia | Contenido público, identidad, sistema externo o personal | Evita sustituir un proceso no verificado por un widget de respuestas |
| Prueba de exportación | Formato disponible, alcance y responsable autorizado | Establece qué puede salir del sistema antiguo |
| Prueba del destino | Entrada documentada y comportamiento compatible | Establece qué puede utilizar realmente el nuevo sistema |
| Decisión | Conservar, reconstruir, no transferible o detener | Hace explícito el trabajo pendiente |
| Recorrido y responsable | Página, persona responsable y condición de aceptación | Convierte la decisión en un cambio revisable |
Las cuatro decisiones significan cosas distintas. Conservar indica que existen pruebas del comportamiento requerido en el nuevo proceso. Reconstruir indica que existe un recorrido sustituto documentado, pero todavía necesita preparación. No transferible indica que una función o registro antiguo no puede trasladarse sin más; decide si debe mantenerse en otro sistema. Detener indica que el sustituto no puede cumplir una tarea obligatoria y no debe asumir ese recorrido.
Añade una condición breve de aceptación a cada fila importante. Para responder sobre una política podría ser: «la respuesta incluye la condición necesaria y enlaza la política pública actual». Para un contacto: «el visitante puede acceder a la página de contacto existente sin enviar información privada al widget de respuestas». Son condiciones propuestas para revisar, no resultados ya conseguidos.
Concreta quién es responsable. El encargado del sitio puede gestionar la ubicación, un editor la política y un responsable de asistencia el destino de contacto. Una persona puede desempeñar varios papeles, pero el registro debe distinguir las decisiones.
No marques una fila como «conservar» solo porque ambos proveedores describen un chatbot. Registra el alcance exacto: una respuesta pública compatible, sus requisitos de fuentes y su recorrido. Aceptar la migración es una decisión que tomas a partir de pruebas, no una insignia concedida por la hoja.
Por qué una exportación no demuestra una importación
Una exportación responde a una pregunta sobre el proveedor anterior: ¿qué registros puede obtener una persona autorizada y en qué formato? Una importación responde a otra pregunta sobre el destino: ¿qué datos acepta y qué significado o comportamiento conservará?
Por ejemplo, la documentación de exportación de conversaciones de Intercom describe varios métodos para contenido y datos de conversaciones, con alcances y permisos distintos. No demuestra que otro proveedor pueda restaurarlas como sesiones activas, recrear su asignación o tratarlas como fuente de conocimiento.
Separa transcripciones de conversaciones, páginas públicas de conocimiento y registros de configuración. Una transcripción puede contener nombres, datos de cuentas o información proporcionada en privado. No es automáticamente adecuada para un asistente público de respuestas del sitio. No copies conversaciones privadas al conocimiento público para que el sustituto parezca más informado. Utiliza preguntas autorizadas y desidentificadas y expectativas basadas en fuentes públicas aprobadas para la hoja de migración.
Pide al destino su contrato documentado de incorporación de datos. Si no hay pruebas de una importación específica de un competidor, deja ese campo como desconocido. Un rastreador gestionado de sitios públicos puede permitir reconstruir respuestas desde páginas públicas existentes; es un proceso distinto de importar la configuración de conocimiento o el historial de otro proveedor.
La documentación de instalación de Achla describe su widget y el proceso de verificación. No demuestra una función nativa de importación desde competidores o migración del historial de conversaciones. Evalúa la tarea de respuestas públicas por sus propios méritos, sin suponer que un archivo exportado cerrará esa brecha.
Registra respuestas, fuentes y recorridos por separado
Considera este sitio hipotético de servicios. Las filas ilustran decisiones que hay que investigar; no son resultados de pruebas observadas.
| Tarea actual | Pruebas necesarias para el sustituto | Decisión propuesta |
|---|---|---|
| Explicar la política de cancelación publicada | Página actual, respuesta respaldada y enlace utilizable a la fuente | Conservar solo después de verificar |
| Consultar la cita individual de un cliente | Integración autorizada de cuenta y acceso adecuado | Detener la sustitución por contenido público |
| Pedir ayuda a un empleado | Vía documentada con personal y expectativas claras | Mantener o reconstruir por separado |
| Abrir resultados habituales de búsqueda del sitio | Destino de búsqueda funcional desde la página correspondiente | Conservar ese recorrido independientemente |
| Revisar una conversación privada anterior | Portabilidad documentada del historial y tratamiento autorizado | No transferible hasta que haya pruebas de lo contrario |
Un cambio de URL de cita no significa automáticamente una migración fallida, y una URL sin cambios no demuestra una respuesta correcta. Comprueba que la página citada respalde la información requerida y siga siendo accesible al visitante previsto. No prometas conservar citas solo porque las páginas públicas subyacentes sigan en línea.
La asistencia humana también tiene su propio contrato. La documentación de transferencia de Zendesk describe la transferencia configurada y el comportamiento de los responsables de respuesta de su producto. Esa función no se traslada por defecto a un widget independiente. Un enlace normal puede conservar un destino de contacto, pero no recrea una transferencia nativa de responsabilidad sobre la conversación.
Prepara el sustituto antes de cambiar el recorrido activo
Conserva un registro recuperable de la instalación actual: plantilla o conector responsable, ajustes relevantes de ubicación, páginas cubiertas, propietario de la cuenta del proveedor y procedimiento conocido para restaurar el recorrido anterior. Guarda la configuración necesaria de forma segura; no incluyas claves privadas o datos de sesión en una hoja compartida.
La responsabilidad de la instalación importa porque el cambio afecta al sitio además del servicio de respuestas. La guía de instalación web de Intercom documenta su propia integración. Usa las instrucciones actuales de cada destino en lugar de adaptar atributos de scripts o llamadas de ciclo de vida de un proveedor a otro.
Comprueba los requisitos del navegador antes de elegir. Un script de terceros añade trabajo a la página, como explica la guía de web.dev sobre JavaScript de terceros. Eso justifica examinar la página real y sus dependencias, no prometer mejoras de rendimiento por cambiar de proveedor. La política de seguridad del navegador también puede bloquear recursos necesarios; la guía CSP de MDN explica ese límite. Mantén intacta la política de la organización y evalúa su compatibilidad con el nuevo widget.
Define la aceptación a partir del registro. ¿Qué preguntas públicas y expectativas sobre fuentes deben seguir cubiertas? ¿Qué vías habituales deben seguir disponibles? ¿Qué dependencias quedan excluidas expresamente? Las orientaciones de Notre Dame sobre chatbots tratan pruebas, lanzamiento y mantenimiento; adopta esa perspectiva operativa sin convertir la migración en otra comparativa genérica de respuestas.
Planifica un cambio controlado y una vía de regreso
Elige un recorrido limitado para el cambio propuesto e identifica quién puede autorizarlo. Especifica el estado actual, el estado sustituto previsto y las condiciones que obligarían a volver a la configuración anterior. Registra el procedimiento real de recuperación antes de cambiar nada en línea.
Usa un único cargador activo del chatbot en la página evaluada. Dos widgets superpuestos dificultan saber qué sistema respondió, qué control gestiona la interacción o qué solicitud falló. Las instrucciones actuales de instalación de Achla también exigen una sola inclusión y advierten de no combinar el conector con una etiqueta manual. Separa las comparaciones de candidatos de su instalación simultánea en producción.
Un plan de regreso es más que «podemos reinstalar la herramienta antigua». Confirma que el responsable autorizado conserve el acceso, que la configuración relevante se pueda recuperar y que el servicio antiguo admita el recorrido necesario. Son cuestiones que verificar, no garantías de recuperación o de ausencia de interrupciones. Conserva los artefactos e información de cuentas necesarios para recuperar; cualquier retirada o eliminación posterior requiere su propia decisión.
Después de un cambio aprobado por separado, revisa las mismas filas en las páginas previstas. Registra comportamientos cubiertos, comportamientos ausentes y responsabilidades pendientes. Una mejora aparente de una respuesta no compensa perder una vía humana o específica de cuenta que sigue siendo necesaria.
¿Cuándo continuar, revisar o mantener al proveedor actual?
Pasa a una evaluación limitada del sustituto cuando las tareas públicas necesarias tengan un destino respaldado por pruebas y las vías independientes de los visitantes sigan contempladas. Revisa cuando una carencia concreta de fuentes, ubicación o responsabilidad tenga una corrección asignada. Mantén el recorrido actual cuando una función esencial no esté cubierta o se desconozca la vía de recuperación.
Elegir un servicio gestionado frente a una arquitectura propia es una decisión aparte, tratada en búsqueda con IA gestionada o desarrollo propio. Una hoja de migración debe conservar las responsabilidades necesarias aunque el sustituto tenga menos funciones o una interfaz distinta.
¿Dónde encaja Achla en una decisión de sustitución?
Para responder sobre un sitio público, contrasta la oferta de búsqueda en documentación, los precios actuales y las orientaciones de solución de problemas de Achla con tu registro completado. Si ese alcance documentado encaja, inicia el proceso de incorporación existente. Mantén los requisitos de datos privados, asistencia humana y transacciones en procesos verificados por separado. El resultado útil es una decisión defendible, con cada tarea importante del visitante todavía a cargo de alguien.
