¿Una o varias instancias de Zendesk?

Su compañía podría tener varias organizaciones formadas por distintos departamentos con una variedad de procesos, necesidades de seguridad y flujos de trabajo. En este sentido conviene considerar qué sería más recomendable para su situación: ¿una o varias instancias de Zendesk? Este artículo describe las ventajas, consideraciones y consecuencias de emplear varias instancias de Zendesk en lugar de solo una. Los temas tratados son los siguientes:

• Consideraciones de funciones
• Cuestiones de alcance
• Resumen

Consideraciones de funciones

Este tema analiza el efecto de emplear una sola instancia de Zendesk para varios equipos en relación a las siguientes funciones: 

• Opciones globales
• Reglas de negocio
• Integraciones
• Autenticación y acceso
• Administración de usuarios finales
• Permisos de agentes y acceso a los tickets
• Informes
• Web Widget (clásico) y widget de Chat
• Guide

Opciones globales

Esta sección describe las consideraciones para las opciones globales. 

• Suscripción
  Si tiene una sola instancia de Zendesk, todos los agentes deben pertenecer al mismo tipo de plan de Support, Guide, Talk y Chat. Para Guide en particular, todos los agentes de Support tienen que ser agentes de Guide. Si solo un equipo utiliza Guide, este es un factor que vale la pena tomar en cuenta si se quiere ahorrar gastos.

• Firmas de agentes
  De forma nativa, existe una firma de agente global por instancia de Zendesk. Para resolver dicha limitación, se pueden personalizar disparadores para cada equipo, con la firma en las condiciones del disparador o del lenguaje de marcado Liquid.

• Plantilla de correo electrónico
  Solo hay una plantilla de correo electrónico nativa por instancia de Zendesk. Para resolver esa limitación, se pueden personalizar todas las reglas de negocio que admiten HTML, CSS o el lenguaje de marcado Liquid. Consulte Aspectos básicos del lenguaje de marcado Liquid y Zendesk Support.
  

• Correos electrónicos de bienvenida/verificación
  Solo hay un correo electrónico nativo de bienvenida y verificación del usuario final que sigue el nombre de la cuenta agregado en Configuración > Cuenta.

• Subdominio
  Solo se puede tener un subdominio que todos los agentes pueden usar y deben recordar. No es posible personalizar el subdominio de los agentes con nombres de equipos.
  
  
• ¿Cualquiera persona puede enviar solicitudes?
  Una cuenta de Zendesk tiene que ser ya sea abierta a todos los usuarios o cerrada a todos los usuarios. Si es una cuenta abierta, cualquiera puede enviar una solicitud, iniciar sesión en Guide o enviar un ticket con el widget. Si es cerrada, el usuario final debe ser un usuario existente de Support para poder enviar una solicitud o tener acceso a Guide. Consulte Configuración del acceso e inicio de sesión de los usuarios finales en Zendesk Support.
  
  
• Nombre de cuenta
  • Solo hay un nombre de cuenta. Consulte ¿Cómo cambio mi nombre de cuenta en Zendesk Support?
  • El nombre de la cuenta está visible en los correos electrónicos si se utilizan marcadores de posición formateados. El nombre de la cuenta forma parte del correo electrónico que se envía a los usuarios finales y que estos pueden ver. Para evitar el comportamiento anterior, deberá dejar de usar los marcadores de posición formateados y utilizar en su lugar otros marcadores de posición de texto enriquecido capaces de admitir contenido enriquecido. Sin embargo, eso elimina la experiencia estética de los marcadores de posición formateados.
  • Por último, el nombre de la cuenta está visible en la página de inicio de sesión y no se puede editar.

• Permitir que los usuarios pertenezcan a varias organizaciones
  Si decide utilizar una sola instancia de Zendesk para equipos de toda índole, existe una opción global que se puede activar o desactivar para toda la instancia.
  
  
• Encuesta de satisfacción
  A pesar de que las encuestas de satisfacción pueden activarse o desactivarse para toda la instancia de Support, se pueden modificar las reglas de negocio de modo que no se activen para determinados grupos. Es posible generar un vínculo de satisfacción para cualquier ticket que utilice marcadores de posición. Consulte Usar marcadores de posición para las calificaciones de satisfacción del cliente.
  
  
• Exportación de datos
  Las exportaciones de datos de tickets, usuarios y organizaciones son globales y tienen efecto en toda la cuenta. Sin embargo, se puede usar la Core API de Zendesk para extraer datos más específicos.
  
  
• Etiquetas
  En una instancia que cuenta con varios equipos, no es recomendable reciclar las etiquetas para varios flujos de trabajo o recursos.

Reglas de negocio

Esta sección describe las consideraciones para las reglas de negocio.

• Disparadores, automatizaciones, vistas y SLA
  • Las reglas de negocio se ejecutan en todos los tickets, sin embargo, se pueden utilizar condiciones para restringir su aplicación a determinado grupo de tickets o marca. Consulte Usar grupos en reglas de negocio. Los administradores tienen alcance global y pueden crear reglas para grupos ajenos a los administrados por ellos mismos. Esta facultad da lugar a que un administrador de un grupo pueda editar las reglas que afectan los tickets y los flujos de trabajo de otro equipo. 
  • Si se utilizan distintos equipos dentro de una misma instancia de Zendesk, habrá una cantidad cada vez mayor de reglas que administrar. La complejidad creciente requiere una estrategia para la administración de los cambios y una colaboración constante entre todos los equipos. Asimismo, existe un mayor riesgo de que los tickets se desvíen incorrectamente a un grupo que no les corresponde, lo cual puede tener repercusiones en los SLA.
  • También se tendrá que tomar en cuenta que la información confidencial o delicada puede llegar a ser visible a agentes que no están supuestos a tener acceso a ella. No existe un método nativo para organizar las reglas de negocio por grupo.
  • Algo que puede ayudar con la organización/agrupación de las reglas de negocio, es la creación de disparadores o automatizaciones creados con el único propósito de manejar un nombre destinado a crear la experiencia de categorización de reglas por equipo.
    
    
• Macros
  El acceso a las macros se puede configurar para todos los agentes o para los agentes en grupos. Consulte Crear macros personales para tickets si desea más información.
  
  
• Campos de ticket y formularios de ticket
  • Los campos de ticket y los formularios de ticket se aplican globalmente a la instancia. Todos los equipos pueden ver todos los formularios y campos. Los formularios de ticket personalizados son necesarios para poder contar con formularios únicos para los distintos equipos y las distintas experiencias de usuario final.
  • En la interfaz de agente, una aplicación personalizada podría ocultar o mostrar determinados campos según qué agente esté viendo el ticket. También se podría utilizar la receta que se presenta en el artículo sobre cómo restringir formularios de ticket.
  • Las personalizaciones del código del centro de ayuda pueden ocultar los campos de usuarios finales editables y no requeridos para que no aparezcan en el formulario de solicitud.

Integraciones

Esta sección describe las consideraciones para las integraciones.

• JIRA
  La versión 3 de la integración de Zendesk con JIRA se realiza de uno a uno. Es decir, no es posible vincular varias integraciones JIRA a una cuenta de Zendesk Support.
  
  
• Integraciones personalizadas
  Varias instancias de Support requieren la configuración de cada integración personalizada. Por ejemplo, si se efectúan exportaciones de datos o se establece una conexión a una base de datos de usuarios es necesario realizar la configuración en ambos lados de cada instancia de Support.
  
  
• Aplicaciones (ZAF)
  Las aplicaciones deberán instalarse y configurarse en cada instancia de Support. Si las opciones nativas no satisfacen sus necesidades particulares, puede codificar una aplicación personalizada para verificar el grupo de usuarios y ocultar o mostrar la aplicación. Es posible especificar el acceso a las aplicaciones por grupo o por rol personalizado de forma nativa. Consulte Restricting the visibility of an app by group.

Autenticación y acceso

Esta sección describe las consideraciones para la autenticación y el acceso.

• Autenticación básica
  Cuando se cuenta con varias instancias de Zendesk, los inicios de sesión (nombre de usuario y contraseñas) son únicos para cada instancia. Los agentes y usuarios finales tendrían que administrar y recordar dos juegos de credenciales para varias instancias de Zendesk que utilizan la autenticación nativa de Zendesk.
  
  
• Acceso con API
  Los tokens de API son globales, lo cual quiere decir que cualquier usuario con un token de API puede tener acceso a todos los recursos y datos de la cuenta.
  
  
• OAuth
  Los tokens de OAuth se pueden limitar para que el acceso quede restringido a determinados recursos únicamente. Sin embargo, los tokens no pueden ser limitados a grupos de agentes.
  
  
• Inicio de sesión único (SSO)
  • El SSO nativo se aplica a toda la instancia tanto para la configuración del agente como la del usuario final. Los agentes y los usuarios finales de todos los equipos deben configurarse en el proveedor de identidad de SSO.
  • Los usuarios pueden utilizar distintos métodos de autenticación (autorización Zendesk y SSO) para resolver esta limitación, pero es algo que debe hacerse del lado del cliente. Consulte el artículo en inglés Having the talk: Am I ready for a more advanced authentication option?

Administración de usuarios finales

Esta sección describe las consideraciones para la administración de usuarios.

• Campos de usuario y organización
  Los campos de usuario y organización son globales para toda la instancia, lo cual quiere decir que todos los agentes pueden verlos y, posiblemente, editarlos. Al igual que con los campos de ticket, la aplicación personalizada puede ocultar o mostrar determinados campos de usuario/organización según el agente que los esté viendo.
  
  
• Administración de las organizaciones
  • Las organizaciones son globales para toda la instancia. Algo que no se puede hacer es segmentar las organizaciones o los permisos de visualización de las organizaciones por grupos de agentes.
  • Cuando se usa la función para compartir tickets dentro de la organización, los permisos de acceso son globales para todos los tickets en una organización. Si se activa esta opción, se ven afectados los tickets de todos los equipos que usan Support y Guide.
  • Los nombres de las organizaciones deben ser únicos. Si bien es posible que los usuarios pertenezcan a varias organizaciones, no es posible tener dos organizaciones con el mismo nombre para dar cabida a varios equipos.
    
    
• Permisos y acceso de los usuarios finales
  • Todos los usuarios finales son globales en toda la instancia. Esto quiere decir que no es posible permitir que un usuario final envíe solicitudes a un equipo en una instancia, pero no permitir que envíe solicitudes a otro.
  • De manera nativa, solo se admite un método principal de autenticación de usuarios finales. Los usuarios finales pueden iniciar sesión en todas las instancias del centro de ayuda. Existen flujos de trabajo que eluden el comportamiento anterior, pero son muy personalizados y requieren cierto grado de programación del lado del cliente. 

Permisos de agentes y acceso a los tickets

• Permisos de agentes para editar usuarios finales
  Existen varias consideraciones según el tipo de plan:
  • Roles de agente personalizados: si su tipo de plan incluye roles personalizados, puede permitir a un grupo de agentes editar los perfiles de usuarios finales, pero no a otro. Los agentes pueden ver el perfil de usuario de todos los usuarios finales. Sin embargo, se pueden dar casos de configuración límite en los que un agente no tiene acceso a un ticket en otro grupo, pero sí tiene acceso para editar los usuarios finales. Esto incluye la adopción de identidad de usuarios finales cuando el agente puede ver TODOS los tickets que el usuario final ha solicitado.
  • Rol de agente: en los tipos de planes que no cuentan con roles de agente personalizados, solo los agentes con acceso a todos los tickets pueden agregar, editar o adoptar la identidad de usuarios finales.
  • Casos de uso especial en los que los agentes de un equipo son considerados usuarios finales de otro equipo: los agentes no pueden enviar tickets mediante el centro de ayuda y, debido a eso, los formularios de usuarios finales no funcionarán para los agentes. Independientemente de los permisos de grupos, los agentes tienen acceso a los tickets en los que ellos son los solicitantes, lo cual quiere decir que pueden acceder a cualquier comunicación interna que tenga que ver con el solicitante.
    
    
• Administración de grupos y acceso a los tickets
  • Los grupos son globales para toda la instancia. Se pueden crear grupos para administrar varios equipos y restringir el acceso a los tickets según el grupo.
  • En los planes Enterprise, se pueden crear grupos de tickets privados. Los grupos de tickets privados dan un control más preciso sobre la visibilidad y el acceso a los tickets en función de la asignación de grupo porque ocultan completamente los tickets privados para los agentes que no tienen permiso para verlos.
  • También en los planes Enterprise, se pueden usar los roles de agente personalizados para controlar el acceso de los agentes a los grupos de ticket privados, lo que incluye su capacidad de asignar tickets a grupos privados.

Informes

Esta sección describe las consideraciones para los informes.

• Informes
  
  • Si se utiliza una instancia, los informes están centralizados. Todos los datos de tickets, usuarios y organizaciones están a disposición de todos los usuarios que tengan acceso a los informes.
  • En los distintos planes, el acceso a los tickets controla el acceso a los informes. Los agentes deben tener acceso a todos los tickets para poder ver los informes.
  • Los paneles predeterminados de los informes son globales para todos los datos de Support. Esto significa que para tener informes desglosados por grupo o por cualquier otro atributo a nivel de ticket (campo de ticket personalizado, marca del ticket, etc.) es necesario personalizarlos.
    
    
• Informes nativos
  Los informes nativos (no los de Explore) como Información general, Tabla de marcadores, Base de conocimientos, Comunidad, Búsqueda y Talk son análisis globales que se aplican a toda la instancia.

Web Widget (clásico) y widget de Chat

Esta sección describe las consideraciones para el Web Widget (clásico) y el widget de Chat. Es posible que no se apliquen a la mensajería del Web Widget.

• Las personalizaciones nativas y el aspecto (color, posición, texto del botón) son globales. Es posible utilizar la API del Web Widget para personalizar el widget por equipo, pero esto requiere programación personalizada.
• Se necesitarán formularios de ticket para poder personalizar la experiencia del formulario/campo de acuerdo a cada equipo.
• La búsqueda del centro de ayuda realiza una búsqueda con el widget en toda la base de conocimientos, pero solo en una base de conocimientos. Sin embargo, con algo de programación personalizada, quizás pueda ajustar los resultados de la búsqueda.
• Chat puede estar activado o desactivado para el widget, lo que puede tener consecuencias si solo un equipo utiliza Chat. Esta configuración se puede modificar personalizando la API del Widget y la API de Chat.

Guide

Esta sección describe las consideraciones para Guide.

• Permisos para los agentes
  • Si varios equipos están utilizando una sola instancia de Guide, será necesario contar con una estrategia de colaboración. Por ejemplo, los agentes de un equipo que también son gerentes podrán administrar contenido y editar temas para otros equipos, incluso si se está usando la función de multimarca.
  • Los permisos para editar y crear artículos son una mezcla de la configuración de Support y la configuración a nivel de sección de Guide. Los administradores de Zendesk Support son administradores de Guide de manera predeterminada.
  • Si tiene un tipo de plan que incluye roles personalizados, podrá crear un rol personalizado y establecer el permiso de administrador de Guide. Si tiene otro plan, podrá controlar quién es administrador o visualizador de Guide en la página de perfil del agente. Consulte Comprender los roles de Guide y cómo otorgar permisos.
  • Los agentes se pueden establecer como visualizadores en Support, y aun así pueden crear y editar artículos en todas las secciones que los permisos a nivel de sección han establecido para administradores y agentes.

• Experiencia de usuarios finales
  • Si se está usando una sola instancia de Zendesk, todos los usuarios finales podrán iniciar sesión en todos los centros de ayuda. Si hay usuarios finales en común cuando varios equipos usan la misma instancia de Zendesk Support para la gestión de tickets, los usuarios finales tendrán un único juego de credenciales para iniciar sesión, y no varios como cuando los equipos utilizan distintas instancias de Support.
  • Los usuarios finales podrán ver todos los tickets en un solo lugar si se utiliza una sola instancia de Support, siempre y cuando los tickets no pertenezcan a distintas marcas.
  • Los segmentos de usuarios y la estrategia de permisos son imprescindibles para poder administrar quién puede ver qué contenido para todos los centros de ayuda asociados con una instancia de Support.
  • Por último, si los agentes que pertenecen a un equipo son usuarios finales en otro equipo, su experiencia con el centro de ayuda se verá menoscabada. A la hora de enviar y ver solicitudes de asistencia, se les enviará a Support.

Cuestiones de alcance

Antes de tomar la decisión final, considere las siguientes cuestiones de alcance:

¿Deberían todos los agentes tener acceso a todos los tickets?

Si está usando una instancia de Support con varios equipos, es aconsejable que tome en cuenta las siguientes consideraciones para permitir o denegar el acceso a todos los tickets.

Permitir el acceso a todos los tickets:

• Si los agentes pueden acceder a todos los tickets, ¿qué tan complejo o ampliable sería configurar y separar el desvío de tickets por medio de reglas de negocio (vistas, disparadores, automatizaciones, SLA, plantillas de correo electrónico) para cada equipo, puesto que las reglas de negocio se aplican globalmente en toda la instancia? 
• Por ejemplo, si dos equipos distintos (el de soporte y el de ventas) utilizan una instancia de Zendesk, se necesita un disparador de desvío para cada equipo (así como distintos disparadores para cada actualización de respuesta automática/comentario) a fin de personalizar la experiencia de los usuarios finales para cada equipo.
• Riesgo mayor de que un ticket sea desviado incorrectamente en términos de los SLA.

No permitir el acceso a todos los tickets:

• Se requiere la configuración de grupos o roles personalizados para restringir el acceso.
• Es imprescindible tener una administración cuidadosa del desvío de tickets para evitar que los tickets sean desviados accidentalmente a un grupo que no está supuesto a tener acceso al ticket.
• Limita la visibilidad para los agentes en otras solicitudes históricas o vigentes. La restricción de acceso a los tickets también puede restringir el acceso de los agentes a los informes.
• Según la configuración, si los agentes restringidos tienen la capacidad de adoptar la identidad de usuarios finales, se puede decir que también tendrían acceso a los tickets fuera de su grupo desde Mis actividades en el centro de ayuda.

¿Existe una estrategia centralizada para la administración de usuarios?

Estos son los puntos que se deben tener en cuenta con respecto a agentes y usuarios:

• En términos de la autenticación de Zendesk, los usuarios que son agentes en ambas instancias tendrían que tener dos juegos de credenciales.
• Si se está usando SSO, Zendesk deberá configurarse como proveedor de servicios para ambas instancias. Si está transfiriendo datos de usuario personalizados, tendrá que crear campos de usuario y de organización en ambas instancias. Todos los campos de usuario personalizados, las organizaciones y los roles tienen ID únicas, que requieren la configuración de aserciones SAML/JWT únicas.

Otras cuestiones que se deben tener en cuenta para los usuarios finales:

• ¿Deberían los usuarios finales tener acceso al contenido del centro de ayuda para ambos equipos (por ejemplo, tanto para uso de RRHH como de soporte) en una sola instancia?
• ¿Deberían los usuarios finales tener acceso a todo el contenido de RRHH y de soporte?  

Resumen

La que sigue es una sinopsis de las ventajas y consideraciones que se deben tener en cuenta a la hora de decidir entre una o varias instancias:

Si opta por una instancia de Zendesk Support, las ventajas son las siguientes:

• Una experiencia unificada para todos los clientes.
• Informes unificados.
• Costo de los agentes: solo se necesita una licencia para los agentes de ambos equipos.
• Derivar o dar seguimiento a los asuntos en los departamento es más fácil dentro de una instancia de Support.
• Administración y autenticación de usuarios unificadas:
• Una sola fuente de datos fiable para todos los usuarios.
• Una perspectiva completa de cada cliente.

Otros aspectos que se deben tener en cuenta:

• En algunos tipos de planes, la restricción del acceso a los tickets es compleja.
• La experiencia de los agentes que también son usuarios finales en otros equipos se ve menoscabada.
• Se hacen necesarios un proceso y una estrategia de administración de cambios bien definidos.
• Mayor complejidad en el desvío de tickets y las reglas de negocio.
• Muchas de las funciones personalizables de Support se configuran globalmente (como la autenticación, la plantilla de correo electrónico, el nombre de cuenta o los correos de bienvenida).

Si opta por varias instancias de Zendesk Support, las ventajas son las siguientes:

• La compartimentación es más fácil.
• Hay flexibilidad para hacer cambios sin el riesgo de afectar a otros equipos.
• Flujos de trabajo independientes y plenamente personalizables de Nivel 0/autoservicio y de conocimiento (KCS, Answer Bot, Publicación en equipo).
• Experiencia de usuarios finales plenamente personalizable y adaptada por equipo (experiencia del usuario final apropiada para los agentes que son también usuarios finales en otros equipos).
• Control por equipo del acceso a los tickets y la seguridad.

Otros aspectos que se deben tener en cuenta:

• Los gastos de configuración y análisis para varias instancias.

• Se requiere configuración del SSO, las aplicaciones y las integraciones para todas las instancias.

• Los usuarios finales deben recurrir a distintos lugares para enviar sus solicitudes de asistencia o en busca de autoservicio.

• La complejidad de la colaboración entre los agentes aumenta debido a que se tienen que compartir tickets entre las instancias de Support.

• La función para evitar el conflicto entre agentes no funciona entre dos instancias de Support.

• Si bien la función para compartir tickets permite la colaboración de dos equipos que utilizan Zendesk, las actualizaciones de tickets son asíncronas de una instancia de Support con respecto a la otra.

• En algunos tipos de planes, el control del acceso a los tickets y la seguridad por equipo se puede conseguir en una instancia única mediante la creación de grupos de tickets privados.