Contenido

Introducción a Dynamics 365 Customer Service........................................................................... 3

Componentes principales de Customer Service ........................................................................... 6
Comprender el recorrido del cliente moderno ............................................................................. 8
Información general sobre la administración de casos .............................................................. 10
Creación y ciclo de vida de los casos ........................................................................................... 11
Consideraciones para automatizar la creación de casos........................................................... 15
Escenarios de administración de casos ....................................................................................... 20
Escenarios de paneles de administración de casos .................................................................... 21
Trabajar con transiciones de razones para el estado.................................................................. 27
CREAR UNA COLA DE DYNAMICS 365 .............................................................................................. 30
Conjuntos de reglas de enrutamiento ........................................................................................ 32
Información general sobre los acuerdos de nivel de servicio (SLA) ............................................ 34
Cierres de empresa y horas laborables ....................................................................................... 37
Crear acuerdos de nivel de servicio (SLA) ................................................................................... 40
Administrar los acuerdos de nivel de servicio (SLA) ................................................................... 47
Información general sobre la administración del conocimiento ................................................ 49
Introducción a Dynamics 365 Customer Service

El servicio al cliente es un aspecto clave en la estrategia de interacción con el cliente de una

organización. La percepción que tienen sus clientes de usted a menudo está directamente
relacionada con el servicio que les brinda. Como organización, es importante que averigüe
cuáles son las expectativas de los clientes y que comprenda lo que ellos consideran un buen
servicio al cliente. Una vez que comprenda mejor lo que esperan sus clientes, podrá
implementar de manera más eficaz una estrategia para atenderlos a todos ellos. Dynamics
365 Customer Service cuenta con muchas características que las organizaciones pueden usar
para gestionar los servicios que proporcionan a sus clientes.

Información general sobre la situación del servicio al cliente

Para ayudar a comprender mejor el contexto del servicio al cliente, vamos a revisar algunos
escenarios de clientes reales.

Abordar y resolver problemas de clientes o productos: un cliente de una tienda de bicicletas

local descubrió recientemente que la suspensión de su bicicleta de montaña está defectuosa y
no funciona correctamente. Se pone en contacto con la tienda para comentar el problema y
obtener ayuda con su bici. Se abre una incidencia y se envía a la cola de solicitudes de
asistencia para bicicletas de montaña de la organización.

Rob, el especialista de soporte de bicicletas de montaña de la tienda, recibe la incidencia a

través de Dynamics 365 Customer Service. Después de hablar con el cliente, programa una
actividad de servicio con el fin de reparar o sustituir la suspensión defectuosa.

Recibir y responder preguntas de los clientes: un cliente compró recientemente una mesa
nueva en el sitio web de una tienda de muebles. Una vez que llega la mesa, el cliente intenta
montarla, pero no está seguro de estar haciéndolo correctamente. Contacta con la empresa de
muebles para preguntarles y obtener ayuda con la mesa.

Sidney, un especialista de atención al cliente, recibe las preguntas del cliente. Usa la
knowledge base de Dynamics 365 Customer Service para encontrar un documento de las
preguntas más frecuentes referente a la mesa. A continuación, usa dicho documento para
ayudar a responder las preguntas de Jim.

Recopilar y aplicar los comentarios de los clientes: María, gerente de producto para mesas y
sillas en la empresa de muebles, desea recopilar comentarios relacionados con el proceso de
montaje en el hogar cuando los clientes se comunican con el departamento de soporte.
Aprovecha la funcionalidad de administración de casos de Dynamics 365 Customer Service
para capturar estos comentarios. Al analizar los datos del caso, puede identificar las mesas y
las sillas que causan más problemas durante el montaje en casa, así como los modelos que son
más fáciles montar. Además, Maria puede determinar qué instrucciones para el montaje en
casa de mesas y sillas se deben priorizar para editarlas y revisarlas.

Soporte proactivo: un cliente compró recientemente un sistema de supervisión del hogar

completo de una empresa de seguridad regional. Además de las cámaras de seguridad, el
sistema incluía sensores de seguridad, humo y humedad junto con otros dispositivos
inteligentes. Durante la noche, uno de los sensores de humedad ubicados en el sótano de los
clientes se enciende. Se desencadena una alerta que crea y escala automáticamente un
problema de soporte en Dynamics 365 Customer Service.

Jennifer, una experta en protección del hogar, recibe la incidencia e inicia una llamada de
investigación para verificarla con el cliente. El cliente indica que se le está inundando el sótano.
Puede identificar que la bomba de sumidero del cliente no funciona. Dado que el cliente tiene
una bomba de reserva, desconecta la bomba vieja y conecta la nueva. El agua en el sótano
desaparece antes de que cause daños.

Comprender al cliente actual

Con la información y las plataformas disponibles, los clientes de hoy están más informados que
nunca. Están acostumbrados a obtener lo que desean, cuando lo desean y del modo en el que
lo desean.

Pensemos en el proceso típico de compra de una televisión:

1. Antes de comenzar el proceso, es probable que investigue un poco en Internet para

identificar información importante como nuevas funciones y tecnología, puntuaciones
de satisfacción del cliente y las mejores marcas.

2. Es probable que revise las opiniones de los clientes y determine qué televisor cree que
es mejor antes de visitar el sitio web del minorista donde lo va a comprar.

3. Mientras esté en el sitio, puede seleccionar varios televisores y hacer una comparación
en paralelo.

4. Si tiene preguntas, puede usar la opción de chat para interactuar con alguien.

5. Si aún no está seguro, puede visitar la tienda física, donde puede comunicarse con un
representante de ventas. Ya sabe lo que busca, pero ahora puede mirar el televisor
con sus propios ojos y tocarlo.

El mismo proceso se puede aplicar a diferentes experiencias. Los clientes quieren tener el
control de la experiencia. Cada vez más clientes prefieren poca o ninguna interferencia a
medida que avanzan en el proceso. Desean saber que alguien está allí si es necesario, pero
también flexibilidad para impulsar su propia experiencia de interacción con personas en
directo a su elección.

Tendencias que influyen en el servicio al cliente

Existen muchas tendencias que afectan a cómo se ofrece el servicio al cliente hoy en día. Como
organización de servicios, es importante que comprenda cuáles son esas tendencias y cómo
puede aprovecharlas para mejorar y controlar la experiencia del cliente.

Estas son alguna de las tendencias que influyen en el servicio actualmente:

 Dispositivos móviles: Con tantos dispositivos móviles disponibles en la actualidad, la

gente ya no se relaciona con el servicio al cliente únicamente a través de una llamada
telefónica o de un correo electrónico. Desean poder tener acceso a información de un
portal en sus dispositivos móviles o interaccionar con un agente en un chat que inicien
ellos en sus dispositivos.

 Medios sociales: Las personas no suelen ser tímidas cuando se trata de expresar sus
ideas y opiniones en medios sociales. Debe poder aprovechar esta plataforma para
asegurarse de que los problemas o las quejas de los clientes se gestionan de la misma
forma que si el cliente interaccionara directamente con el soporte técnico.

 Autoservicio: El autoservicio puede significar cosas distintas:

o Puede ser algo tan sencillo como proporcionar una Knowledge Base que los
clientes puedan utilizar para buscar respuestas a preguntas de procedimiento
simples.

o Puede implicar dejar que los clientes administren sus cuentas.

o A veces puede significar proporcionar a los clientes una forma de interaccionar

con otros clientes que se encuentren en la misma situación.

 Internet de las cosas: Cada vez hay más dispositivos conectados a Internet y que se
comunican unos con otros, por lo que importante aprovechar la tecnología usada en
estos dispositivos para la interacción en las llamadas de servicio. Estas son algunas de
las maneras en que puede hacerse:

o Detección de anomalías

o Mantenimiento predictivo

o Usar los datos recopilados para ayudar a controlar las ofertas de servicio en el
futuro

 Interacción con el cliente: La interacción es algo más que comunicarse para recabar las
opiniones de los clientes. Puede incluir conocer estos detalles:

o ¿Cuándo es el momento adecuado para la interacción?

o ¿Qué canales deben usarse?

o ¿Qué información se debe recopilar?

Componentes principales de Customer Service
Ahora vamos a analizar los tipos de registros básicos que se usan para la administración del
servicio.

TIPOS DE REGISTROS

Registros de cliente: en Dynamics 365 Customer Service, las solicitudes del servicio de
atención al cliente generalmente se administran en relación con un registro de contacto o de
cuenta existente. Estos contactos y cuentas también los usan otras áreas de las operaciones
comerciales, como las ventas o el marketing.

 Un contacto representa a una persona, al igual que en Outlook.

 Una cuenta representa a una empresa, una organización o un grupo de personas.

Aunque estos son los usos habituales de las cuentas y los contactos, distintas
implementaciones de Customer Service pueden usar estos tipos de registro de manera
diferente. Pero a ambos se hace referencia habitualmente como clientes. Por ejemplo, al
introducir el cliente en un caso, puede seleccionar una cuenta o un contacto.

Casos: Los casos son el tipo de registro fundamental en la administración del servicio y
representan un único incidente de cualquier servicio solicitado. Distintas organizaciones
pueden usar distintos términos para referirse a los casos: incidentes, vales, solicitudes de
servicio, etc.

Dicho de otro modo, los casos son cualquier cosa en el contexto de una interacción con un
cliente que requiera algún tipo de resolución o de respuesta. Es posible que haya muchos
casos asociados con un único registro de cliente a la vez. En Customer Service, los
representantes del servicio al cliente pueden ver los casos abiertos y resueltos desde el
registro del cliente.

Actividades: Las interacciones entre una empresa y sus clientes que se consideran
suficientemente importantes como para realizar su seguimiento en Customer Service se
conocen como actividades. Las actividades pueden estar asociadas con varios tipos de
registros en Customer Service. Puede abrir el registro y buscar las actividades en Actividades
cerradas o Actividades abiertas.

 Las actividades cerradas son las que se han marcado como completadas.

 Las actividades abiertas o bien no se han marcado como completadas o bien están a la
espera de completarse en una fecha y hora distintas.

Derechos: Los derechos se pueden usar para especificar a cuántos servicios de soporte técnico
tiene derecho un cliente. Por ejemplo, el derecho de un cliente en Customer Service podría
asignar diez casos de soporte técnico que el cliente puede usar cuando desee.

Canales de derecho: los canales de derecho se pueden usar para especificar el tipo de servicio
al que tiene derecho un cliente. Originalmente, hay seis canales de derechos:

 Teléfono

 Correo

 Web
  Facebook

 Twitter

 IoT

Artículos de Knowledge Base: la Knowledge Base de Customer Service es un repositorio de

artículos informativos que ayudan a los representantes del servicio al cliente a resolver casos.
En algunas organizaciones, la información de la knowledge base ayuda a los empleados no solo
a resolver problemas sino también a realizar preguntas de seguimiento.

Normalmente esta información es sobre la empresa, preguntas y respuestas sobre el producto

y cualquier otro tipo de información que pueda ayudar los empleados a gestionar mejor las
consultas, las solicitudes o los problemas del cliente.

Actividades de resolución: Una vez que todas las actividades de un caso se han resuelto, es
posible resolver el propio caso. Después de resolver el caso, se crea una actividad del
tipo Actividad de resolución. Esta actividad se encuentra en las actividades cerradas asociadas
con un caso. Las actividades de resolución muestran la resolución del caso y el tiempo
empleado en el caso.

Colas: Una cola es un lugar para organizar y almacenar actividades y casos que esperan a ser
procesados.

Por ejemplo, una organización podría tener un equipo de soporte técnico con la dirección de
correo electrónico [email protected]. Si el equipo de soporte técnico recibe un mensaje
de correo electrónico enviado a esta dirección, un miembro del equipo gestiona el caso de
soporte técnico y trabaja para resolver el problema para el cliente.

Las colas en Dynamics Customer Service funcionan de la misma manera.

Productos: los productos del Catálogo de productos de Dynamics CRM pueden estar
relacionados con un caso del servicio al cliente. Por lo tanto, puede ayudar a proporcionar una
visión más detallada de los casos, las resoluciones y los comentarios de los clientes en el nivel
de un producto.

Aunque los productos se pueden asociar con casos para categorizar mejor los tipos de casos,
esta asociación no tendrá ninguna influencia sobre los precios ni la facturación. Además, el uso
de productos junto con casos es opcional y es posible que no sea aplicable a todas las
organizaciones.

Objetivos: Además de realizar informes sobre la información de Customer Service y analizarla,

las organizaciones pueden usar las características de la Administración de objetivo para
establecer y realizar el seguimiento del progreso en comparación con valores de destino de
indicadores clave de rendimiento (KPI). Para la administración del servicio, estos KPI pueden
incluir métricas como los casos resueltos o los casos en curso.

Contratos de nivel de servicio: Los contratos de nivel de servicio (SLA) son una forma de
realizar el seguimiento y definir qué debe suceder cuando se abre un caso. Puede realizar el
seguimiento de cosas como cuándo aceptó un caso por primera vez un representante del
soporte técnico y cuánto tiempo tardó en resolverse el caso. También puede enviar mensajes
de correo electrónico basados en escalas de tiempo de advertencias y errores.
Comprender el recorrido del cliente moderno
Desde hace entre cinco y diez años, el servicio ha cambiado drásticamente. En el pasado, un
cliente llamaba y se le ponía en espera hasta que alguien se ponía al teléfono para ayudar. En
la actualidad el contexto del soporte técnico es muy diferente.

El cliente actual puede iniciar un recorrido de soporte técnico desde múltiples puntos de
partida. Los clientes tienen diferentes preferencias de canal y esperan una experiencia sin
esfuerzo en todos los canales.

Con la llegada de las funcionalidades de autoservicio, los clientes pueden empezar a aprender
por sí mismos usando cualquiera de estos recursos:

 Portales con un bot interactivo

 Capacidad de chat en directo

 Comunicación SMS

 Quioscos interactivos

 Una aplicación móvil implementada por la organización del cliente

 Uso compartido remoto de pantallas entre un agente de servicio y el cliente

 Distintas redes sociales, incluidas Facebook y Twitter

Como muestra esta lista, nunca podemos saber con certeza de dónde viene el cliente. Por lo
tanto, debemos estar preparados, con todos los canales y medios posibles abiertos y a la
escucha.
La perspectiva y las expectativas del cliente

No es suficiente con tener varios canales distintos. Su organización de servicios debe estar
integrada, de modo que:

 Todos los canales de soporte técnico tengan la misma información. No desea que los
consejos que proporcionen sus bots sean diferentes de los que daría un representante
del servicio al cliente.

 Los canales estén conectados de forma directa. Desea que la información pueda pasar
fácilmente de un canal a otro.

La complejidad no termina aquí. En general, una empresa de servicios moderna debe tener en
cuenta lo siguiente:

 Medios sociales: Los clientes son muy activos en los medios sociales. No solo dejan
comentarios sobre aquello que les gusta. También comentarán, y de forma muy
intensa, lo que no les gusta. Además, muchos de sus amigos —sus clientes
potenciales— escuchan estos comentarios y se forman sus propias opiniones sobre su
empresa.

 Tamaño de la empresa: A menudo las empresas desean dirigirse a clientes pequeños y

empresariales mediante el mismo conjunto de canales.

 Soporte técnico para clientes con contrato y sin contrato: Todo el mundo recibe
soporte técnico, no solo aquellos con contratos de nivel de servicio (SLA). Una vez más,
no sabe de dónde proceden los nuevos clientes.

 Tiempos de respuesta rápidos: Los clientes esperan tiempos de respuesta rápidos. Si

no puede dars una respuesta a tiempo, se irán a otra parte, puede que incluso a la
competencia, que tal vez disponga de un canal de soporte técnico mejor.

 Soporte técnico in situ: A veces no es posible ayudar a los clientes en línea. En este
caso, a menudo esperan que la empresa de servicios los visite en su lugar de trabajo o
sobre el terreno para resolver un problema.
RECORRIDO DEL CLIENTE TÍPICO

El cliente típico seguirá una ruta específica para conseguir resolver un problema:

1. Autoayuda: Cuando la gente necesita ayuda, en primer lugar va a Internet e intenta

solucionar el problema por sí misma. Visitarán algunos foros y grupos de noticias y
harán algunas preguntas, esperando una solución rápida. Puede que visiten el sitio
web de la empresa e investiguen un poco mientras buscan en la documentación.

2. Creación inicial del caso y enrutamiento: Los casos se generarán desde varios canales.
Luego pueden dirigirse a colas específicas, en función de factores como si hay un
contrato, si el cliente es un cliente preferido o si un técnico apto para gestionar el
problema está disponible en una cola específica.

3. Administración y resolución del caso: Ahora un agente de servicio realizará el

seguimiento de toda la comunicación con el cliente y seguirá un proceso dedicado de
resolución del caso mientras usa una knowledge base interna. En este punto, la
comunicación con el cliente puede realizarse por correo electrónico, mensajes de
texto o una llamada de teléfono. Normalmente se realiza un seguimiento de los casos
para crear un registro histórico de qué ha sucedido con el cliente. También se ampliará
la Knowledge Base, de modo que otros representantes del servicio al cliente puedan
aprovechar el conocimiento de casos anteriores.

4. Actividades tras el caso: las organizaciones de servicio al cliente prestan cada vez más
atención a lo que hacen después de la resolución de un caso. Ahora estas actividades
tras el caso se consideran vitales. En la actualidad las empresas desean obtener
comentarios de los clientes acerca de la calidad de la interacción, como una forma de
mantener los canales abiertos y fomentar que el cliente se quede con la empresa. Para
obtener más ideas del caso y ampliar su knowledge base, las empresas pueden enviar
a los clientes una encuesta con aspectos específicos del caso.

En el mundo moderno, este es el modo habitual en el que los clientes interactúan con una
organización de soporte técnico de una empresa.

Información general sobre la administración de casos

D365 for Customer Service ofrece un completo conjunto de características relacionadas con la
administración de casos, para ayudar a las organizaciones a prestar servicio a sus clientes de
varias formas, en función de las necesidades de los clientes, del modelo de servicio de la
organización y de otros factores.

Antes de que comience, vamos a estudiar los casos con más detalle.

¿QUÉ ES UN CASO?

Un caso suele representar una situación o un incidente que un cliente notifica y requiere una
solución. Los casos se han diseñado para seguir el proceso desde la entrada inicial de un
incidente hasta su resolución definitiva, pasando por el proceso de corrección del problema.
Desde el punto de vista del servicio al cliente, un caso puede representar varios elementos. A
continuación, encontrará algunos ejemplos comunes:

 Preguntas: el cliente puede tener una duda concreta sobre un producto o servicio. Por
ejemplo, un cliente se pone en contacto con un agente de soporte para pedir
 información sobre la póliza de seguros de la organización, como los importes
deducibles o de la prestación.

 Solicitudes: el cliente puede realizar una petición concreta, como solicitar más
información o que se lleve a cabo cierto tipo de acción. Por ejemplo, un cliente se
pone en contacto con una organización para solicitar que alguien acuda a realizar una
inspección de un bien inmobiliario.

 Problema: el cliente puede tener un problema que necesite corregir, como una
reclamación de garantía, una objeción a una factura o un defecto de un producto. Por
ejemplo, una clienta se pone en contacto con un centro de soporte por un error de
facturación de su plan de datos móviles.

Customer Service presenta varios componentes que funcionan juntos para proporcionar una
solución integral de administración de casos. Esta no se limita a identificar los casos, sino que
también enruta cada uno de ellos al agente más apropiado para que aporte orientación al
respecto y lo resuelva. A continuación, describimos algunos de los componentes más usados:

 Casos: un caso representa un incidente de servicio individual. Dicho de otro modo,

representa cualquier cosa, en el contexto de una interacción con un cliente, que
requiera algún tipo de resolución o de respuesta. Puede haber varios casos asociados a
un único de cliente en cualquier momento dado.

 Actividades: una actividad suele representar una interacción con un cliente, como una
llamada de teléfono. Puede haber varias actividades a un solo caso.

 Derechos: los derechos especifican la cantidad de servicios de soporte que

corresponden a un cliente. Puede considerarlos contratos de soporte.

 Artículos de conocimientos: la knowledge base es un repositorio de artículos

informativos que ayudan a los representantes del servicio al cliente a resolver los
casos.

 Colas: una cola es un lugar donde se organizan y almacenan las actividades y los casos
que esperan a ser procesados.

 Contratos de nivel de servicio (SLA): los SLA son una manera de seguir y definir lo que
sucede al abrir un caso, como el tiempo que deberá tardarse en responder a un
cliente.

 Reglas de creación y actualización de registros: estas reglas se pueden aplicar a

distintos tipos de actividades para crear registros de Dynamics 365 automáticamente.

 Reglas de enrutamiento: estas reglas se aplican a los casos para enrutarlos

automáticamente a una cola o un usuario en particular.

 Flujos de proceso de negocio: un flujo de proceso de negocio representa un proceso

guiado que consta de varias fases y pasos aplicados a resolver un elemento concreto,
como un caso.

Creación y ciclo de vida de los casos

Los casos pueden crearse de varias formas en Dynamics 365, para tener en cuenta los
distintos escenarios de recepción de casos de la organización. Por ejemplo, los casos se
pueden crear automáticamente, a partir de una interacción con los medios sociales, o bien los
pueden crear los agentes manualmente al atender una llamada de un cliente. Incluso se
pueden crear a través de un portal de autoservicio. Al implementar una estrategia de
administración de casos, es importante tener en cuenta todos los escenarios en los que la
organización puede prestar soporte.

En Dynamics 365, los casos se pueden capturar e introducir en el sistema de varias formas,
según los requisitos específicos de la organización (por ejemplo, a través de un portal de
autoservicio). Sin embargo, lo más habitual es crear los casos manualmente o convirtiendo una
actividad.

CREACIÓN MANUAL DE CASOS

En muchas ocasiones, un agente de servicio debe introducir manualmente los casos. Al

introducir el caso, el agente captura la información pertinente, como el cliente, el punto de
contacto, el problema, etc. Hay dos maneras principales de crear casos manualmente.

Página Caso

La página Caso es el método más usado para introducir los casos en Dynamics 365. Al
introducir el caso, el agente especifica los detalles sobre el caso, como su título, cliente, origen,
etc.

La página Caso contiene todos los campos que están disponibles para el caso y proporciona
acceso rápido a los registros relacionados, como los artículos de conocimientos. La
página Caso también proporciona acceso al flujo de proceso de negocio activo que el caso
utiliza. Muchos elementos (por ejemplo, la escala de tiempo) y el acceso a los registros
relacionados no están disponibles hasta que el caso se ha guardado por primera vez.
CUADRO DE DIÁLOGO CREACIÓN RÁPIDA : CASO

El cuadro de diálogo Creación rápida: Caso es una versión abreviada de la página Caso. Solo
contiene los campos más importantes para la entidad de caso. Este cuadro de diálogo se usa
para especificar rápidamente la información del caso y ahorrar tiempo. También puede usar
este cuadro de diálogo al crear un caso en el contexto de otro registro. Por ejemplo, si agrega
un caso directamente desde una cuenta de Dynamics 365, utilizará el cuadro de
diálogo Creación rápida: Caso.

Los cuadros de diálogo Creación rápida se pueden abrir desde la barra de navegación superior
de la aplicación, desde el panel relacionado o desde una subcuadrícula adjunta en un registro
principal. Aunque un cuadro de diálogo Creación rápida no esté disponible de forma
predeterminada para cada entidad, sí lo está para la entidad de caso. Por lo tanto, al agregar
un caso desde un registro relacionado, utilizará el cuadro de diálogo Creación rápida: Caso.
CONVERTIR REGISTROS DE ACTIVIDAD EN CASOS

En ocasiones, un caso puede ser consecuencia de una actividad, como un mensaje de correo
electrónico, una llamada de teléfono o una tarea. Por ejemplo, un agente de soporte podría
recibir por correo electrónico una solicitud de servicio directa de un cliente. En estas
situaciones, puede convertir directamente las actividades en registros de casos de Dynamics
365. Las reglas de creación y actualización de registros de Dynamics 365 se utilizan para
convertir automáticamente actividades específicas en registros de Dynamics 365. Esta
conversión también se puede realizar manualmente para un registro individual.

De entrada, se pueden convertir en casos los siguientes tipos de actividades:

 Citas

 Respuestas de campaña

 Mensajes de correo electrónico

 Faxes

 Cartas

 Llamadas de teléfono

 Actividades de servicio

 Tareas

 Actividades sociales

Todas las actividades personalizadas que se crean para una organización también se pueden
convertir en casos. Por ejemplo, una organización podría crear una actividad personalizada
denominada Mensajes SMS y utilizarla usa para trabajar con mensajes de texto. Estas
actividades también se pueden convertir en casos.

Dentro de una actividad específica, seleccione el botón Convertir en en la barra de comandos.

A continuación, puede seleccionar si desea convertir la actividad en una oportunidad o en un
caso.

Tras seleccionar En caso, aparece la página Convertir en caso. Esta página ofrece más
información y permite realizar acciones como cerrar la actividad como terminada.

Consideraciones sobre los canales

Al existir tantas vías de interacción con los clientes, las organizaciones ofrecen cada vez más
canales a través de los cuales los clientes pueden enviar casos de soporte. El canal a través del
cual se envía un caso puede influir en cómo se enruta el caso o a qué contrato de soporte al
cliente se aplica. Puesto que esta información puede ser vital, Dynamics 365 permite
seleccionar, directamente en el registro de caso, el canal específico por el que se recibió el
caso.
Consideraciones para automatizar la creación de casos
A menudo, las organizaciones prefieren que los casos se creen automáticamente en ocasiones
específicas. Por ejemplo, su organización podría tener un alias de correo electrónico
como [email protected] y utilizarlo para las solicitudes de soporte. Para cualquier solicitud de
correo electrónico que se envíe a dicho alias, se deberá crear automáticamente un caso en
Dynamics 365 y asociarlo al cliente que envió el mensaje de correo electrónico.

Las reglas de creación y actualización de registros automáticamente de Dynamics 365

constituyen la base para consumir información de varios canales, ingerirla como actividades de
Dynamics 365 (como mensajes de correo electrónicos o actividades sociales) y crear
automáticamente los registros de Dynamics 365 correspondientes. En la imagen siguiente se
muestra el concepto básico.

Cuando trabaja con el Centro de servicio al cliente, puede acceder a reglas de actualización y
creación automática de registros del área Administración de servicios de Dynamics 365.
En el área Administración de servicios, seleccione Reglas de creación y actualización
automática de registros. Al crear una regla, debe definir para ella un tipo de origen de
actividad. De entrada, se pueden convertir en casos los siguientes tipos de actividades de
Dynamics 365:

 Citas

 Respuestas de campaña

 Mensajes de correo electrónico

 Faxes

 Cartas

 Llamadas de teléfono

 Actividades de servicio

 Tareas

 Actividades sociales

Todas las actividades personalizadas que se crean para una organización también se pueden
convertir mediante las reglas de creación.

Además de definir el tipo de origen, puede definir una cola específica; la regla la supervisará
por si aparecen elementos de ese tipo. Por lo tanto, puede definir varias reglas para un mismo
tipo de origen, como el correo electrónico, si bien cada regla puede supervisar una cola
distinta.

Aunque puede crear varias reglas para un único tipo de origen, es importante recordar que
solo puede haber una regla activa para el mismo tipo de origen y cola en un momento dado.

Por ejemplo, en una cola denominada Soporte, puede haber definido una regla activa
denominada Correo electrónico en caso cuyo tipo de origen es Mensajes de correo electrónico.
Si crea otra regla denominada Correo electrónico en caso 2 cuyo tipo de origen también
sea Mensajes de correo electrónico, la regla Correo electrónico en caso se desactivará cuando
intente activar la regla Correo electrónico en caso 2.
Esto también sucederá si tiene dos reglas que no están asociadas a ninguna cola concreta pero
tienen el mismo tipo de origen. Tenga en cuenta este comportamiento cuando diseñe las
reglas.

En función del tipo de origen, se pueden modificar las condiciones adicionales para determinar
cuándo se creará un registro. A continuación se muestran las opciones cuando el tipo de
origen se establece en Mensajes de correo electrónico:

 Crear registros para correo electrónico de remitentes desconocidos: los casos

procedentes de direcciones de correo electrónico que no están asociados a una cuenta
o un contacto de Dynamics 365 se pueden crear automáticamente.

 Crear caso si existe un derecho válido para el cliente: debe existir un registro de
derecho válido para el cliente que ha enviado el mensaje de correo electrónico. Esta
condición no comprueba las características específicas del derecho. Solamente
comprueba que el derecho exista. Si un cliente tiene varios derechos, se creará un
registro.

 Crear casos para actividades asociadas a un caso resuelto: esta condición comprueba
si el mensaje de correo electrónico está relacionado con un caso resuelto
recientemente o si debe tratarse como un caso nuevo.
Esta lista representa únicamente las opciones disponibles para los mensajes de correo
electrónico. Recomendamos consultar las opciones disponibles para otros tipos de actividad,
como Actividades sociales. También existe una opción para definir propiedades de canal
adicionales. Esta opción puede ser útil si desea extraer datos adicionales de un elemento,
como una publicación en un medio social, y quiere utilizar esos datos para rellenar los campos
del registro recién creado.

Después de definir las características específicas de la regla, es preciso guardarla para poder
definir los detalles de creación y actualización. Los detalles son las reglas reales que se evalúan
y aplican, en función de la información de la actividad recibida. Se pueden definir varios
elementos de regla para una sola regla.
Por ejemplo, una regla Correo electrónico en caso puede contener los tres elementos de regla
siguientes:

 Elemento de regla 1: comprueba si la cuenta de Dynamics 365 del remitente es un

cliente Oro. En caso afirmativo, crea un caso de servicio de nivel Oro para el cliente,
cuyo origen es Correo electrónico.

 Elemento de regla 2: comprueba si la cuenta de Dynamics 365 del remitente es un

cliente Plata. En caso afirmativo, crea un caso de servicio de nivel Plata para el cliente,
cuyo origen es Correo electrónico.

 Elemento de regla 3: crea un caso para el que no se ha definido ningún nivel de

servicio y cuyo origen es Correo electrónico.

Cada elemento de regla consta de condiciones y acciones. Para que las condiciones y las
acciones estén disponibles, antes debe indicar un nombre para el elemento de regla y
guardarlo.

CONDICIONES

Las condiciones permiten evaluar contenido específico de la actividad que se convierte en un

registro de Dynamics 365 o de los registros que están relacionados con ella. Por ejemplo, una
condición podría especificar que es preciso consultar la cuenta o el registro de contacto
asociados al remitente del mensaje correo electrónico. A continuación, la condición podrá
comprobar si el campo de nivel de servicio de la cuenta (Campo personalizado) está
establecido en Oro. Esta funcionalidad proporciona mayor flexibilidad, ya que permite utilizar
como criterios también los datos pertinentes de Dynamics 365, además del contenido de los
mensajes de correo electrónico.

Se pueden especificar varios elementos en la misma condición. Los elementos de una

condición se pueden especificar como condiciones AND u OR.

ACCIONES

Las acciones tienen dos secciones.

  Registro que se creará: especifica el tipo de registro que desea crear. Este valor debe
establecerse en caso. Se creará un caso si se cumplen las condiciones especificadas
para la actividad.

 Configurar en Power Automate: la creación real del registro del caso está a cargo
de Power Automate. La aplicación Power Automate se abre en una nueva pestaña
donde puede configurar criterios que deben evaluarse para la actividad de correo
electrónico.

CÓMO SE APLICAN LOS ELEMENTOS DE REGLA

Los elementos de regla se comprueban en el orden en que se han definido en la regla. Una vez
que la regla encuentra un elemento de regla coincidente, aplica ese elemento de regla y deja
de buscar coincidencias adicionales. Puede controlar el orden en que se comprueban los
elementos de regla. Por lo tanto, es preferible indicar primero las reglas más específicas y
luego ir bajando.

Una vez que se activa una regla, comienza a definir casos para las actividades de correo
electrónico que se han enviado a una cola concreta.

Escenarios de administración de casos

Cuando los agentes trabajan con los problemas de los clientes, es importante que tengan
todas las herramientas necesarias para resolverlos desde una única ubicación. No tener esta
información tiene una gran incidencia en la eficiencia general de un agente. También puede
ser frustrante para un cliente, que deberá esperar mientras el agente se desplaza a diferentes
áreas para obtener lo que necesita. Proporcionar a los agentes lo que necesitan directamente
desde el caso en el que trabajan es la forma más efectiva de garantizar que los agentes tengan
las herramientas necesarias.

Esto podría incluir proporcionar al agente acceso a lo siguiente:

  Una lista de las tareas que deben realizarse para que se pueda resolver el caso.

 Acceso a la base de conocimientos de las organizaciones para ayudar a resolver el

problema.

 Historial contextual completo de lo que se ha hecho con el caso.

Acceso a otros temas similares que se pueden usar para ayudar en el proceso de resolución.

Desde el formulario del caso, pueden ver información general del caso, como el título, el
cliente, los detalles del SLA relacionados, las actividades relacionadas con el caso y otros datos
relacionados. Entre algunos de los datos clave con los que pueden trabajar los agentes se
incluyen:

 Escala de tiempo: muestra las actividades relacionadas con el caso. En función del
modelo de servicios de las organizaciones, muchas de ellas realizan un seguimiento del
tiempo total que los agentes dedican a las actividades asociadas con un caso, para
determinar cuánto tiempo se debe facturar al cliente.

 Relacionado: en la sección Relacionado se muestra información que puede estar

relacionada con el caso (como un artículo de conocimientos) o con el cliente con el
que está asociado el caso (como los contratos de soporte técnico o los casos
relacionados).

 Flujos de proceso de negocio: representan procesos guiados que se utilizan para guiar
a los agentes del servicio hacia una resolución de caso completa.

o La entidad de caso puede tener varios procesos de negocio disponibles que

pueden cambiarse según los detalles específicos del caso, como el tipo, el
origen u otros factores empresariales.

Escenarios de paneles de administración de casos

La aplicación del centro de Dynamics 365 Customer Service se ha diseñado usando la Interfaz
unificada de Dynamics 365. El Centro de Servicio al cliente no solo facilita que los
representantes del servicio al cliente trabajen y gestionen sus casos en la aplicación, sino que
también garantiza que todos los representantes tengan la misma experiencia de usuario,
independientemente de la plataforma que estén utilizando: teléfono, tableta o equipo.

El Centro de Servicio al cliente proporciona acceso a una serie de paneles interactivos que
están diseñados para facilitar la identificación de gran cantidad de casos, así como el acceso a
las entidades específicas que se usan para administrar las actividades del servicio al cliente. Los
agentes pueden obtener acceso a él desde el menú de navegación principal de la aplicación o
desde la pantalla de inicio de las aplicaciones.

Los paneles facilitan a los usuarios el consumo de datos y el trabajo que deben realizar con
ellos. Por ejemplo, un agente del servicio de soporte técnico puede necesitar obtener acceso a
casos que se encuentran en varias colas, como las colas de soporte técnico de tipo Oro y Plata.
Ese mismo agente también necesita ver los casos que se le asignan y las actividades que debe
completar. Así pues, se conforman cuatro áreas potencialmente diferentes de la aplicación a
las que tal vez necesite obtener acceso. Sin embargo, con un solo panel, el agente puede ver
los datos de las cuatro ubicaciones e interactuar fácilmente con ellas sin tener que salir de la
misma pantalla.

Cuando se inicie el Centro de servicio al cliente, los agentes verán una serie de paneles.
Muchos de estos paneles son los mismos que tradicionalmente han estado disponibles en
Dynamics 365. Además, los agentes podrán trabajar con paneles interactivos que son
exclusivos del Centro de servicio al cliente.
Existen dos tipos de paneles interactivos:

 Paneles de varias secuencias

 Paneles de secuencia única

Panel de varias secuencias: el panel de varias secuencias muestra datos en tiempo real en
varias secuencias de datos. Los datos de una secuencia se basan en una vista o cola de una
entidad, como, por ejemplo, Mis actividades, Mis casos o Casos de la Cola de actividades
bancarias. Aunque una secuencia siempre incluye información sobre una única entidad, cada
secuencia del panel puede incluir información sobre otra entidad.

Por ejemplo, es posible que quiera realizar un seguimiento de los casos y las cuentas en una
ubicación central. Dado que una secuencia solo puede contener datos de una entidad, no se
puede realizar un seguimiento de ambas en una sola secuencia. Sin embargo, se puede hacer
un seguimiento de los casos de una secuencia y las cuentas de otra. Ambas secuencias se
pueden mostrar en el panel.

También se puede configurar un panel de varias secuencias para que muestre aquellas
secuencias basadas en la misma entidad. Por ejemplo, es posible tener un panel que contenga
una secuencia que muestre los casos activos de un agente y otro que contenga los casos que
se han abierto esta semana. El Centro de servicio al cliente contiene un panel de varias
secuencias denominado "Panel de nivel 1" que está integrado.

Panel de secuencia única: los paneles de secuencia única muestran los datos en tiempo real de
una secuencia, en función de una vista o cola como, por ejemplo, Casos activos. Todos los
gráficos del panel están asociados a la secuencia de datos. Además, un panel de secuencia
única contiene iconos. Los iconos se colocan en el lado derecho del tablero y siempre se
muestran. Los paneles de secuencia única pueden resultar útiles a aquellos usuarios que
necesitan supervisar menos casos, pero que sean más complejos o estén escalados en una sola
vista o cola. El Centro de Servicio al cliente de uso inmediato contiene un panel de secuencia
única denominado Panel de segundo nivel.

PANEL DE NIVEL 1

El panel de nivel 1 proporciona varias "secuencias" que le permiten trabajar con casos y
elementos relacionados, como actividades o correo electrónico. Al usar filtros visuales, puede
mostrar gráficos interactivos que le permiten filtrar un caso en función de criterios específicos.
De esta manera, puede encontrar los casos más apropiados para que los agentes trabajen.

Los filtros de fecha le permiten cambiar el rango de fechas de la información que ven los
agentes. Existen varios rangos predefinidos para elegir, aunque también puede definir rangos
personalizados.

PANEL DE NIVEL 2

Cuando los agentes quieren profundizar más en los casos, pueden usar el Panel de nivel 2. En
este caso, en lugar de mostrar varias secuencias que pueden ser de varias entidades, el panel
muestra una sola secuencia que se basa en los casos activos. También incluye varios iconos y
gráficos interactivos para trabajar con los datos de los casos.

Igual que sucede en el panel de nivel 1, los gráficos se pueden usar como filtros interactivos
para obtener más detalles de tipos específicos de casos. Asimismo, los iconos interactivos
agrupan los datos relevantes que están asociados a los casos. Puede usar los iconos para ver
los registros específicos que se incluyen en los iconos.
PANELES DE INFORMACIÓN ESPECÍFICOS DE LA ENTIDAD

Otra característica del Centro de servicio al cliente es la capacidad de trabajar con paneles de
información específicos de la entidad. Los paneles de información específicos de la entidad son
exactamente lo que su nombre describe; se trata de paneles de varias secuencias que
muestran secuencias de datos relacionadas con una sola entidad, como los casos.

Cuando los agentes van a la entidad del caso, podrán ver una lista de sus casos activos. En la
barra de comandos existe una opción para abrir paneles. Esta acción abrirá el panel del caso.
Desde el panel del caso, los agentes pueden seleccionar el botón Mostrar filtro visual para
mostrar el filtro visual del caso y así poder filtrar los datos del mismo. Esto les permite realizar
elementos más específicos, que les ayudarán a identificar los casos apropiados para trabajar.
Los agentes pueden volver a la vista de la lista de entidades en cualquier momento,
seleccionando el botón Abrir vistas del panel.

CASOS PRINCIPALES Y SECUNDARIOS.

En ocasiones se pueden crear múltiples casos que estén todos relacionados con el mismo caso
principal. De entrada, Dynamics 365 le deja crear casos principales y secundarios usando su
estructura jerárquica de casos. Por ejemplo, usted trabaja en una empresa de software que
acaba de sacar una actualización de una de sus aplicaciones de software. Pero la actualización
tiene un error. Puesto que muchos clientes diferentes pueden llamar para informar del error,
es posible que se creen múltiples casos. Al usar jerarquías de caso, podrá asociar todos los
casos en un único caso principal. Cuando el error esté corregido en el caso principal, todos los
casos secundarios también podrán resolverse y cerrarse al mismo tiempo.

En la imagen siguiente se muestran algunos ejemplos de cómo las jerarquías de caso se

pueden usar en una organización de atención al cliente.

Información importante de la jerarquía de caso

 No se pueden asociar más de 100 casos secundarios a un único caso principal. Si

necesita más de 100 casos secundarios, puede que tenga que crear manualmente una
jerarquía de caso personalizada.

 Solo se admite un nivel de jerarquía.

o Las asignaciones de campos de caso se pueden crear para que completen

automáticamente los campos de registros de casos secundarios.

o La asignación solo se aplica cuando un registro de caso secundario se crea en

el contexto de un caso principal.

o Las asignaciones de campos de caso no mantienen los registros sincronizados.

 La característica de la jerarquía de caso admite tres opciones de cierre en cascada

cuando se cierra un caso principal:

o Ninguno: cerrar el caso principal no tiene ningún efecto en los casos

secundarios. Los casos secundarios se deben cerrar individualmente.
o Cerrar todos los casos secundarios cuando se cierra el principal: cualquier
caso secundario abierto se cerrará automáticamente cuando se cierre el caso
principal.
 o No permitir el cierre del caso principal hasta que estén cerrados todos los
casos secundarios: todos los casos secundarios se deben cerrar antes de que
el caso principal se pueda cerrar.

COMBINACIÓN DE CASOS

En algunos escenarios comunes, uno o más clientes pueden informar de un único caso varias
veces. Por ejemplo, un cliente inicia un caso a través de un portal Web e informa de que no
puede iniciar sesión porque ha olvidado su contraseña. Más tarde, el mismo cliente llama al
servicio de asistencia para notificar que tiene problemas para iniciar sesión. Como se pueden
abrir varios casos para el mismo artículo, esto puede afectar a la carga de casos del agente. Los
indicadores clave de rendimiento (KPI) que la organización sigue para los acuerdos de nivel de
servicio (SLA) también pueden verse afectados.

En estos casos, la característica de combinación de casos en Dynamics 365 se puede usar para
combinar los casos individuales en un registro de caso principal.

En la imagen siguiente se muestran algunos casos potenciales de uso para esta función.

Consideraciones adicionales para la combinación de casos

 La característica de combinación de casos en Dynamics 365 admite combinaciones de

dos o más casos activos. Se permite combinar un máximo de 10 casos en una sola
acción.

 Un caso se puede marcar como el caso principal.

o El caso principal estará activo.

o El resto de los casos se cancelarán.

o Todas las actividades, notas y archivos adjuntos asociados con todos los casos
se reasignarán al caso principal.

 Después de que se combinen los casos, la combinación no se puede deshacer.

Trabajar con transiciones de razones para el estado
El estado de un registro ayuda a identificar dónde se encuentra el registro en un determinado
proceso. Por ejemplo, si trabaja actualmente en un caso en el sistema, se considera que el caso
tiene el estado de Activo. Cuando se cierra el caso, puede establecerlo con un estado de
Resuelto. Estos estados facilitan clasificar, filtrar y consultar registros específicos del sistema.

Hay disponibles estados específicos, listos para usar, para cada registro de Dynamics 365, en
función del tipo de registro. Son tres los estados en los que pueden estar los casos:

 Activo: el caso está actualmente abierto y se está trabajando activamente en él en la

aplicación.

 Resuelto: se ha corregido el problema correspondiente al caso.

 Cancelado: el caso ya no está activo en el sistema, pero no se ha resuelto.

No puede cambiar los estados disponibles para un tipo de registro específico. Pero suele ser
importante tener información más específica sobre el estado de un registro. Por ejemplo, un
caso podría estar activo en el sistema, pero ¿qué se ha hecho exactamente en el caso? ¿Está
investigando el agente el problema? ¿Está esperando el agente a que el cliente proporcione
más información? Conocer estos detalles puede resultar vital para una prestación de servicios
eficaz.

Cada tipo de registro tiene lo que se denomina una razón para el estado. Con cada estado del
registro específico hay asociada una razón para el estado, que ofrece más información sobre
por qué el registro se encuentra en ese estado. Para los casos de Dynamics 365, hay
disponibles varias razones para el estado listas para usar:

 Activo:

o En curso: un agente del servicio al cliente está trabajando actualmente en el

caso.

o En espera: el caso está activo, pero no se está trabajando en él actualmente.

o Esperando detalles: el caso está activo, pero se está esperando obtener más
información del cliente.

o Bajo investigación: el caso se está investigando actualmente.

 Resuelto:

o Problema resuelto: se encontró una solución satisfactoria para el caso.

o Información proporcionada: se dio al cliente información satisfactoria y el

problema se corrigió.

 Cancelado:

o Cancelado: el caso se canceló.

o Combinado: el caso se canceló porque se combinó con otro registro.

Puede agregar, quitar o cambiar las razones para el estado del caso según sea necesario yendo
a Personalizaciones > Casos > Campos y seleccionando la flecha desplegable en el
campo Razón para el estado. Hay disponibles varias razones para el estado correspondientes a
cada estado, y se pueden modificar.

TRANSICIONES DE LAS RAZONES PARA EL ESTADO

A menudo, las organizaciones tienen un determinado proceso que siguen para resolver casos.
Los estados del caso y las razones para el estado podrían desempeñar una función en dicho
proceso. Para ayudar a las organizaciones a definir con mayor claridad estos procesos y a
aplicarlos, Dynamics 365 les permite crear rutas de transición de razones para el estado de
clientes.

Las transiciones de razones para el estado agregan una capa adicional de filtrado con idea de
definir una lista específica de razones para el estado que se pueden seleccionar para una razón
concreta. Por ejemplo, cuando un caso tiene una razón para el estado Esperando detalles,
técnicamente ya está en espera. Por lo tanto, dejar que un técnico cambie la razón para el
estado a En espera es redundante. Además, En espera podría no ser la mejor razón para el
estado a la que efectuar la transición. Al usar transiciones de razones para el estado, puede
definir las transiciones específicas a las que un agente puede ir desde la razón para el
estado Esperando detalles.

En la imagen siguiente, se muestra un ejemplo.

Como puede ver, cuando un caso tiene una razón para el estado Esperando detalles, las únicas
opciones de transición son:

 Cancelado

 Remitido a servicio

 Bajo investigación

 En curso

Por cada una de las razones para el estado, a su vez, se pueden seleccionar varias transiciones.
Por lo tanto, las transiciones de las razones para el estado facilitan a las organizaciones el
ayudar a garantizar que los agentes utilicen únicamente razones válidas, en función de la razón
para el estado actual.

Las transiciones de razones para el estado solo están disponibles en la entidad Caso y
entidades personalizadas. Puede cambiarlas seleccionando el botón Editar las transiciones de
la razón para el estado en la página de personalización de campos de la razón para el estado.
Tras activar la característica de transiciones de la razón para el estado, puede definir las
razones para el estado específicas disponibles.
Cuando se definen opciones de razón correspondientes a una razón para el estado activa, debe
haber al menos una ruta para un estado inactivo. Por ejemplo, si un caso tiene una razón para
el estado En curso, debe ser posible efectuar la transición a al menos una de las siguientes
razones para el estado: Cancelado, Combinado, Problema solucionado, o Información
proporcionada. Si no se proporciona al menos una ruta a un estado inactivo, no podrá guardar
nuevas transiciones.

Una vez guardadas y publicadas las transiciones, los agentes verán los cambios reflejados en la
aplicación..

CREAR UNA COLA DE DYNAMICS 365

Cuando una organización está lista para comenzar a usar colas, estas pueden crearse en
función de las necesidades organizativas específicas. Antes de agregar colas a una
organización, tómese un tiempo para considerar el número total de colas que se necesitarán y
para qué se utilizarán.

Las colas se pueden crear en la aplicación Centro de administración de Customer Service. Para
crear colas, seleccione la opción Colas en Asistencia al cliente y luego elija Administrar junto
a Colas básicas.

Cuando se crea una nueva cola, se requieren el nombre y el tipo de cola. También puede
especificar otra información, pero la cola no se puede guardar a menos que se definan esas
dos propiedades.

Hay distintos tipos de colas disponibles:

 Personal: estas colas están asociadas a un equipo o usuario específico. El sistema se

encarga de crearlas.
 o El sistema crea automáticamente las colas personales cuando se agrega un
usuario o equipo a Dynamics 365. No se pueden crear manualmente.

o La pertenencia en la cola no se puede editar manualmente. Al agregar y quitar

miembros del equipo, ajusta la pertenencia de las colas asociadas a un equipo.

 Público: todos los usuarios pueden ver esas colas y tener acceso a ellas, en función de
su rol de seguridad.

o Los usuarios eligen elementos de la cola. Luego, los elementos que selecciona
un usuario se mueven a la cola personal de ese usuario.

 Privado: el acceso a estas colas se asigna a usuarios específicos. (Los miembros se

definen en el registro de la cola).

o Los usuarios eligen elementos de la cola. Luego, los elementos que selecciona
un usuario se mueven a la cola personal de ese usuario.

Consideraciones sobre los correos electrónicos

Si una cola debe recibir correos electrónicos, debe tener un alias de correo electrónico
asociado. Ese alias de correo electrónico debe estar asociado a un registro de buzón de correo
de trabajo en Dynamics 365. La configuración del sistema se puede usar para especificar si una
cola que tiene un alias de correo electrónico se aprueba para aceptar elementos de correo
electrónico entrantes.

Además de especificar un registro de buzón de correo para una cola, puede definir los correos
electrónicos que entran en la cola que se convertirán en actividades de correo electrónico.

Tiene varias opciones:

 Todos los mensajes de correo electrónico

 Mensajes de correo electrónico en respuesta al correo de Dynamics 365

 Mensajes de correo electrónico de clientes potenciales, contactos o cuentas de

Dynamics 365

 Mensajes de correo de registros de Dynamics 365 habilitados para correo electrónico

Es importante seleccionar una opción de correo electrónico, ya que especifica qué se definirá
como actividades de correo electrónico y qué actividades de correo electrónico se pueden
convertir automáticamente en registros de casos en el sistema. Por ejemplo, una cola de
soporte técnico puede recibir mensajes de correo electrónico de clientes que se encuentran en
su aplicación de Dynamics 365, pero también puede recibir correos electrónicos de usuarios
que no son clientes de Dynamics 365.

Después de que la cola se haya guardado por primera vez, si se ha designado como cola
privada, puede definir a sus miembros. Solo pueden trabajar con una cola privada los
miembros que asigne a esta. Además, cuando los elementos se enrutan a la cola, puede ver
qué elementos incluye esta. También puede ver las reglas de creación y actualización de
registros asociadas con la cola.
Una vez se crea una cola, esta tiene el estado Activo. Si por algún motivo la cola no se debe
usar, puede desactivarla. Si descubre que la cola es necesaria más tarde, puede reactivarla.

Conjuntos de reglas de enrutamiento

En función de la organización, el enrutamiento y la distribución de elementos de trabajo a los

agentes puede variar según la organización. Es posible que una organización más pequeña
puede llevar un caso nuevo relacionado a una pregunta de facturación y moverlo a una cola de
facturación hasta que un agente seleccione físicamente y comience a trabajar en él. Por el
contrario, es posible que un centro de contacto puede tener una necesidad mayor de no solo
desear enrutar los elementos relacionados con la facturación a una cola de facturación, sino
también de asignar automáticamente el elemento a un miembro de esa cola con
disponibilidad para trabajar en él. Esto garantizaría que se asignen todos los elementos y que
no se pueda perder nada.

D365 Customer Service proporciona a las organizaciones dos opciones de enrutamiento que
las organizaciones que se pueden usar para satisfacer las necesidades de cualquier
organización, desde las pequeñas organizaciones hasta las grandes empresas.

 Enrutamiento básico: normalmente se usa para enrutar registros como casos, clientes
potenciales, correos electrónicos, etc. a personas, equipos o colas en función de
diferentes criterios de reglas definidos. El criterio utilizado con la característica de
enrutamiento básico suele ser básico y sencillo. (Examinará el enrutamiento básico con
más detalle más adelante en este módulo).

 Enrutamiento unificado (enrutamiento avanzado): ofrece capacidades de

enrutamiento más avanzadas que dirigen el trabajo entrante al agente y a la cola más
adecuados. El enrutamiento unificado proporciona capacidades de enrutamiento más
avanzadas.

Las características básicas de enrutamiento disponibles en Dynamics 365 Customer Service se

pueden aplicar cuando desee asignar registros como casos a personas, equipos o colas.
Asignará elementos según una lógica predefinida basada en propiedades del registro para
determinar a qué cola enrutar el caso.

Cuando se crea una regla por primera vez, es necesario definir un nombre de regla. Después
de definir un nombre y guardar la regla, se pueden agregar elementos a la misma. Los
elementos de regla definen los valores correspondientes a "qué" y "dónde" para el conjunto
de reglas. Un elemento de regla especifica las condiciones que se evaluarán para enrutar casos
a una cola, un agente o un equipo.

Por ejemplo, cuando se crean casos, el campo Nivel de servicio se puede establecer para que
se base manual o automáticamente en las necesidades de la organización. Para garantizar que
los casos se enruten a la cola correcta en función de su nivel de servicio, un conjunto de reglas
de enrutamiento denominado Enrutamiento de casos podría tener los siguientes elementos de
regla:

 Ruta Oro: se usa para enrutar cualquier caso con un nivel de servicio Oro a la cola de
tipo Oro.

 Ruta Plata: se usa para enrutar cualquier caso con un nivel de servicio Plata a la cola
de tipo Plata.

 Ruta Bronce: se usa para enrutar cualquier caso con un nivel de servicio Bronce a la
cola de tipo Bronce.

Cada elemento de la regla tiene dos secciones: Condiciones If y Condiciones Then.

 Condiciones If: gracias a este elemento se definen las condiciones específicas para
determinar si se aplica el elemento de la regla. Las condiciones pueden evaluar
campos del registro del caso o de registros relacionados, como la cuenta relacionada.
Se pueden usar varias condiciones AND u OR en un solo elemento de regla. (De
manera predeterminada, las condiciones son condiciones AND).

 Condiciones Then: con este elemento se especifica hacia dónde se debe enrutar el
artículo.
 o Cola: se usa para enrutar el elemento a una cola específica (pública o privada).

o Usuario o equipo: se usa para enrutar un elemento a un usuario o un equipo

específico.

Los elementos de la regla se aplican según el orden en que se especificaron en el conjunto de

reglas. El primer elemento de regla coincidente que se encuentre se aplicará al caso. El
conjunto de reglas no evalúa los elementos de regla restantes para así tratar de encontrar una
mejor coincidencia.

Información general sobre los acuerdos de nivel de servicio (SLA)

Una de las estrategias que utilizan las organizaciones basadas en el servicio al cliente para
supervisar la satisfacción del cliente y diferenciarse de otras organizaciones semejantes
consiste en identificar y seguir los indicadores clave de rendimiento (KPI). Un KPI es un valor
medible que indica la eficacia de una empresa respecto a la consecución de los objetivos
empresariales importantes. Las organizaciones usan los KPI para evaluar en qué medida están
alcanzando sus objetivos.

Los KPI específicos que las organizaciones siguen pueden variar mucho, pero hay varios de
ellos comunes que se pueden utilizar para medir correctamente el éxito y mejorar el servicio al
cliente:

 Puntuación de la satisfacción del cliente (CSAT): es el KPI más frecuente y se suele

capturar preguntando a los clientes en qué medida están satisfechos con la empresa,
el producto o el servicio en cuestión.

 Net Promoter Score (NPS): este KPI mide la probabilidad de que sus clientes le
recomienden a usted a otro usuario.

 Primer tiempo de respuesta: este KPI mide la velocidad de la respuesta inicial al

cliente cuando se crea un problema.

 Tiempo de resolución de llamadas: este KPI mide la velocidad a la que resuelve los
problemas de los clientes.

 Tasa de retención de clientes: este KPI mide su capacidad para conservar a sus clientes
de pago durante un período específico.
  Implicación de los empleados: este KPI mide en qué medida sus empleados están
comprometidos con su empresa.

Aunque esta lista no es exhaustiva en absoluto, le permite hacerse una idea de lo que suele
preocupar a las organizaciones de servicio al cliente.

Dynamics 365 for Customer Service le permite definir contratos de nivel de servicio (SLA) para
ayudar a resolver los niveles de servicio deseados al prestar soporte a los clientes. Los SLA de
Dynamics 365 le permiten seguir los KPI comunes, como Primer tiempo de respuesta o Tiempo
de resolución de llamadas, para cada caso que se registra. También puede crear KPI
personalizados para seguir elementos específicos de su empresa que son importantes para su
organización.

Cada SLA se puede configurar de tal forma que modele varios KPI, en función de distintos
atributos de casos. Cada SLA incluirá varias líneas de detalle que proporcionan información
acerca del KPI que se sigue y de las acciones asociadas a él.

Cada línea de detalle define la siguiente información:

 KPI del SLA: el KPI que está midiendo.

Ejemplo: Primera respuesta por o Resolver por

 Aplicable cuando: condiciones que han de cumplirse para que el elemento sea
aplicable al caso.

Ejemplo: El campo Nivel de servicio de un caso se ha establecido en Gold y el campo Prioridad

del caso se ha establecido en Alta.

 Criterios de éxito: el aspecto que tiene una resolución correcta del KPI.

Ejemplo: El campo Primera respuesta enviada está establecido en Sí.

 Acciones de éxito: las acciones que han de llevarse a cabo si se cumple el KPI.

Ejemplo: Actualizar el registro del caso para indicar que se ha enviado la primera respuesta.

 Error de elemento de SLA: el tiempo que se deberá esperar hasta que se considere
que un elemento no se ha producido o se ha incumplido.

Ejemplo: No se ha realizado la comunicación de la primera respuesta dentro del plazo de una

hora desde la creación del caso.

 Acciones de error: las acciones que han de llevarse a cabo si no se cumple el KPI.

Ejemplo: Remitir el caso a la cola de elevación de caso y notificárselo al administrador del

servicio.

 Advertencia de elemento de SLA: el tiempo que se esperará hasta enviar una

advertencia de que existe el riesgo de que un elemento no se cumpla.

Ejemplo: No se ha realizado la comunicación de la primera respuesta dentro del plazo de

30 minutos desde la creación del caso.

 Acciones de advertencia: las acciones de advertencia que deberán llevarse a cabo si

existe el riesgo de que el KPI no se cumpla.
Ejemplo: Enviar un mensaje de correo electrónico de recordatorio al agente responsable del
caso.

En la imagen siguiente se muestra un SLA típico para diferentes tipos de clientes, en función
del nivel de servicio al que se ha comprometido con ellos.

En este ejemplo, se han definido tres condiciones para el SLA:

 Tipo de cliente = Premium/Corporativo y Prioridad del caso = Alta:

o Primera respuesta en el plazo de una hora laborable

o Resolución de caso dentro de un día laborable

 Tipo de cliente = Premium/Corporativo y Prioridad del caso = No alta:

o Primera respuesta en el plazo de cuatro horas laborables

o Resolución de caso dentro de dos días laborables

 Tipo de cliente = Estándar y Prioridad del caso = Cualquiera:

o Primera respuesta en el plazo de un día laborable

o Resolución de caso dentro de cinco días laborables

En función del tipo de cliente que envía un caso y de la prioridad de este último, el SLA lleva a
cabo una de estas acciones:

 Enviar un mensaje de correo electrónico de advertencia al propietario del caso si

existe el riesgo de que no cumpla el KPI Primera respuesta por.

o Enviar un mensaje de correo electrónico al representante del servicio al cliente

y al administrador del servicio al cliente si no cumplen el KPI Primera respuesta
por.
 o Actualizar el registro del caso estableciendo el campo Primera respuesta
enviada del SLA en No.

 Enviar un mensaje de correo electrónico de advertencia al propietario del caso si

existe el riesgo de que no cumpla el KPI Resolver por.

o Enviar un mensaje de correo electrónico al representante del servicio al cliente

y al administrador del servicio al cliente si no cumplen el KPI Resolver por.

o Actualizar el registro del caso estableciendo el campo Resolución del SLA en

No.

Además, los SLA de Dynamics 365 pueden tener en cuenta aspectos como las horas laborables
y los cierres temporales de las empresas al comprobar si un KPI se ha cumplido o no.

Por ejemplo, supongamos que su organización abre de 8:00 de la mañana a 5:00 de la tarde y
que se ha comprometido con un cliente en un tiempo de respuesta de cuatro horas. Estas
cuatro horas podrían basarse exclusivamente en el tiempo que su organización está abierta.
Por lo tanto, si un cliente llama a las 15:00, se le deberá devolver la llamada a las 10:00 de la
mañana del siguiente día laborable. En cambio, a un cliente que tenga asociado un SLA 24/7 se
le deberá devolver la llamada antes de las 7:00 de la tarde de ese mismo día.

En su organización, es fundamental que tengan en cuenta todos los escenarios distintos en los
que prestan soporte para asegurarse de poder configurar y asignar el SLA adecuado a cada tipo
de llamada recibida.

Otro factor que puede tener en cuenta es tiempo transcurrido esperando a los clientes. Si se
ha comprometido con un cliente a resolver su caso en dos horas, cada minuto cuenta. Por lo
tanto, si una de las dos horas se pierde esperando a que el cliente le proporcione una
contraseña, deberá decidir si esa hora se contabilizará al calcular el tiempo de resolución
comprometido.

La característica de SLA de Dynamics 365 admite todos estos escenarios. Durante el resto de
este módulo, le guiaremos para conocer estos escenarios. También recorreremos el proceso
de configurar los SLA de tal forma que satisfagan necesidades específicas.

Cierres de empresa y horas laborables

Cuando una organización comienza a diseñar contratos de nivel de servicio (SLA) para cumplir
los requisitos de los indicadores clave de rendimiento (KPI), debe tener en cuenta el horario
durante el que presta soporte a sus clientes.

Por ejemplo, supongamos que una organización está abierta de lunes a viernes, de 8:00 de la
mañana a 5:00 de la tarde. Este horario representa el tiempo estándar durante el que la
mayoría de los clientes de la organización pueden llamar para recibir soporte. Pero un cliente
que haya adquirido un contrato de soporte, podría tener derecho a soporte 24/7.

Al abrir un caso, es importante identificar el horario al que debe asociarse ese caso y aplicar el
SLA correcto. Por lo tanto, es preciso identificar las diferentes programaciones de trabajo que
se requieren en la organización. Tenga en cuenta factores como los requisitos de zona horaria
o los días festivos en que la empresa está cerrada.

PROGRAMACIÓN DE VACACIONES
Programación de vacaciones permite a las organizaciones especificar los días festivos que
respetan en los que habitualmente estar cerradas. Para configurar la programación de
vacaciones, vaya a Configuración > Administración de servicios; a continuación, en la
sección Condiciones de servicio, seleccione Programación de vacaciones. La primera vez que
se crea una programación de vacaciones, debe asignar un nombre; por ejemplo, Vacaciones en
EE. UU.

Si su organización presta soporte a clientes en varios países o regiones, los días festivos
respetados serán distintos en cada uno de ellos. Por lo tanto, deberá asegurarse de configurar
las programaciones de vacaciones necesarias para cada país o región donde preste soporte.

Una vez que haya creado una programación de vacaciones, puede comenzar a agregar días
festivos. Los días festivos suelen incluir la información siguiente:

 Nombre: nombre de la festividad.

 Fecha de inicio: día de inicio de los días festivos.

 Fecha de finalización: día de finalización de los días festivos.

 Duración: duración total de los días festivos.

Por ejemplo, si su organización va a cerrar el día de Año Nuevo de 2019, este día festivo se
configuraría así:

 Nombre : Año Nuevo 2019

 Fecha de inicio: 1/1/2019

 Fecha de finalización: 1/1/2019

 Duración: 1 día

Debe definir cada día festivo. Por lo tanto, puede agregar el día de Año Nuevo festivo en 2019,
2020, 2021 y así sucesivamente.

Aunque se pueden agregar los días festivos individualmente, muchos de ellos se pueden
importar (por ejemplo, desde un archivo de Excel) y asociarlos a la programación de
vacaciones correspondiente. Los días festivos suelen ser lo primero que se configura.
CALENDARIOS DE SERVICIOS AL CLIENTE

A continuación, debe configurar los calendarios de servicios al cliente para definir los distintos
horarios de trabajo que puedan aplicar los SLA. Los calendarios de servicios se suelen definir
después de las programaciones de vacaciones, para así poder asociar los primeros a las
segundas. Para configurar los calendarios de servicios, vaya a Configuración > Administración
de servicios; a continuación, en la sección Condiciones de servicio, seleccione Calendarios de
servicios al cliente.

Al configurar calendarios de servicios al cliente, puede definir las siguientes propiedades:

 Horas laborables: seleccione las horas laborables específicas asociadas al calendario

de servicios:

o Las mismas todos los días: las horas laborables pueden ser las mismas todos
los días. Tras seleccionar esta opción, seleccione Definir horas laborables para
definir el horario laboral, incluidos los descansos.

o Variar por día: se mostrarán todos los días de la semana. Tras seleccionar esta
opción, elija los días que la organización está abierta y, a continuación, haga
clic en Definir horas laborables para definir el horario laboral, incluidos los
descansos, de cada día.

o Soporte 24 horas, 7 días a la semana: las horas laborables se establecen

automáticamente en 24 horas al día, 7 días a la semana. Las horas y los días no
se pueden cambiar.

 Días laborables: seleccione los días de la semana que la organización está abierta. Esta
opción solo está disponible si ha seleccionado Las mismas todos los días en el grupo
de campos Horas laborables.
  Programación de vacaciones: seleccione si el calendario de servicios incluye días de
cierre por festivo. Si se selecciona Respetar, puede seleccionar la programación de
vacaciones que desea utilizar.

 Zona horaria: seleccione la zona horaria del calendario de servicios.

Probablemente haya varios calendarios de servicios al cliente definidos en su organización. A

menudo, las organizaciones tienen al menos dos calendarios de servicios:

 Estándar: las horas laborables son de lunes a viernes de 8:00 de la mañana a 5:00 de la
tarde. Se respeta la programación de vacaciones de EE. UU.

 24/7: las horas laborables se definen en 24 horas al día, 7 días a la semana. No se

respeta ninguna programación de vacaciones.

También puede tener calendarios representativos de los diferentes países o regiones donde
preste soporte.

Una vez que haya configurado todos los calendarios de servicios necesarios para su
organización, puede comenzar a definir los SLA en la aplicación.

Crear acuerdos de nivel de servicio (SLA)

Los contratos de nivel de servicio (SLA) se pueden crear para realizar un seguimiento de los
indicadores clave de rendimiento (KPI) específicos y medirlos, en función del cliente y los
detalles del caso. Es importante recordar que los SLA no son específicos de un cliente, sino que
están definidos para la organización. Se aplican a un caso de cliente mediante la asociación
manual del caso con un SLA específico o la vinculación del caso a un derecho que está asociado
con un SLA específico. Además, se puede definir un SLA predeterminado para la organización.
De esa manera, si no se define ningún SLA para un caso, el SLA predeterminado se aplicará
automáticamente.

Para crear SLA, vaya a Configuración > Administración de servicios y, a continuación, en la

sección Condiciones de servicio, seleccione Contratos de nivel de servicio. Al definir SLA,
considere qué calendario de servicio al cliente (si lo hay) debe utilizarse. De esta manera,
ayuda a garantizar que todos los KPI se calculen correctamente, en función de las horas de
trabajo y los días festivos del centro que atiende al cliente. A menudo, se define al menos un
SLA para cada calendario de servicios que existe para una organización.

Otro elemento clave que debe tener en cuenta al definir un SLA es desde cuándo será aplicable
dicho SLA. El campo Aplicable desde se puede establecer en cualquier campo de fecha
asociado a dicha entidad como, por ejemplo, Fecha de creación o Fecha de modificación. Esto
define cuándo deberían comenzar a calcularse los KPI de SLA.

Por ejemplo: digamos que quiere tener un SLA con un KPI de "Primera respuesta en un plazo
de" definido en 4 horas:

 Si establece el campo Aplicable desde en Fecha de creación, el agente que toma el

caso tendrá 4 horas a partir de la hora y la fecha en que se creó el caso para realizar
una primera respuesta inicial con el cliente.

 Si establece el campo Aplicable desde en Fecha de modificación, cada vez que se

actualice el registro del caso, se reiniciará el temporizador del KPI de "Primera
respuesta en un plazo de".

Si bien el uso del campo Fecha de modificación puede ser útil en algunos casos, no es un
desencadenante ideal para realizar un seguimiento de un KPI de primera respuesta. Debe
prestar mucha atención a la configuración que establece para el campo Aplicable desde, ya
que puede tener un impacto significativo en cómo se calculan los KPI.

En la imagen siguiente se muestra un ejemplo de un SLA 24/7.

Después de definir la información especificada anteriormente, puede guardar el SLA. Al

guardar el SLA, obtiene la capacidad de comenzar a agregar elementos de la línea de detalles
al SLA.
DEFINIR LOS DETALLES DEL ACUERDO DE NIVEL DE SERVICIO (SLA)

En los detalles del contrato de nivel de servicio (SLA) se definen los indicadores clave de
rendimiento (KPI) específicos que quiere medir. También se define cuándo se debe aplicar un
elemento específico. Como mencionamos en la unidad de información general, un SLA típico
tendrá varios elementos de detalle de SLA definidos.

Por ejemplo, es posible que un SLA de cliente de contrato de soporte técnico tenga los
siguientes elementos de detalle del SLA:

 Cliente Oro: primera respuesta en un plazo de: si nivel de servicio = Oro para un caso,
primera respuesta en el plazo de una hora

 Cliente Oro: Resolución en un plazo de: si el nivel de servicio = Oro para un caso:
resolución de caso en el plazo de cuatro horas

 Cliente Plata: Primera respuesta en un plazo de: si el nivel de servicio es Plata para un
caso: primera respuesta en el plazo de dos horas

 Cliente Plata: Resolución en un plazo de: si el nivel de servicio es Plata para un caso:
resolución de caso en el plazo de un día

Cada KPI del que quiere realizar un seguimiento para cada nivel de servicio se agrega al SLA
como su propio elemento de detalle del SLA. Para realizar un seguimiento del progreso de los
clientes Oro, debe definir dos elementos de detalle independientes. Para el ejemplo anterior,
se definen un total de seis elementos de detalle para todo el SLA.

Para cada elemento de detalle del SLA que agregue a un SLA, debe proporcionar la siguiente
información:

 Nombre: escriba el nombre del elemento del SLA. Este campo es obligatorio,

 KPI del SLA: seleccione el KPI que está midiendo. De forma predeterminada, se liberan
dos KPI con la entidad Caso: KPI de Primera respuesta en un plazo de y KPI de
Resolución en un plazo de. Puede definir KPI adicionales para la entidad Caso según
sea necesario.
  Aplicable cuando: define las condiciones que deben existir en el registro con el que se
está ejecutando el SLA o en un registro relacionado para el elemento del SLA
específico que se aplicará al registro (por ejemplo, un nivel de servicio de caso
establecido en Oro).

o Esté al tanto si usa un campo que es posible que cambie con frecuencia al
definir las condiciones "Aplicable cuando". Pueden afectar potencialmente al
rendimiento del sistema.

o Solo se pueden seleccionar los registros activos como argumentos de la acción

o condición.

 Criterios de éxito: defina el aspecto que tiene una resolución correcta del KPI definido.
Por ejemplo, una resolución puede ser correcta si se actualiza un campo específico del
registro actual o relacionado.

ADVERTENCIAS Y ERRORES DEL SLA

Después de haber definido cómo debe ser el cumplimiento satisfactorio del elemento de
detalle del SLA, debe definir el tiempo durante el que se pueden incumplir los criterios
correctos antes de que se establezca una advertencia de un posible error. También debe
definir el tiempo durante el que se pueden incumplir los criterios de éxito antes de que se
considere que se ha producido un error en el elemento. Para definir estos comportamientos,
debe configurar las advertencias del elemento del SLA y del error de dicho elemento. Cada uno
tiene un tiempo asociado y los tiempos actúan de forma independiente entre sí.

ACCIONES DEL SLA

Las acciones del SLA se usan para realizar una tarea específica, en función del cumplimiento de
los criterios. Para poder definir acciones, se debe guardar el elemento de detalle. Aunque las
acciones están respaldadas por el motor del flujo de trabajo, no tiene las mismas opciones
para las acciones que para los flujos de trabajo tradicionales. Por ejemplo, no puede iniciar
flujos de trabajo ni acciones personalizadas. Las opciones disponibles son Enviar correo
electrónico, Crear registro, Actualizar registro y Cambiar estado.

Pueden definirse tres tipos de acciones:

 Acciones de éxito: defina las acciones que se deben ejecutar si se cumplen los criterios
de éxito.

 Acciones de error: defina las acciones que se deben ejecutar si los criterios de éxito no
se cumplen dentro del tiempo de error especificado.
  Acciones de advertencia: define las acciones que se deben ejecutar si existe peligro de
que los criterios de éxito no se cumplan dentro del tiempo de advertencia
especificado.

A menudo, el valor de un campo específico, como el campo Indicador de primera respuesta,

se usará como criterio de éxito para un elemento del SLA. De forma predeterminada, los
valores de los campos como First Response Indicator se actualizarán automáticamente. Para el
campo First Response Indicator, debe determinar qué se considera una primera respuesta.

TRABAJAR CON VARIOS ELEMENTOS DEL SLA

Cuando se definen varios elementos del SLA para un solo SLA, dichos elementos se evalúan en
el orden en que aparecen en la subcuadrícula de detalles del SLA. Si varios elementos del SLA
hacen referencia al mismo campo relacionado en un registro específico, también se evalúan en
el orden en que aparecen en la lista. Se aplicará el primer elemento del SLA para cada campo
relacionado.
Puede cambiar el orden en que se evalúan los elementos del SLA mediante los botones de
flecha de la subcuadrícula de detalles del SLA. Si algunos de los elementos del SLA tienen
criterios más específicos que otros, le recomendamos que coloque los elementos más
específicos del SLA más arriba en la lista.

DEFINIR LOS INDICADORES CLAVE DE RENDIMIENTO (KPI) PERSONALIZADOS

De forma predeterminada, la entidad de caso es la única entidad que está configurada para
utilizarse con el acuerdo de nivel de servicio (SLA). No obstante, Dynamics 365 le permite usar
la funcionalidad del SLA con cualquier entidad. Además, puede definir indicadores clave de
rendimiento (KPI) personalizados para cualquier entidad que esté configurada para usarse con
SLA.

Hay muchos escenarios en los que podría usar los SLA con otras entidades en Dynamics 365. A
continuación, se muestran algunos ejemplos:

 Clientes potenciales: haga un seguimiento de la rapidez con la que los ejecutivos de

cuentas responden a los clientes potenciales.

 Órdenes de trabajo: haga un seguimiento de la rapidez con la que se programan y

envían las órdenes de trabajo.
  Oportunidades: haga un seguimiento de la rapidez con la que se cierran tipos de
oportunidades específicos.

Para configurar una entidad para que se pueda usar con SLA, vaya
a Configuración > Personalizaciones > Personalizar el sistema y seleccione la entidad. A
continuación, en Comunicación y colaboración, seleccione la casilla Habilitar para SLA.
Después, guarde y publique sus personalizaciones.

CREAR KPI PERSONALIZADOS

En la unidad anterior, mencionamos que se liberan dos KPI predefinidos con la entidad Caso:

 KPI de Primera respuesta en un plazo de

 KPI de Resolución en un plazo de

También puede definir más KPI para la entidad Caso y cualquier otra entidad que se haya
configurado para usarse con SLA.

Por ejemplo, aquí hay algunos KPI personalizados que puede configurar para los escenarios
mencionados anteriormente:

 Cliente potencial – KPI de contacto inicial: mida cuándo un ejecutivo de cuentas

realiza su contacto inicial con un cliente potencial.

 Órdenes de trabajo – KPI de Enviar por: mida cuándo una orden de trabajo se ha
marcado como programada.

 Oportunidad – KPI de Cerrado por: mida cuándo se ha cerrado una oportunidad.

Para definir KPI personalizados, cree un campo de búsqueda en la entidad de la instancia de

KPI de SLA. Este campo de búsqueda representa una relación uno a varios (1: N) con la entidad.
Para crear un campo de búsqueda para una entidad específica, vaya
a Configuración > Personalizaciones > Personalizar el sistema, seleccione la entidad para la
que se debe definir el KPI y, luego, seleccione los campos. A continuación, cree un nuevo
campo de búsqueda para esa entidad y configúrelo para usar la entidad de la instancia de KPI
de SLA.
Una vez que se haya definido el KPI, puede usarlo como KPI para cualquier elemento de SLA
que cree para los SLA asociados con la entidad seleccionada.

Administrar los acuerdos de nivel de servicio (SLA)

Tal como mencionamos al principio de este módulo, los contratos de nivel de servicio (SLA) no
son específicos del cliente. Se definen a nivel de organización y se aplican a los casos. El
registro de caso que está listo para usar no tiene un campo de búsqueda para la entidad del
contrato de nivel de servicio. Por lo tanto, un contrato de nivel de servicio no se aplicará a un
caso a menos que se este último se establezca en el contrato de nivel de servicio
predeterminado de la organización o que se asocie a un derecho.

Un contrato de nivel de servicio no se puede establecer como el contrato de nivel de servicio

predeterminado de una organización hasta que esté activado. Una organización solo puede
tener un contrato de nivel de servicio predeterminado. Si establece otro contrato de nivel de
servicio como predeterminado, anulará el contrato de nivel de servicio predeterminado
anterior. Si necesita desactivar temporalmente el contrato de nivel de servicio predeterminado
por cualquier motivo, debe configurarlo nuevamente como contrato de nivel de servicio
predeterminado una vez que se haya reactivado.
Los contratos de nivel de servicio deben estar desactivados cada vez que quiera realizar
cualquier cambio. Cuando desactiva un contrato de nivel de servicio todos los derechos
asociados a él permanecen activos. Mientras el contrato de nivel de servicio esté inactivo, no
se actualizará ningún campo del contrato de nivel de servicio en los casos vinculados al
contrato de nivel de servicio inactivo.

PAUSAR Y REANUDAR CONTRATOS DE NIVEL DE SERVICIO

Pongamos que está trabajando en un caso con un cliente y que necesita información específica
de ese cliente. Mientras espera a que el cliente le conteste, es posible que deba pausar la hora
de cálculo del contrato de nivel de servicio, de modo que el tiempo que pase esperando no
afecte a la hora de cálculo del mismo. Por ejemplo, le promete a un cliente un tiempo de
respuesta de dos horas. Después de haber trabajado con el cliente en un caso durante 30
minutos, ponga el estado del caso en Esperando detalles durante 45 minutos. Cuando se
reanude el temporizador, solo 30 minutos contarán en el cálculo del contrato de nivel de
servicio.

Cuando crea un contrato de nivel de servicio mejorado, puede definir los estados de pausa y
reanudación de un contrato de nivel de servicio específico. A continuación, puede poner un
caso en espera. Para configurar estados específicos para los casos en pausa, vaya
a Configuración > Administración de servicio y, a continuación, en la sección Términos del
servicio, seleccione Opciones de configuración del servicio. Aquí puede especificar si su
organización usa la funcionalidad del contrato de nivel de servicio. También puede definir los
estados que se considerarán estados de pausa para cada entidad que se haya configurado para
poder usarla con los contratos de nivel de servicio.

CONTROL DE TEMPORIZADOR

Desde la página de personalización del formulario, puede agregar un control de temporizador

en cualquier entidad para proporcionar información de cuenta regresiva para cualquier KPI
que se haya definido en esa entidad. Cuando se agrega un control de temporizador, puede
configurar la siguiente información:

 Campo de hora erróneo: se usa para definir el campo basado en la fecha y hora que
debe usarse para calcular el éxito o el error (por ejemplo, el campo Creado en ).
(Necesario)

 Condición de éxito: se usa para definir el campo y el valor de campo que determina
una resolución exitosa (por ejemplo, una configuración Sí para la opción Primera
respuesta enviada ). (Necesario)

 Condición de error: se usa para definir el campo y el valor de campo que determina un
error en ese momento (por ejemplo, una configuración No para la opción Primera
respuesta enviada ).

 Condición de advertencia: se usa para definir el campo y el valor de campo que

determina cuándo se debe activar una advertencia.

 Condición de cancelación: se usa para definir el campo y el valor de campo que

determina cuándo se debe cancelar el temporizador (por ejemplo, un valor
de Resuelto para el campo Razón para el estado).
  Condición de pausa: se usa para definir el campo y el valor de campo que determina
cuándo se debe cancelar el temporizador (por ejemplo, un valor de Esperando
detalles para el campo Razón para el estado).

Puede agregar y definir controles de temporizador siempre que necesite capacidades de

cuenta regresiva. El temporizador cambiará de color para reflejar los diferentes estados. Por
ejemplo, puede cambiar de verde a amarillo para indicar las advertencias o a rojo para indicar
los errores.

Información general sobre la administración del conocimiento

La administración del conocimiento es el proceso de creación, gestión, uso e intercambio de
conocimientos e información en una organización. El objetivo de cualquier solución de
administración del conocimiento es aprovechar lo más posible la información de que dispone
la organización y facilitar al máximo el consumo de esa información.

El módulo Administrador de conocimientos de Dynamics 365 permite a las organizaciones

proporcionar información a sus empleados y clientes mediante la creación y administración de
los artículos de conocimientos que las personas podrían buscar.

Los artículos de conocimientos pueden abordar cualquier cantidad de problemas que los
clientes o los empleados puedan tener al usar los productos o servicios de una organización.
Los tipos de artículos de conocimientos pueden incluir soluciones a problemas comunes,
documentación sobre productos o características, respuestas a las preguntas más frecuentes
(FAQ) e informes sobre productos. Las organizaciones pueden usar el editor de texto
enriquecido proporcionado para crear artículos de conocimientos, dar formato a su contenido
e integrar vídeos o imágenes, entre otras tareas.

La solución de administración del conocimiento permite:

 Crear y diseñar artículos de conocimientos: con el editor de texto enriquecido, podrá

crear contenido enriquecido y con el formato correcto para mensajes de correo
electrónico y artículos de conocimientos.

 Gestionar el ciclo de vida de los artículos: con los flujos de procesos de negocio listos
para usar, podrá gestionar el ciclo de vida de los artículos o crear otros procesos.

 Gestionar el historial de versiones de los artículos: podrá administrar las

actualizaciones de los artículos sin necesidad de interrumpir la visualización de los
artículos publicados.

 Traducir los artículos: podrá ofrecer traducciones de los artículos a varios idiomas.

 Publicar los artículos: podrá publicar los artículos tan pronto como se aprueben o
programar su publicación en un momento posterior. También puede establecer las
fechas de vencimiento de los artículos.

 Seguir los artículos y analizar sus estadísticas: podrá seguir cuántas veces se ha usado,
consultado o enviado a algún cliente cada artículo.

ARTÍCULOS DE CONOCIMIENTOS DE DYNAMICS 365

Los artículos de conocimientos se crean en el Centro de Dynamics 365 Customer Service. Las
funciones de administración del conocimiento que incluye le ofrecen flexibilidad para
implementar su propia solución de administración del conocimiento adaptada a las
necesidades de su organización. Aunque admite un alto grado de configuración, se distribuye
con un proceso de administración del conocimiento predefinido para ayudar a comenzar.

En la imagen siguiente se muestra un ejemplo del proceso predeterminado para crear y usar
artículos de conocimientos en el Centro de servicio al cliente.

1. El proceso comienza con un artículo que se crea y se marca para su revisión.

2. Un revisor evalúa el contenido del artículo y puede aprobarlo o rechazarlo.

3. Si se rechaza el artículo:

 Se devuelve al autor del artículo original para que realice ediciones o

actualizaciones.

 El proceso se repite hasta que el artículo finalmente se aprueba.

4. Si el artículo se aprueba:

1. Está publicado y disponible para su utilización

 En un portal de empresa

 Desde dentro de la interfaz de Dynamics 365

 En registros de casos en los que trabajan los agentes

 Está disponible en la búsqueda y además se puede traducir.

Como se mencionó anteriormente, una organización puede tener pasos de procesos para
aprobaciones específicos con el fin de reflejar requisitos comerciales específicos. Existe la
posibilidad de utilizar elementos como workflows o flow para automatizar el traspaso y la
notificación a personas específicas que participan en el proceso de aprobación.

CREAR Y DEFINIR ARTÍCULOS DE CONOCIMIENTOS

Una solución efectiva de administración del conocimiento es más que un mero repositorio de
problemas y soluciones. Debe ofrecer una navegación sencilla, proporcionar soluciones claras
y concisas, presentar información actualizada y pertinente y ser de fácil acceso desde todas las
plataformas.
Al prepararse para crear un repositorio de conocimientos y definir los artículos de
conocimientos específicos, es importante entender la visión global del repositorio. A
continuación enumeramos algunas preguntas que conviene responder:

 ¿Para qué se utilizará el artículo?

 ¿Quién consumirá el artículo?

 ¿Qué se debe incluir el artículo para que resulte de máxima utilidad a quienes lo
consuman?

 ¿El artículo está relacionado con un producto específico?

 ¿El artículo deberá estar disponible en varios idiomas? En caso afirmativo, ¿en qué
idiomas?

 ¿El artículo está sujeto a limitaciones temporales?

Esta lista representa tan solo algunos de los aspectos que es preciso tener en cuenta. Cada
organización tendrá requisitos específicos que se deban cumplir.

La herramienta proporciona diversas opciones que le ayudarán a crear y administrar los

artículos de acuerdo con los requisitos de su organización. Cuenta con un editor de texto
enriquecido que permite incluir elementos como imágenes y vídeos en los artículos. Esto
ayuda a explicar mejor las cosas y hace que los artículos sean más atractivos. Además, puede
escribir, editar, buscar, publicar y traducir los artículos de tal forma que sean más eficaces y
pertinentes para su público.

CREACIÓN DE ARTÍCULOS

Los artículos de conocimientos se crean en el Centro de servicio al cliente o en el Customer

Service workspace. Los puede crear cualquier persona que tenga el permiso específico para
hacerlo. Además de especificar quién puede crear los artículos, la organización puede designar
a las personas encargadas de aprobarlos.

Pestaña Contenido

La primera vez que se crea un artículo, debe especificar la información siguiente en la

sección Contenido del artículo de la pestaña Contenido:

 Título: el título comunica el asunto y el propósito del artículo de manera concisa.

 Palabras clave: las palabras clave se usan para buscar artículos en la knowledge base.
Separe las palabras clave entre sí mediante comas.

 Descripción: la descripción es un resumen breve del artículo. Este texto aparece en los
resultados de la búsqueda y se utiliza para optimizar los motores de búsqueda.

Una vez que guarde el artículo de conocimientos, se mostrará el vínculo Ver descripción y
palabras clave sugeridas. Al hacer clic en este vínculo, aparecerá un cuadro de diálogo que
incluye palabras clave y una descripción sugerida.
Según el contenido analizado, se mostrarán varias sugerencias de palabras clave. Seleccione
una por una las palabras clave que desee, o puede seleccionar para insertar todas las palabras
clave sugeridas. Las palabras clave tienen una limitación de 4000 caracteres en total. Se le
proporcionará una descripción sugerida. Puede editar la descripción antes de aplicar los
cambios sugeridos. Las descripciones tienen una limitación de 155 caracteres en total.

DISEÑAR EL CONTENIDO DEL ARTÍCULO

Al diseñar un artículo de conocimientos, es preciso asegurarse de que el contenido no solo sea

pertinente para las personas que harán uso de él, sino también que sea fácil de consultar, de
tal forma que el usuario asimile plenamente todo el contenido presentado. Por ejemplo,
puede agregar un vínculo a un vídeo que demuestre el procedimiento o proceso presentado,
vínculos a otros contenidos pertinentes o HTML integrado para ofrecer un contenido más
dinámico. El diseñador de contenido admite estas características de diseño avanzadas y mucho
más.

El editor de contenido se encuentra en la sección Contenido. Consta de tres pestañas:

 Diseñador: permite escribir y editar el contenido del artículo. Esta pestaña incluye
funciones de edición de texto enriquecido y mejorado.

 HTML: muestra una vista previa del contenido del artículo en formato HTML. También
puede escribir y editar el artículo en esta pestaña.

 Vista previa: muestra el aspecto que tendrá el contenido en diversos dispositivos,

como un equipo de sobremesa, una tableta o un dispositivo móvil.
AGREGAR UN ARCHIVO ADJUNTO A UN ARTÍCULO DE CONOCIMIENTOS

Cuando esté creando un artículo de conocimientos, es posible que desee adjuntar archivos
para ayudar a proporcionar información completa a sus clientes. Por ejemplo, tiene algunas
instrucciones detalladas almacenadas en un documento de Word que desea utilizar como
parte del artículo. Puede agregar archivos adjuntos en la pestaña Contenido con la
opción Adjuntar archivos desde.

Puede seleccionar Archivos en las siguientes ubicaciones:

 Mi dispositivo: le permite seleccionar archivos que están almacenados en su

dispositivo local.

 Cargas anteriores: abre un panel de búsqueda donde puede buscar y seleccionar

archivos que se cargaron previamente.

Debe guardar el artículo antes de poder adjuntar los archivos a él. Si bien no hay límite para la
cantidad de artículos que puede adjuntar a un artículo de conocimientos, el archivo adjunto no
puede superar los 32 MB.

En la sección Archivos adjuntos se muestran los archivos adjuntos del artículo de

conocimientos en una vista de mosaico horizontal sobre su mensaje. La configuración
predeterminada para la cantidad máxima de archivos que se pueden mostrar es de cinco
archivos adjuntos antes de que se muestre la funcionalidad de avance de página.

Para los archivos adjuntos, use los siguientes comandos:

 Seleccionar: le permite seleccionar uno o varios archivos adjuntos. Para ello, debe
hacer clic en el cuadro que aparezca en los archivos adjuntos. También
puede Eliminar o Descargar los archivos seleccionados.

 Ordenar: le permite ordenar los registros según un filtro específico, como el nombre o
el tamaño del archivo.

Al publicar un artículo de conocimientos, si le ha adjuntado archivos, los usuarios de estos

artículos podrán acceder a los archivos adjuntos a través de Búsqueda de conocimientos.

Pestaña Resumen

La pestaña Resumen incluye mucha otra información que es pertinente para el artículo de
conocimientos. El sistema actualiza gran parte de esta información a medida que se realizan
cambios en el artículo. Sin embargo, parte de ella se puede editar. A continuación, encontrará
los dos campos principales que podría tener que actualizar:

 Interno: puede marcar el artículo de forma que sea exclusivamente para uso interno.
En tal caso, las personas ajenas a su organización no podrán obtener acceso al artículo
(por ejemplo, desde un portal). Este ajuste puede resultar útil para artículos que se
centran más en los procesos internos y no son pertinentes para los usuarios externos.

 Razón para el estado: permite especificar el estado del artículo para indicar si se ha
propuesto o está en revisión a la espera de revisión.

Parte de la información de la pestaña Resumen no aparece hasta que el registro de artículo se

guarda por primera vez. Por ejemplo, Información relacionada y Escala de tiempo son sendos
paneles importantes que pasan a estar disponibles cuando se guarda el registro por primera
vez.

 Escala de tiempo: este panel muestra todas las actividades asociadas al artículo de
conocimientos. También puede agregar actividades directamente al registro.

 Información relacionada: este panel proporciona acceso a los registros relacionados

con el artículo de conocimientos o asociados a él. Puede abrir los siguientes registros
mediante los botones situados junto al extremo derecho de este panel:

o Versiones relacionadas: este registro muestra un historial completo de las

versiones del artículo. Puede ver las versiones anteriores del artículo e incluso
volver a una versión anterior si es necesario.

o Traducciones relacionadas: este registro muestra una lista de las distintas

traducciones que están disponibles para el artículo.

o Categorías relacionadas: este registro muestra las categorías con las que está
asociado el artículo. Las categorías se utilizan para los análisis y la ubicación
del artículo. Ayudan a proporcionar una mejor organización del artículo
cuando los artículos se usan en una knowledge base del portal.
 o Artículos relacionados: este registro muestra cualquier artículo similar al
artículo o que se haya relacionado con él.

o Productos relacionados: este registro muestra los productos con los que está
asociado el artículo.

CICLO DE VIDA DE LOS ARTÍCULOS DE CONOCIMIENTOS

Tal y como se ha mencionado anteriormente, un ciclo de vida eficiente de la administración del

conocimiento y la aprobación de artículos permite garantizar no solo que el contenido del
conocimiento sea preciso, sino también que los usuarios dispongan del contenido más actual y
pertinente. De entrada, el ciclo de vida de la administración del conocimiento tiene un aspecto
similar al de la siguiente imagen.

 Borrador: el proceso lo inicia una persona, como un representante del servicio al

cliente, que crea y propone una versión de borrador de un artículo.

o Un aprobador marca el artículo para revisión.

 Aprobado o rechazado: un revisor evalúa el contenido del artículo y puede aprobar o

rechazar el artículo.

o Si el artículo logra el estado Rechazado:

  Se devuelve al autor del artículo original para que realice ediciones o
actualizaciones.

 El proceso se repite hasta que el artículo finalmente se aprueba.

o Si el artículo logra el estado Aprobado:

 El artículo se establece en un estado de aprobación y está listo para

publicarse.

 Programado: el artículo se programa para publicarse. Se proporciona información de

las fechas, como las de publicación y expiración.

o El artículo se establece en un estado Programado hasta que se alcanza la fecha

de publicación.

 Publicado: una vez que se alcanza la fecha de publicación del artículo, este pasa al
estado Publicado. Los artículos publicados están disponibles en:

o En registros de casos en los que trabajan los agentes

o Portales orientados al cliente

 Expirado: los artículos que alcanzan la fecha de expiración establecen su estado

en Expirado.

Un artículo de conocimientos puede someterse a muchas revisiones, aprobaciones y revisiones

durante el ciclo de vida. En muchos casos, después de que un artículo de conocimientos expire,
retrocede al proceso de otras aprobaciones para volverse a publicar.

Borrador

Una vez creado el contenido del artículo, este debe revisarse para garantizar que sea preciso.
Los artículos de conocimientos se pueden revisar de dos maneras:

 Marcado para revisión: los artículos que están marcados para revisión comienzan a
mostrarse en el panel Administrador de conocimientos.

 Asignado directamente: los artículos se pueden asignar directamente a personas

específicas o a una cola.

Los usuarios que necesitan aprobar artículos de conocimientos deben tener permisos
para Aprobar para el tipo de registro del artículo de conocimientos.

Cuando un artículo está marcado para revisión, aparecerá en la vista Los artículos borrador
necesitan revisión. El administrador de conocimientos puede luego asignar el artículo a
miembros específicos del equipo o una cola para su revisión.
Revisar un artículo de conocimientos y rechazarlo o aprobarlo

Los artículos de conocimientos deben revisarse para que sean precisos antes de que se
publiquen o se pongan a disposición de otras personas. Cuando un artículo requiere una
revisión, un revisor puede realizar las siguientes acciones:

 Seleccionar un artículo que esté asignado para su revisión.

 Sugerir comentarios de revisión.

 Aprobar el contenido del artículo.

Existen varias formas de agregar comentarios y sugerencias a un artículo. En primer lugar, las
notas se pueden agregar directamente a un artículo en el panel Escala de tiempo de la
pestaña Resumen. Después de agregar una nota, esta aparece en la escala de tiempo.
Además, los comentarios de los artículos se pueden agregar a los artículos en borrador, a los
artículos aprobados o incluso a los artículos publicados que se usan actualmente. Los
comentarios permiten a las personas hacer acciones como, por ejemplo, agregar comentarios
que sugieran ediciones específicas o proporcionar una clasificación general para un artículo.

Los comentarios de los artículos se pueden agregar y ver en el panel Comentarios de la

pestaña Análisis. A medida que se capturan los comentarios, se pueden definir clasificaciones.
El campo Clasificación muestra la clasificación actual del artículo. El valor de este campo se
vuelve a calcular según una programación predefinida, pero puede desencadenar
manualmente un nuevo cálculo en cualquier momento. Para ello, seleccione el icono de la
calculadora en el campo Clasificación.
Una buena forma de asegurarse de que los artículos estén actualizados y sean precisos es
actualizarlos, a partir de los comentarios y notas del artículo que reciba. Después de actualizar
un artículo, puede asignarlo de nuevo al revisor para que lo apruebe o publique.
Seleccione Asignar en la barra de comandos y, a continuación, elija el usuario o el equipo al
que quiere asignar al artículo.

Una vez que el aprobador del artículo cree que el artículo está listo para su publicación, el
aprobador puede aprobarlo seleccionando el botón Aprobar botón en la barra de comandos.
El artículo está listo para publicarse.

ADMINISTRAR LAS VERSIONES, CATEGORÍAS Y TRADUCCIONES DEL ARTÍCULO DE CONOCIMIENTOS

A medida que compila su repositorio de conocimientos, puede que observe que los artículos
que están en desarrollo, o incluso los artículos que ya se han publicado, requieren
actualizaciones para reflejar las nuevas funciones o una nueva forma de ejecutar un
procedimiento. A medida que se realizan esas actualizaciones, se almacenan las versiones
anteriores del artículo.

El control de versiones del artículo permite a las organizaciones administrar las actualizaciones
de los artículos de conocimientos sin necesidad de interrumpir la visualización de los artículos
publicados. Al almacenar versiones de un artículo de conocimiento, puede mantener los
artículos actualizados con la información más reciente, pero también hacer un seguimiento de
los cambios a lo largo del ciclo de vida de sus productos y servicios.

Se pueden crear dos tipos de versiones para los artículos de conocimientos:

 Versión principal: este tipo de versión representa un cambio importante en

características o funcionalidades.

Por ejemplo, una nueva característica que se ha agregado a una aplicación de software cambia
completamente la funcionalidad de la aplicación.

 Versión secundaria: este tipo de versión representa un cambio menor que no

necesariamente afecta a la funcionalidad.
Por ejemplo, una pantalla de la interfaz de usuario de una aplicación cambia, pero el resultado
general de la pantalla no se ve afectado.

Para agregar versiones principales y secundarias, use la barra de comandos de la página en la

que define el título, las palabras clave y la información detallada del artículo. Cuando se crea
una versión por primera vez, tiene el mismo contenido, información y permisos que la versión
actual. A continuación, puede revisar y actualizar la información de la nueva versión. El artículo
incluirá los campos Número de versión principal y Número de versión secundaria que se
actualizan automáticamente para reflejar el nuevo número de versión.

Traducción de artículos en varios idiomas

Todos sus clientes también deben poder consumir con facilidad los artículos que crea, así
como acceder a ellos fácilmente, independientemente de su país o región. Dynamics 365 le
permite crear artículos traducidos, para que pueda proporcionar el mismo contenido de
autoayuda en varios idiomas, pero sin tener que administrar varias copias del mismo artículo.
Por ejemplo, un artículo de conocimiento que explica cómo reemplazar un cartucho de
impresora puede tener versiones en español, francés e hindi. Esas versiones traducidas se
pueden enviar por correo electrónico a los clientes que hablan esos idiomas.

Cuando un artículo se traduce a otro idioma, Dynamics 365 crea una nueva versión principal
asociada a dicho idioma.
Por ejemplo, para crear una versión en francés de un artículo de conocimiento, seleccione el
botón Traducir desde en la barra de comandos y, luego, seleccione Francés en la lista de
idiomas disponibles.

Importante

Al crear una versión de un artículo para otro idioma, el artículo realmente no se traduce a
dicho idioma. Debe proporcionar el texto traducido y formateado para el artículo.

Categorías de los artículos

Al asociar un artículo con una o varias categorías, permite que el artículo se pueda buscar y
consumir más fácilmente en diferentes áreas de la aplicación. Los usuarios pueden aprovechar
las categorías de los artículos cuando buscan un artículo directamente desde un caso. Las
categorías de los artículos también se pueden usar para organizar artículos cuando los usuarios
acceden a ellos a través de un portal de clientes.

Para crear categorías para los artículos, vaya a la aplicación del centro de administración de
Customer Service y, luego, en la sección Administración, seleccione Categorías. También
puede definir jerarquías de categorías, como Hardware > Impresoras > Tambores y rodillos. De
esta manera, puede crear una jerarquía de artículos para categorías específicas.

Para agregar una categoría a un artículo, seleccione Asociar categoría en la barra de

comandos. Un único artículo puede asociarse a varias categorías.