Este artículo está dirigido a los clientes de Support Enterprise que utilizan actualmente una configuración de cuenta central y cuenta de marca para administrar varias marcas, y están pensando hacer la migración a multimarca para administrarlas.
Prerrequisitos para la migración a multimarca
Si está pensando o planeando hacer la migración del modelo de cuenta central y cuenta de marca a la función multimarca, tenga en cuenta estos obstáculos que impedirán que hagamos un migración completa de su cuenta a multimarca.
Antes de leer los detalles, pregúntese si en realidad está usando todas sus cuentas de marca. Tenemos clientes que han configurado un modelo de cuenta central y cuenta de marca, pero solo usan la cuenta central. Si no está usando sus cuentas de marca, o si dichas cuentas no están compartiendo tickets con la cuenta central, probablemente no necesite hacer una migración.
- Comunidades del centro de ayuda. Puede migrar el contenido de la comunidad usando la API del centro de ayuda. Si desea más información, consulte Temas y Publicaciones en la documentación para programadores.
- Multimarca o cuenta central y cuenta de marca. Una configuración de cuenta central y cuenta de marca no puede tener una instancia de multimarca. Estos dos productos son mutuamente excluyentes.
Si se siente a gusto con todo lo mencionado arriba y desea más información sobre la migración a la función multimarca, comience por leer el artículo Pasos para la migración a multimarca.
Comparar el modelo de cuenta central y cuenta de marca con la función multimarca
En esta sección se describe el cambio de comportamiento que se podría percibir en un modelo de cuenta central y cuenta de marca después de hacer la migración a la función multimarca. Tenemos planes para cambiar el comportamiento de la función multimarca para algunos de los elementos enumerados a continuación, pero aún no tenemos un cronograma específico.
- Autenticación remota/Inicio de sesión único. Cada centro de ayuda redirige a los usuarios al mismo protocolo de inicio de sesión único y la misma base de datos. Esto se debe a que los usuarios dependen de la cuenta, no de la marca.
-
Marca del canal Zopim. Los tickets creados a través de Zopim no tienen actualmente en cuenta el atributo de marca. De nuevo, nuestra intención es corregir esto en el futuro.
- Firmas de agentes. Solo hay una firma por agente. Los agentes pueden aprovechar sus macros personales para crear una firma de agente para cada marca.
-
Identidades de marca de usuario final. Actualmente no hay manera de segmentar a los usuarios finales para las listas de clientes en función de la identidad de marca porque no se hace seguimiento de qué usuarios han interactuado con qué marcas.
- Permisos de agentes. Todos los agentes tienen acceso a todas las marcas de manera predeterminada. Se pueden crear vistas de marcas para que las utilicen los agentes. Si se necesitan restricciones, se pueden usar disparadores para asignar tickets de marca a los grupos y restringir los permisos de los agentes a los tickets de esos grupos.
-
Permisos de usuarios finales. No es posible ocultar ciertos centros de ayuda para impedir que los vea un subconjunto de usuarios finales. Se diseño así a propósito, pero estamos trabajando para encontrar una manera de admitir un servicio segmentado y privilegiado en función del tipo de usuario. Sin embargo, para evitar el acceso al contenido, al portal de usuarios y a las comunidades, se pueden usar javascripts y etiquetas de usuario de Zendesk.
-
Plantillas de correo electrónico únicas. En un principio habrá un límite de una plantilla de HTML por cuenta. Tenemos planeado actualizar esto en el futuro, pero por ahora existe la posibilidad de crear una plantilla de HTML compartida y usar macros para ponerle marca al texto de la respuesta.
- Formularios de ticket. Se puede restringir el acceso a formularios de ticket específicos por marca (consulte Creación y aplicación de formularios de tickets de marca). Eso permite controlar los formularios de ticket que están disponibles para los usuarios finales y los agentes en función de la marca del centro de ayuda o del ticket que estén viendo.
-
Integraciones. Estamos trabajando para garantizar que el valor de la marca se transfiera en todas nuestras principales integraciones, incluidas Jira y SFDC. Todas las demás aplicaciones tendrán que ser actualizadas por sus dueños.
- Restablecimiento de contraseña. Si un usuario final solicita un restablecimiento de contraseña en el portal de una marca, se restablecerá la contraseña para todas las marcas simultáneamente. El correo electrónico de restablecimiento de contraseña no se puede personalizar, pero incluirá una lista de todos los centros de ayuda asociados para que el usuario final sepa dónde se actualizó su contraseña.
Comprender los pasos y las limitaciones de la migración
Estos son los elementos más importantes de la migración a multimarca:
-
Pasos y cronograma
-
Limitaciones
Cronograma y pasos típicos
- Usted configurará su instancia de multimarca (“Configuración”, “Canales”, “Marcas”, Roles de agente...).
- Zendesk migrará una muestra del contenido (tickets y artículos del centro de ayuda).
- Usted verificará si el contenido de muestra se migró como se esperaba.
- Zendesk completará la migración del contenido, exceptuando los tickets que tengan un estado menor que cerrado (es decir, los tickets que están "en curso").
- Usted configurará su flujo de trabajo en su instancia de multimarca (macros, disparadores, automatizaciones y vistas).
- En preparación para el último paso de la migración, usted se comunicará con sus clientes para avisarles que habrá un periodo de inactividad próximamente (con mensajes en los centros de ayuda de las cuentas de marca y quizás un correo electrónico de advertencia).
- Tareas durante el periodo de inactividad: Zendesk migrará los tickets restantes y usted cambiará de subdominio (de cuenta de marca a multimarca) y establecerá el mapeo de host para cada marca.
En cuanto al cronograma, este esfuerzo está limitado por los recursos que Zendesk tiene dedicados a este proceso, la complejidad de la migración de su programa y la rapidez con la que usted complete sus tareas. Le podremos dar una fecha de finalización aproximada solo después de obtener todos sus requisitos de migración.
- Tickets
- Se hace la migración de todos los comentarios, archivos adjuntos y metadatos (p. ej., el valor actual de cada campo de ticket y las etiquetas).
- No se pueden migrar los eventos (p. ej., la etiqueta “xyz” fue agregada por el disparador “123” el 12 de diciembre de 2014).
- No es posible migrar la ID ni el número del ticket porque los tickets nuevos se crean en la instancia de multimarca.
- Contenido del centro de ayuda
- Se migran los artículos (y los archivos adjuntos). Todos los artículos tendrán el mismo autor después de la migración (el dueño de la cuenta o una persona que usted designe).
- La información de fecha de creación, comentarios y suscripción no está disponible para los artículos ni para la configuración de la sección y el contenido de las comunidades.
- Las plantillas no pueden migrarse (es decir, la personalización hecha en el centro de ayuda).
- No es posible migrar la configuración de las categorías y secciones. Es necesario restablecerla después de la migración.
- Las ID y los números de categorías, secciones y artículos cambiarán después de la migración. Los vínculos externos existentes tendrán que actualizarse.
- Información del usuario
- Los usuarios finales, agentes, grupos y organizaciones pueden migrarse (esto no incluye los campos personalizados, las notas de usuarios ni los detalles de la información anterior).
- Las contraseñas de los usuarios finales no se pueden migrar. Si sus clientes inician sesión en Zendesk directamente (es decir, si tienen un perfil de autenticación con Zendesk), tendrán que restablecer sus contraseñas cuando finalice la migración.
- Los roles de agente no se migran.
- Tampoco se migran la organización, el idioma, la zona horaria, los detalles y las notas ni los campos personalizados en los perfiles.
- Flujo de trabajo
- Las macros sí se pueden migrar.
-
No se pueden migrar sus vistas, disparadores y automatizaciones (no tendría mucho sentido porque es necesario revisarlos y ajustarlos a la nueva marca que se ha creado).
-
El contenido dinámico no está disponible para la migración.
- Otros
- Índices de satisfacción: no disponibles.
- La migración de "Configuración" y "Canales" no está disponible (y no tendría mucho sentido dado que hay marcas adicionales).
- Los favoritos de artículos específicos enviarán a los usuarios a la página principal del centro de ayuda de la marca (no al artículo equivalente en el nuevo centro de ayuda de la marca).
- Estamos trabajando para garantizar que el valor de la marca se transfiera en todas nuestras principales integraciones, incluidas Jira y SFDC. Todas las demás aplicaciones tendrán que ser actualizadas por sus dueños.