TFG Gonzalez Gines 2022

Universidad de Alcalá
Escuela Politécnica Superior
GRADO EN INGENIERÍA TELEMÁTICA
Trabajo Fin de Grado
Desarrollo de sistema de gestión de incidencias con la

herramienta de CRM Salesforce, a través de varios canales.
Autor: Alba González Ginés
Tutora: Elisa Rojas Sánchez
2022
UNIVERSIDAD DE ALCALÁ
GRADO EN INGENIERÍA TELEMÁTICA
Trabajo Fin de Grado

Desarrollo de sistema de gestión de incidencias con la herramienta de
CRM Salesforce, a través de varios canales.
Autor: Alba González Ginés
Tutora: Elisa Rojas Sánchez
TRIBUNAL:
Presidente: Antonio García Herráiz
Vocal 1º: Juan Antonio Rodrigo Yanes
Vocal 2º: Bernardo Alarcos Alcázar
FECHA: 30/06/2022
Agradecimientos
A mi familia,
por confiar en mi desde el primer momento.
A mis amigos y pareja,
por ser mi punto de apoyo constante.
Me gustaría agradecer a mi tutora, Elisa Rojas Sánchez, por el empuje, la paciencia y las
ganas que has puesto a la finalización de este proyecto. Viendo la tendencia debido a mi
trabajo se dificultaba el avanzar y no tiraste la toalla. Gracias por inyectarme esas ganas
cuando las necesitaba.
También quisiera agradecer a mi profesor José Luis Lázaro que me enseñó y apoyó tanto
durante toda mi carrera. Me dio la fuerza necesaria como para tirar adelante con todo a
pesar de lo complicado.
A mi familia, en particular a mi madre que ha sido mi punto de apoyo principal. En

realidad, ni ella ni yo creemos que este vaya a ser el fin de esta etapa tan bonita y dura de
mi vida. Gracias infinitas por enseñarme que, con esfuerzo, todo se consigue.
Por último, a mis amigos, en concreto a mi amiga Lucía Zujeros. Ha sido la persona que
más veces me ha escuchado decir no puedo y más veces me ha dicho puedes con todo.
Gracias por estar conmigo en esta carrera de fondo apoyándome al máximo y siendo
partícipe de mis alegrías y mis decepciones.
ÍNDICE
I. Introducción ....................................................................................................... 4
1.1 Objetivo del proyecto............................................................................................ 7
1.2 Estructura del documento ..................................................................................... 8
II. ESTADO DEL ARTE .............................................................................................. 9
2.1 Historia del CRM ................................................................................................... 9
2.2 ¿Qué es la nube? ................................................................................................. 14
2.3 Salesforce ........................................................................................................... 15
2.3.1 Nubes de Salesforce ........................................................................................................... 15
2.3.1 Licenciamiento ................................................................................................................... 18
2.4 Oracle ................................................................................................................. 19
2.4.1 Nubes de Oracle ................................................................................................................. 19
2.4.1 Licenciamiento ................................................................................................................... 20
2.5 SAP ..................................................................................................................... 21
2.5.1 Nubes de SAP ..................................................................................................................... 22
2.5.2 Licenciamiento ................................................................................................................... 23
2.6 Ventajas sobre la utilización CRM en la nube....................................................... 23
2.7 Historia de los asistentes de voz .......................................................................... 25
2.8 Alexa ................................................................................................................... 29
2.8.1 ¿Qué es una Skill? .............................................................................................................. 29
2.8.2 Dispositivos Echo ............................................................................................................... 29
2.9 Google Assistant ................................................................................................. 32
2.9.1 ¿Qué es una acción? .......................................................................................................... 32
2.9.2 Dispositivos de Google Home ............................................................................................ 32
III. Análisis y diseño ........................................................................................... 35
3.1 Salesforce ........................................................................................................... 35
3.2 Amazon Web Services ......................................................................................... 37
3.3 Alexa Skills Kit ..................................................................................................... 38
IV. Implementación y Desarrollo........................................................................ 40
4.1 Implementación de Salesforce ............................................................................ 41
4.1.1 Modelo de datos ................................................................................................................ 41
4.1.2 Configuración de seguridad ............................................................................................... 55
4.1.3 Interfaz de usuario ............................................................................................................. 59
4.1.4 Configuración de Omnichannel.......................................................................................... 64
4.1.5 Configuración de asignación de Casos ............................................................................... 69
4.1.6 Configuración canales ........................................................................................................ 69
4.2 Desarrollo de skill de Alexa ................................................................................. 77
4.2.1 Configuración de la skill ..................................................................................................... 79
4.2.2 Configuración de Salesforce............................................................................................... 90
4.2.3 Función lambda ................................................................................................................. 91
V. EVALUACIÓN .................................................................................................... 96
5.1 Valoración de usuarios del sistema ................................................................... 101
VI. CONCLUSIONES .......................................................................................... 102
VII. BIBLIOGRAFÍA ............................................................................................ 104
VIII. REFERENCIAS.............................................................................................. 105
IX. ANEXO ....................................................................................................... 106
9.1 Data import....................................................................................................... 106
9.2 Data export ....................................................................................................... 110
ÍNDICE DE ILUSTRACIONES
FIGURA 1: PHILIP KOTLER, CATEDRÁTICO DE MARKETING INTERNACIONAL [1] .............................................................. 4
FIGURA 2: LOGOS DE CRM EN ESTUDIO [2] ........................................................................................................... 6
FIGURA 3: DISPOSITIVO DE ASISTENTE DE VOZ, ALEXA [3] ......................................................................................... 7
FIGURA 4: BASE DE DATOS EN LA ÉPOCA DE LOS 80 (HISTORIA DEL CRM) .................................................................... 9
FIGURA 5: TARJETEROS ROLODEX [5] ................................................................................................................. 10
FIGURA 6: MIKE MUNHEY Y PAT SULLIVAN, FUNDADORES DE ACT [6] ..................................................................... 10
FIGURA 7: COFUNDADORES DE ORACLE [7] ......................................................................................................... 11
FIGURA 8: SOCIOS FUNDADORES DE SAP [8] ....................................................................................................... 12
FIGURA 9: THOMAS SIEBEL [9] .......................................................................................................................... 13
FIGURA 10: MARC BENIOFF, FUNDADOR DE SALESFORCE [10] ................................................................................ 14
FIGURA 11: LOGO OFICIAL DE LAS NUBES DE SALESFORCE. [11] ............................................................................... 16
FIGURA 12: LOGO DE LA NUBE DE VENTAS [12] .................................................................................................... 16
FIGURA 13: LOGO DE LA NUBE DE SERVICIOS [13]................................................................................................. 16
FIGURA 14: LOGO DE LA NUBE DE MARKETING [14] .............................................................................................. 17
FIGURA 15: LOGO DE LA NUBE DE COMUNIDADES [15] .......................................................................................... 17
FIGURA 16: LOGO DE LA NUBE DE VENTAS DE SAP [16] ......................................................................................... 22
FIGURA 17: LOGO DE LA NUBE DE SERVICIOS DE SAP [17] ...................................................................................... 22
FIGURA 18: LOGO DE LA NUBE DE MARTKETING DE SAP [18] .................................................................................. 23
FIGURA 19:IMAGEN DE (AUDREY) [19] .............................................................................................................. 25
FIGURA 20: IMAGEN DE (SHOEBOX) [20] ............................................................................................................ 26
FIGURA 21: LOGO DE SIRI [21] ......................................................................................................................... 27
FIGURA 22: LOGO DE CORTANA [22] ................................................................................................................. 27
FIGURA 23: LOGO DE ALEXA [23] ...................................................................................................................... 28
FIGURA 24: LOGO DE GOOGLE ASSISTANT [24] .................................................................................................... 28
FIGURA 25: ECHO DE AMAZON [25] .................................................................................................................. 30
FIGURA 26: ECHO PLUS DE AMAZON [26]........................................................................................................... 30
FIGURA 27: ECHO DOT DE AMAZON [27] ........................................................................................................... 31
FIGURA 28: ECHO SPOT DE AMAZON [28] .......................................................................................................... 31
FIGURA 29: GOOGLE HOME [29] ...................................................................................................................... 33
FIGURA 30: GOOGLE HOME MINI [30] ............................................................................................................... 33
FIGURA 31: GOOGLE NEST AUDIO [31] .............................................................................................................. 34
FIGURA 32: GOOGLE NEST HUB [32] ................................................................................................................. 34
FIGURA 33: MODELO DE DATOS ........................................................................................................................ 37
FIGURA 34: CONSOLA DE AWS ......................................................................................................................... 38
FIGURA 35: ALEXA DEVELOPER CONSOLE ............................................................................................................ 39
FIGURA 36: PROCESO DE SOPORTE ..................................................................................................................... 41
FIGURA 37: CONFIGURACIÓN DE CUENTAS PERSONALES ......................................................................................... 42
FIGURA 38: FORMATO DE PÁGINA DE CUENTAS PERSONALES ................................................................................... 44
FIGURA 39: FORMATO DE PÁGINA DE CASOS ........................................................................................................ 45
FIGURA 40: ACTIVACIÓN DE PEDIDOS ................................................................................................................. 46
FIGURA 41: FORMATO DE PÁGINA DE PEDIDOS ..................................................................................................... 47
FIGURA 42: FORMATO DE PÁGINA DE LÍNEA DE PEDIDO .......................................................................................... 48
FIGURA 43: FORMATO DE PÁGINA DE PRODUCTO .................................................................................................. 49
FIGURA 44: FORMATO DE PÁGINA DE ENTRADAS DE LISTA DE PRECIOS ....................................................................... 49
FIGURA 45: FORMATO DE PÁGINA DE CATÁLOGO .................................................................................................. 50
FIGURA 46: CREACIÓN DE PROCESO DE SOPORTE DE INCIDENCIAS Y CONSULTAS ........................................................... 50
FIGURA 47: CREACIÓN DE PROCESO DE SOPORTE DE SUGERENCIAS ........................................................................... 51
FIGURA 48: SELECCIÓN DE ESTADOS DE PROCESO DE SOPORTE DE INCIDENCIAS Y CONSULTAS ......................................... 51
FIGURA 49: SELECCIÓN DE ESTADOS DE PROCESO DE SOPORTE DE SUGERENCIAS .......................................................... 51
FIGURA 50: CONFIGURACIÓN TIPO DE REGISTRO INCIDENCIAS Y CONSULTAS ............................................................... 52
FIGURA 51: CONFIGURACIÓN TIPO DE REGISTRO DE SUGERENCIAS ............................................................................ 52
FIGURA 52: PANTALLA DE INICIO DE CONFIGURACIÓN DEL FLOW .............................................................................. 53
FIGURA 53: PANTALLA DE CONFIGURACIÓN DE DECISIÓN EN EL FLOW ........................................................................ 54
FIGURA 54: PANTALLA DE OBTENCIÓN DE TIPO DE REGISTRO ................................................................................... 54
FIGURA 55: PANTALLA DE MODIFICACIÓN DE REGISTROS ........................................................................................ 55
FIGURA 56: FLOW DE ASIGNACIÓN DE TIPOS DE REGISTRO....................................................................................... 55
FIGURA 57: JERARQUÍA DE ROLES EN SALESFORCE ................................................................................................. 58
FIGURA 58: PANTALLA DE INICIO EN CONSOLA DE SALESFORCE................................................................................. 60
FIGURA 59: CONFIGURACIÓN DE APLICACIÓN DE CONSOLA I .................................................................................... 60
FIGURA 60: CONFIGURACIÓN DE APLICACIÓN DE CONSOLA II ................................................................................... 61
FIGURA 61: CONFIGURACIÓN DE APLICACIÓN DE CONSOLA III .................................................................................. 61
FIGURA 62: CONFIGURACIÓN DE APLICACIÓN DE CONSOLA IV .................................................................................. 62
FIGURA 63: VISTA DE CONSOLA DE SERVICIO CON REGISTRO ABIERTO ........................................................................ 62
FIGURA 64: PÁGINA DE REGISTRO DE CUENTAS PERSONALES.................................................................................... 63
FIGURA 65: CONFIGURACIÓN DE LA COLAS DEL OBJETO CASOS ................................................................................. 64
FIGURA 66: PANTALLA DE CONFIGURACIÓN DE CANALES DE SERVICIO ........................................................................ 65
FIGURA 67: CONFIGURACIÓN DE ESTADO DE SERVICIO EN LÍNEA ............................................................................... 66
FIGURA 68: CONFIGURACIÓN DE ESTADO DE PRESENCIA OCUPADO ........................................................................... 66
FIGURA 69: PANTALLA DE CONFIGURACIÓN DE PRESENCIA ...................................................................................... 67
FIGURA 70: PANTALLA DE CONFIGURACIÓN DE ENRUTAMIENTO ............................................................................... 68
FIGURA 71: PANTALLA DE CONFIGURACIÓN FINAL DE COLA ASOCIADA A OMNICHANNEL ............................................... 68
FIGURA 72: CONFIGURACIÓN DE REGLAS DE ASIGNACIÓN DE CASOS .......................................................................... 69
FIGURA 73: PANTALLA DE CREACIÓN DE CUENTA DE GOOGLE ................................................................................... 70
FIGURA 74: PANTALLA DE CONFIGURACIÓN DE EMAIL-TO-CASE ................................................................................ 71
FIGURA 75: CORREO DE VERIFICACIÓN DE CREACIÓN DE EMAIL-TO-CASE .................................................................... 72
ÍNDICE DE TABLAS
TABLA 1: LICENCIAS DE LAS PRINCIPALES NUBES DE SALESFORCE ............................................................................... 18
TABLA 2: LICENCIAS DE LA NUBE DE MARKETING DE SALESFORCE ............................................................................. 19
TABLA 3: LICENCIAS ORACLE SALES CLOUD .......................................................................................................... 21
TABLA 4: LICENCIAS ORACLE SERVICE CLOUD ....................................................................................................... 21
TABLA 5: CAMPOS DEL OBJETO CUENTA PERSONAL ................................................................................................ 43
TABLA 6: CAMPOS DEL OBJETO CASO .................................................................................................................. 44
TABLA 7: CAMPOS DEL OBJETO PEDIDO ............................................................................................................... 46
TABLA 8: CAMPOS DE LÍNEA DE PEDIDO .............................................................................................................. 48
TABLA 9: CAMPOS DE PRODUCTO ...................................................................................................................... 48
TABLA 10: CAMPOS DE ENTRADA DE LISTA DE PRECIOS ........................................................................................... 49
TABLA 11: CAMPOS DE OBJETO CATÁLOGO .......................................................................................................... 49
TABLA 12: TABLA DE VISIBILIDAD DE OBJETOS DE SALESFORCE ................................................................................. 57
TABLA 13: DEFINICIÓN DE SLOTS UTILIZADOS EN LA SKILL ........................................................................................ 82
TABLA 14: CASOS DE USO DE USUARIOS FINALES ................................................................................................... 97
Resumen
El presente trabajo de final de grado titulado “Desarrollo de sistema de gestión de

incidencias con la herramienta de CRM Salesforce, a través de varios canales”, realiza el
diseño y desarrollo de un sistema de gestión en la nube que permita a una empresa tener
una gestión centralizada de información de clientes e incidencias. Se propone tener
canales de entrada de incidencias como un buzón de email, un formulario web y la
integración con el dispositivo Alexa.
La empresa en la que se basa este trabajo de final de grado es una empresa ficticia cuyo
punto de partida es un sistema de gestión de información obsoleto (Excel, email y papel).
El objetivo principal del proyecto es proporcionar a la empresa un sistema de gestión

centralizado que facilite la gestión de incidencias, y, por consiguiente, verificar que el
nivel de satisfacción de los clientes incrementa, además de que los tiempos de los agentes
que utilicen el sistema disminuye de tal manera que se vuelve más productivo.
1
Abstract
This final degree project entitled “Development of an incident management system with
Salesforce”, performs the design and development of a Cloud management system that
allows a company to have a centralized management for customer information and their
incidents, doubts and suggestions. It is proposed to have different case entry channels
such as email, web and the Alexa device.
The company on which this final degree project is based is a fictitious company whose
starting point is an obsolete information system comprised of excel, email and paper
notes.
The main objective of this project is to provide the company with a centralized
information system that facilitates the management of incidents, doubts or suggestions of
their customers, and, consequently, verify that are the customer satisfaction level
increases, in addition to the fact that the time of the agents thar are using the system
decreases in such a way they become more productive.
2
Glosario y abreviaturas
• API: Es la interfaz de programación de aplicaciones que se usa para integrar
softwares de diferentes aplicaciones.
• CRM: Sistema a través del cual se puede establecer una relación personalizada
con los clientes o clientes potenciales de una empresa
• CTI: Sistema que permite la integración de ordenadores con sistemas de telefonía.
• Enterprise contracts: Funcionalidad que permite mejorar el proceso de
contratación estándar aportando rapidez en las búsquedas, renovaciones y
visibilidad de los contratos dentro del CRM
• ERP: Software que se utiliza para almacenar información o gestionar acciones
comerciales, de facturación o contractuales en una empresa.
• Forecast: pronóstico
• Hashtags: Define una palabra que es clave y lo convierte en vínculo, permitiendo
así exportar toda la información referente a dicha palabra.
• Journey: Funcionalidad que permite construir relaciones estrechas con el cliente
respondiendo a la actividad de un cliente durante su ciclo de vida
• Knowledge: Funcionalidad que permite tener una base de datos de preguntas
frecuentes de Salesforce
• Oracle Voice: Sistema de chat a través del cual el cliente puede comunicarse con
la empresa.
• Out of the box: Funcionalidad no incluida en el paquete contratado y que puede
ser desarrollada por un tercero.
• TFG: Trabajo de final de grado
3
I. Introducción
El objetivo principal de cualquier empresa, independientemente el tamaño que tenga es
la captación y la retención de clientes. Es por esto, que uno de los factores de mayor
relevancia, es la comunicación con el cliente. Existen dos métricas por las cuales se puede
medir la fidelidad del cliente a la empresa:
• NPS, Net Promoter Score: Es la métrica orientada a la retención de clientes.
En esta métrica permite conocer si el cliente recomendase el servicio ofrecido
por la empresa a su entorno basándose en su experiencia con la misma.
• CHURN, Tasa de cancelación de clientes: Es la métrica orientada al
porcentaje de bajas que sufre una empresa de sus clientes. Esto permite la
mejora de los servicios en la empresa, pudiendo realizar un análisis de las
bajas de los clientes.
Teniendo en cuenta estas dos mediciones se puede deducir que una buena comunicación
con el cliente favorece la recomendación de la empresa y ayuda a reducir el número de
bajas de servicios, ya que se conoce la insatisfacción del cliente con respecto a los
mismos.
El establecimiento de una comunicación con el cliente que sea sencilla por diversos
canales y, que, además, en esa comunicación, el trabajador sea capaz de tratar la consulta
del cliente de manera ágil, aumenta el grado de satisfacción del cliente.
Philip Kotler, una de las referencias en el mundo del Marketing, en su libro Dirección de
Mercadotecnia, define la satisfacción del cliente como “El nivel de satisfacción es el nivel
del estado de ánimo de una persona que resulta de comparar el rendimiento percibido de
un producto o servicio con sus expectativas.” (Kotler, 1996)
Figura 1: Philip Kotler, catedrático de Marketing Internacional [1]
Abordando la definición de Philip Kotler, cualquier empresa se puede plantear la pregunta

de ¿Cómo puedo tener satisfechos a mis clientes? En este trabajo de final de grado, se
propone dar solución a esta pregunta, mejorando la comunicación entre cliente y empresa,
disminuir los tiempos de espera e incluso, incrementar el rendimiento de los trabajadores
de la empresa.
4
Las siglas CRM, Customer Relationship Management, tal y como su nombre indica, se
refiere a todo sistema o proceso a través del cual se puede establecer una relación
personalizada con los clientes o clientes potenciales de una empresa. Con este tipo de
herramientas, la empresa aumenta su rendimiento, la satisfacción del cliente e incluso,
realizando un análisis del feedback recibido por los clientes satisfechos, puede
incrementar sus ventas.
En este caso, se utilizará la definición de CRM como aplicación o programa informático

que permite tener centralizada toda la información de sus clientes, así como las
interacciones que tiene la empresa con los mismos.
En función del objetivo de la empresa, el modelo CRM se divide en tres categorías:

• CRM Operativo: Enfocado al área de ventas, marketing y servicio de atención
al cliente. Existe una subdivisión en este modelo de CRM.
o Back Office: No existe una comunicación directa con el cliente.
Enfocado al área de finanzas, contabilidad y recursos humanos de la
empresa.
o Front Office: Contacto directo con el cliente. Enfocado al envío de
campañas de marketing, gestión de contratación y gestión comercial.
• CRM Analítico: Enfocado al análisis del comportamiento del cliente a lo
largo de su contratación con la empresa. El objetivo de este tipo de CRM es
trazar una estrategia de venta en base a la tendencia del comportamiento del
cliente con respecto a la empresa.
• CRM Colaborativo: Enfocado en la mejora de comunicación con el cliente
por varios canales. El objetivo de este tipo de CRM es mejorar la relación con
el cliente y además aumentar la satisfacción del mismo.
Los tipos de CRM no solo se clasifican por su usabilidad con respecto a la empresa, sino
que en función de donde se localicen físicamente este tipo de sistemas se tiene la siguiente
clasificación:
• CRM on premise: Programa informático localizado en los servidores propios
de la empresa. En general, este tipo de aplicaciones suelen estar creadas a
medida completamente para la empresa o para un tipo de negocio en
concreto.
El espacio de almacenamiento de datos en este tipo de aplicaciones es
limitado, ya que la instalación se hace en un dispositivo físico. Es por esto,
que la instalación de estos programas es compleja ya que, las empresas
suelen tener contratado otro espacio de almacenamiento donde tienen sus
bases de datos, y es necesario realizar una integración del CRM con la base
de datos de la empresa.
En cuanto al coste de este tipo de herramientas, el usuario compra una
licencia de la herramienta que no tiene caducidad. Si la herramienta necesita
alguna actualización, el usuario asume el coste de la misma.
• CRM en la nube: Programa informático localizado en un espacio de la nube.

Este tipo de programas presentan soluciones estandarizadas, aplicables a
cualquier negocio, únicamente con las funcionalidades que vienen por
defecto. No obstante, es posible realizar cualquier customización para hacer
de algo estándar, algo customizado completamente para una empresa.
El espacio de almacenamiento en este tipo de aplicaciones no es limitado ya
que toda la información se encuentra en la nube. Dependiendo del espacio
5
que el usuario compre de la nube, podrá almacenar más o menos
información.
Por tanto, dado que el programa no se encuentra en un dispositivo físico, el
coste de instalación es nulo. Solo se necesita un ordenador con acceso a
internet.
En cuanto al coste, el usuario compra una licencia con un tiempo
determinado de validez. Si la licencia caduca, el usuario pierde acceso al
programa y consigo a los datos almacenados en la nube.
En función de la política de la empresa desarrolladora de la herramienta de
CRM, cuando se finaliza el tiempo de una licencia, permiten un tiempo
limitado para extraer toda la información de la nube.
En caso de que la herramienta tenga alguna actualización disponible, el
usuario la tendrá disponible sin ningún tipo de coste adicional.
Definidos los tipos de CRM existentes, en este proyecto nos centraremos en desarrollar
un CRM Colaborativo basado en la nube.
Existen múltiples sistemas de gestión de información para empresas, por tanto, se

realizará un estudio de las herramientas más utilizadas en gestión de información
actualmente:
• SAP CRM
• Oracle
• Salesforce
Figura 2: Logos de CRM en estudio [2]
El sistema de CRM en el que se implementará el proyecto es Salesforce. Ya que es una

CRM en la nube, por defecto, la herramienta viene equipada con algunas funcionalidades
útiles para cualquier empresa que realice un uso básico de un CRM. No obstante, para
una mayor customización, Salesforce propone una serie de nubes que, en función de la
que se contrate, se tendrá acceso tanto a funcionalidades específicas de la nube como a
realizar desarrollos que permitan explotar dichas funcionalidades.
La elección de esta herramienta se basa en la amplia experiencia del autor del proyecto
en esta herramienta, aportando certificaciones oficiales en la nube con la que se va a
trabajar y ofreciendo la mejor solución dentro de la misma.
Dentro de la sección del estado de arte de este proyecto, se explicarán la arquitectura de

nubes de Salesforce, así como el crecimiento de la plataforma y las capacidades del
sistema. En esta sección, además, se desarrollarán las diferentes integraciones que se
pueden tener con sistemas externos como:
• integraciones con ERP, Enterprise Resourcing Plan1,
1
Enterprise Resourcing Plan (ERP): Software que se utiliza para almacenar información o gestionar
acciones comerciales, de facturación o contractuales en una empresa.
6
• integraciones con CTI, Computer Telephony Intergation2,
• e incluso, integraciones con dispositivos de asistentes de voz.
Además de la implementación del sistema CRM, se propone la realización de un canal de

comunicación entre cliente y empresa. Este canal se desarrollará a partir del asistente de
voz, Alexa.
Figura 3: Dispositivo de asistente de voz, Alexa [3]
Alexa es asistente de voz desarrollado por la empresa Amazon que te permite interactuar
con el a través de ciertos comandos de voz. Estos comandos de voz son programas
desarrollados por terceros (o por amazon) y que se instalan en el dispositivo. Por defecto,
amazon incorpora algunas skills como juegos, noticias o el tiempo. En este proyecto se
desarrollará una skill que permita al cliente abrir o saber el estado de sus reclamaciones
abiertas en la empresa.
Amazon propone para su dispositivo un control parental que permite inhabilitar el uso de
Alexa en ciertas skills para evitar, por ejemplo, compras no deseadas. Se realizará una
investigación acerca de la seguridad que se puede proporcionar en Alexa sobre el control
parental. A nivel de Alexa, se realizará la activación del control parental y se investigará
a nivel de Skills si es posible garantizar alguna clave de seguridad para evitar la apertura
de incidencias no deseadas.
Para la integración con Alexa, el autor del proyecto realizará una formación a través de
la página oficial de Salesforce con los módulos:
• Alexa Development Basics
• Build an Alexa Skill
• Build a Private Alexa for Business Skill for Salesforce
1.1 Objetivo del proyecto

El objetivo del proyecto es mejorar la comunicación que se tiene entre cliente y empresa
proporcionando diversos métodos de comunicación entre los mismos. Además, se
proporcionará también un sistema en el que la empresa tendrá todos sus datos de
clientes junto con sus interacciones accesibles y en un solo lugar, Salesforce.
El enfoque del proyecto será, sobre todo, en mejorar el rendimiento de la empresa que
utilice el sistema y, por consiguiente, mejorar la satisfacción de los clientes y elevar la
tasa de retención de los mismos.
2
Computer Telephony Integration (CTI): Sistema que permite la integración de ordenadores con sistemas
de telefonía
7
Al final del proyecto se realizará una encuesta de valoración del sistema, además de las
pruebas unitarias que la empresa deberá hacer para corroborar su funcionamiento, a los
trabajadores de la empresa, los cuales evaluarán si el sistema ha facilitado sus labores
administrativas. También los clientes realizarán una valoración, puntuando si la
atención recibida por la empresa ha sido mejor gestionada y por consiguiente, han
resuelto sus incidencias de manera más ágil.
1.2 Estructura del documento

El presente documento de proyecto de final de carrera se estructurará en las siguientes
secciones:
• Estado del arte: Dentro de esta sección se realiza un recorrido a través de la
historia de los avances realizados tanto en la gestión de empresas, desde el inicio
de la gestión en papel hasta la creación de los diferentes sistemas de CRM que
actualmente se disponen en el mercado. Además, se realizará una comparativa de
algunos CRM actuales a nivel licenciamiento, costes y servicios aportados.
En cuanto a los asistentes de voz, se realiza un estudio del avance de los asistentes
de voz desde su creación hasta la actualidad, viendo las principales diferencias
entre los diferentes asistentes de voz del mercado, analizando sus principales
diferencias y capacidades de cada uno.
• Análisis y diseño: En esta sección se realizará el análisis de los requerimientos
que se han identificado para la construcción de este proyecto, haciendo un breve
análisis de cada uno de los sistemas que se utilizarán en la implementación.
Además, en esta sección también se encontrará el detalle de la implementación
que se ha realizado en cada uno de los sistemas utilizados en este proyecto,
adjuntando capturas de pantalla y detallando los procesos implementados.
• Evaluación: En esta sección se describe la evaluación tanto de los usuarios finales
como la autoevaluación del proyecto. En cuanto a la evaluación de los usuarios
finales, se aporta el testimonio de uno de ellos a modo de opinión de la
herramienta y diferentes capturas de pantalla de las pruebas que realizó.
• Conclusiones: Dentro de esta sección se hace un análisis global del proyecto
estableciendo los próximos pasos a seguir y los evolutivos que se podrían aplicar
al sistema tras la finalización del proyecto. Además, se concluye el impacto que
podrá tener el sistema en un medio largo plazo de implantación en base al
testimonio del usuario de pruebas y demás clientes a los que se ha implantado este
sistema.
• Anexos: Se incluye el desarrollo de la carga de datos junto con las plantillas que
corresponde de la información que el cliente para el que se desarrolla este TFG
proporciona.
8
II. ESTADO DEL ARTE
Las siglas CRM, del inglés Customer Relationship Management, hacen referencia a los
sistemas software que permiten tener registradas todas las comunicaciones que tiene una
empresa con sus diferentes clientes. Este sistema, permite conocer el estado del cliente
con respecto a la empresa, pudiendo realizar un análisis de sus necesidades y permitiendo
a la empresa trazar planes comerciales de captación y retención de clientes.
En los siguientes apartados se realizará un estudio de la evolución de los sistemas de

gestión de datos a lo largo de la historia. Además, siguiendo con los sistemas de gestión
de datos, se mostrará una comparativa entre los CRM más importantes actualmente. Para
concluir el apartado de CRM, se realizará una breve valoración de los sistemas,
explicando porque se eligió Salesforce para el desarrollo del proyecto.
Por último, se realizará una descripción del dispositivo Alexa y una comparativa con otros
dispositivos con los que se podría realizar el proyecto. Además, se realizará un estudio
sobre la evolución de los sistemas de asistentes de voz a lo largo de la historia.
2.1 Historia del CRM

En la década de los 80, nacen muchas de las tecnologías de gestión que se tienen
actualmente. Además, el desarrollo de métricas orientadas a ventas, marketing e incluso
a satisfacción del cliente, permitían tener una visión de la situación de la empresa con
respecto a sus clientes.
Kate Kestenbaum y Robert D. “Bob” fueron los creadores de algunas de las metricas que
a día de hoy se siguen utilizando. Una de ellas, CLV, del inglés Customer Lifetime Value,
permitía conocer el valor que aporta al negocio en un periodo de tiempo cerrado. Esta
métrica permitía establecer estrategias comerciales que, a día de hoy, se utilizan para
incrementar las ventas y mejorar el servicio dado al cliente.
En el año 1967 se fundó la consultora Kestenbaum & CO por Kate y Robert. Ambos
coaboraron con Robert Shaw, especialista en Marketing y consultor, realizando
desarrollos en las bases de datos de empresas como Barclays. Robert Shaw, fue la persona
que añadió el campo teléfono a las bases de datos de marketing.
Figura 4: Base de datos en la época de los 80 (Historia del CRM)
9
Previo a la creación de programas que permitirían tener una gestión centralizada de la
información de una empresa, estas mismas gestionaban su información a través de papel
y los famosos Rodolex.
Los tarjeteros Rodolex, cuyo nombre proviene del acrónimo de Rolling e Index, fueron
inventados en el año 1956 por Hildaur Neilsen. Su funcionamiento consistía en que cada
una de las tarjetas del Rodolex, contenía la información de un cliente. Además, el usuario
podía girar el eje hasta encontrar la tarjeta del cliente que requería. Esta herramienta fue
utilizada por los comerciales de las empresas a modo de base de datos de clientes.
El invento del Rodolex no fue importante porque fuera una revelación, sino porque
vaticinó el crecimiento de las herramientas destinadas a la gestión de los datos de las
empresas.
Figura 5: Tarjeteros Rolodex [5]
El comienzo de la metodología CRM, surge previo a la utilización del término. Es en el

año 1986, cuando se desarrolla la primera herramienta que puede ser catalogada como
CRM. Desarrollada en Estados Unidos por Pat Sullivan y Mike Muhney surge lo que
denominan ACT, del inglés Automate Contact Tracking.
ACT era un desarrollo sencillo que permitía sustituir los anticuados tarjeteros por un
sistema de gestión basado en un ordenador, el cual permitía a los comerciales gestionar
toda su cartera de clientes. Lo curioso de este CRM, y a pesar de ser uno de los primeros
sistemas que permitían gestionar la información desde un ordenador, es que actualmente
es uno de los CRM más utilizados del mundo.
Figura 6: Mike Munhey y Pat Sullivan, fundadores de ACT [6]
10
Años más tarde, en 1995 Pat Sullivan desarrolla SFA, del inglés Sales Force Automation.
SFA es un conjunto de sistemas de información utilizados en CRM que permitieron la
automatización del proceso de ventas que realizaban los comerciales de las empresas.
Entre las tareas automatizadas se encontraban el seguimiento de la actividad del cliente,
registros de actividad del comercial con el cliente incluso permitia el cálculo automático
del forecast 3de ventas. Este desarrollo permitió que las empresas obtuvieran un mayor
rendimiento en lo que a tareas comerciales se refiere, además de reducir el riesgo de la
fuga de clientes.
Transversal a todos estos años, el ingeniero Larry Ellison junto con otros socios, fundan
una empresa de consultoría. Esta empresa, conocida como Software Development
Laboratories (SDL), basó su tecnología en uno de los mayores estudios conocidos hasta
la fecha sobre bases de datos escrito por George Koch (1970). Una de las curiosidades
del nacimiento de esta empresa es que, los cofundadores de la misma, Lawrence J. Ellison
y Robert N. Miller, convencieron a la Agencia Central de Inteligencia (CIA) para firmar
un proyecto cuyo nombre en clave era “Oracle”.
Tras varios cambios de nombre, la empresa antes conocida como SDL, pasó a nombrarse
Oracle Corporation, empresa de software la cual posee uno de los más potentes CRM en
la actualidad.
Figura 7: Cofundadores de Oracle [7]
Con el anuncio que la empresa IBM realizó indicando que a partir de ese momento se
enfocarían en realizar bases de datos que mejorasen aspectos como la rapidez o eficiencia
de los sistemas de bases de datos y con la utilización del lenguaje SQL (Structure Query
Language), Oracle se propuso construir uno de los primeros modelos de bases de datos
relacionales.
En 1978, uno de los cofundadores de la empresa, Miner, desarrolló la primera base de

datos relacional de Oracle, llamada RDBMS (Relational Database Management System).
Con la salida de este producto al mercado, Oracle se convirtió en la primera empresa en
proporcionar este tipo de servicios, incluso antes que IBM.
3
Forecast: pronóstico
11
Alrededor del año 1982, Oracle tenía aproximadamente un valor de 2.5 millones de euros
contando con tan solo 24 trabajadores. Actualmente Oracle es una de las más grandes
empresas del sector y, por ejemplo, en 2004, reporto unos ingresos de 8100 millones de
dólares.
Con el surgimiento de negocios que se dedicaban a almacenar la información de empresas

enteras en bases de datos y construían sistemas que permitían obtener una mayor
rentabilidad, IBM adquirío los derechos de un software que daría lugar a una de las
mayores empresas de CRM que se conoce actualmente.
Alrededor del año 1970, un grupo de ingenieros trabajaron en un proyecto interno de IBM
con el software que esta empresa obtuvo. Durante el desarrollo de dicho proyecto, los
cinco ingenieros que participaron en él decidieron dejar la empresa IBM para poder crear
la suya propia. En el año 1972 surge una de las mayores empresas en el sector del CRM
actuales, SAP.
Figura 8: Socios fundadores de SAP [8]
SAP (Systemanalyse, Anwendungen und Programmentwicklung) surge de la unión de los

cinco ingenieros del proyecto de IBM, Dietmar Hopp , Klaus Tschira , Hans-Werner
Hector, Hasso Plattner y Claus Wellenreuther. En cuanto al nombre de la empresa, cuyas
siglas son en alemán, es el mismo que el de la sección donde trabajaban los cinco
ingenieros en el proyecto del software que IBM obtuvo.
Un año más tarde de su fundación, SAP lanzó al mercado el primer programa que permitía
tener funcionalidades de contabilidad, además de las funcionalidades estándar de su
CRM. Tras el éxito de su primer producto, la sede central de la empresa se trasladó a
Walldrof, Alemania, y tres años más tarde, en el 1979 lanzó la segunda versión de su
primer producto. Sin embargo, este segundo producto no fue tan exitoso como el primero.
Fue en el año 1985 cuando consiguió estar a la altura de su predecesor.
SAP evolucionaba acorde a las innovaciones tecnológicas de la época y se adaptaba a las

necesidades de sus clientes, haciendo así que a día de hoy sea una de las cinco mayores
empresas del mundo con una cartera de 375000 clientes y aproximadamente unos 100000
empleados.
Por otro lado y unos años más tarde, uno de los trabajadores de la empresa Oracle, Tomas
Siebel, en el año 1993 fundó la empresa Siebel Systems. Esta empresa comienza siendo
una empresa orientada a la realización de automatizaciones en los procesos de venta pero,
12
al convertirse en el líder mundial del mercado, expande su negocio introduciéndose en el
mundo del CRM.
En la actualidad, esta empresa sigue funcionando y actualmente tiene más de 700
empresas consideradas colaboradoras, como Oracle, y cuenta con aproximadamente 7000
trabajadores.
Figura 9: Thomas Siebel [9]
Tras el éxito de la compañía Siebel Systems, los competidores de la misma, viendo el

éxcito que obtuvo en el mercado del CRM, comenzaron a desarrollar soluciones basadas
en este tipo de sistemas. Sin embargo, no todas las compañías que decidieron apostar por
el desarrollo de CRM tuvieron éxito debido al alto coste al cual vendían su solución.
Alrededor del año 1999, sucedieron varios cambios importantes para la industria del
CRM que marcaron la historia. Algunas compañías comenzaron a ofrecer productos
orientados a otros dispositivos como móviles y además, comenzaron a utilizar internet
para mejorar sus soluciones. Estos hitos permitieron un desarrollo exponencial de los
sistemas CRM que hasta la época se conocía.
En el mismo año en el que la revisa Fortune nombra a la empresa Siebels como empresa
con el crecimiento más rápido del país, otro trabajador de la compañía Oracle, funda una
de las empresas que actualmente tiene otro de los sistemas de CRM más potentes.
Marc Benioff, antiguo desarrollador de la empresa Apple y ex-trabajador de Oracle, funda

en el año 1999 la empresa Salesforce. Lo curioso de esta empresa es que, tanto el fundador
Marc Benioff Parker como los cofundadores de la empresa Parker Harris, Frank
Domínguez y Dave Moellenhoff, comenzaron el desarrollo de su primer prototipo en un
apartamento y no en un sitio con las instalaciones adecuadas.
Como anécdota cabe destacar que los cuatro desarrolladores del prototipo no vestían con
ropas ejecutivas ni mucho menos, vestían con ropa completamente deportiva y nombraron
a la mascota de Marc, su perro Koa, como jefe del amor. En este aspecto, se puede ver la
influencia que tuvo sobre Marc Benioff su trabajo como desarrollador de la empresa
Apple, la cual tenía filosofías parecidas.
13
Figura 10: Marc Benioff, fundador de Salesforce [10]
Algo que caracteriza a la empresa de Marc Benioff, es que, en sus inicios, redactaron unn
documento en el que se citaban los objetivos de la empresa y que sus empleados, pasados
y futuros, debían tener en cuenta. Este documento denominado V2MOM, representa las
siglas de Visión, Valores, Métodos, Obstáculos y Medidas. Actualmente, la empresa
continúa aplicando lo estipulado en el documento V2MOM tanto en la dirección de la
empresa, como en las decisiones que se toman en la misma.
Actualmente la empresa Salesforce es uno de los líderes de mercado en soluciones CRM

alcanzando un valor de 17 billones de dólares en el mercado.
A continuación, se realizará un estudio de tres de los sistemas mencionados a lo largo de

este punto. Estos son Salesforce, SAP y Oracle. Además, se definirá uno de los conceptos
en los que se basa este trabajo de final de grado y es el hilo conductor de todas las
empresas en estudio, la nube
2.2 ¿Qué es la nube?

Se define como nube al espacio virtual de almacenamiento de información o sistemas
informáticos que un usuario puede utilizar sin tener la necesidad de realizar una
instalación de un dispositivo hardware.
El almacenamiento en la nube implica una despreocupación por la capacidad de

almacenamiento, ya que dicha capacidad no está limitada como si lo está la capacidad de
cualquier dispositivo físico. Los datos están almacenados en espacios de memoria
virtuales, que, en su mayoría, son aportados por terceros. De esta manera, la empresa,
compra o alquila el espacio que necesite para el almacenado de sus datos, con la
posibilidad de aumentarlo, y sin la necesidad de instalar un dispositivo hardware.
Además, el coste para las empresas es en su mayoría menor, dado que no destinan su
capital en algo físico e inamovible, sino que lo invierten en algo que puede cambiar y les
permite tener opciones diferentes sin necesidad de tener un contrato duradero.
La nube, además de abaratar costes, permite que los empleados que la utilizan dentro de
una empresa tengan mayor flexibilidad dado que pueden acceder a la información desde
cualquier dispositivo que tenga acceso a internet.
Otra de las ventajas de la utilización de la nube es que los datos tienen una fiabilidad y
seguridad mayor ya que no se almacenan en un dispositivo físico, sino que toda la
información está compartida entre los empleados y no es posible que se pierda por
desperfectos de los equipos que los contienen.
14
A continuación, se detallan algunos de los sistemas en estudio que utilizan la nube como
método de almacenaje de datos, a pesar de que algunos de ellos partieron de el
almacenamiento de datos en dispositivos de hardware.
2.3 Salesforce
Salesforce (Benioff, Salesforce CRM, 1999), empresa fundada por Marc Benioff en el
año 1999, desarrolló una plataforma basada en la nube que permite a cualquier empresa
que lo utilice, tener toda su información centralizada. No solo permite almacenar la
cartera de clientes de una empresa sino, sus oportunidades de negocio, clientes
potenciales y, además, incidencias en el servicio prestado por la misma empresa.
El enfoque de esta herramienta de gestión es poder mejorar las relaciones con clientes,
permitiendo a los mismos tener una mejor comunicación con la empresa y, a esta última,
tener toda la información necesaria de cada uno de sus clientes accesible desde cualquier
punto.
La estructura de Salesforce está basada en diversas nubes. Cada una de las nubes que
conforman la plataforma Salesforce aporta unas funcionalidades estándar, lo que hace
que el cliente pueda obtener un sistema de CRM orientado únicamente a la nube que el
necesite.
A continuación se definirán las diferentes nubes que aporta Salesforce, el tipo de

licenciamiento, así como su coste, y se especificarán las ventajas de la utilización de
Salesforce.
2.3.1 Nubes de Salesforce

Salesforce consta de varias nubes orientadas a diversas funcionalidades. En este apartado
únicamente se definirán las principales nubes de Salesforce, además de explicar
brevemente su utilidad y enfoque. A pesar de que durante el apartado se pondrá foco en
las principales nubes de Salesforce, a continuación se listan todas las nubes de salesforce
dando una breve definición de cada una de ellas:
• Ventas: Nube enfocada a la atención comercial y a la generación de

oportunidades de negocio.
• Servicios: Nube directamente relacionada con la atención del cliente y la
satisfacción del mismo.
• Marketing: Explota la capacidad de una empresa de captación de clientes y
mejora de relaciones con los mismos.
• Commerce: Basada en el comercio digital se enfoca en la captación de
clientes.
• Apps y relacionamiento: Nube para desarrollo de aplicaciones personalizadas
dentro del CRM de Salesforce.
15
Figura 11: Logo oficial de las nubes de Salesforce. [11]
Nube de ventas
Esta es la nube de Salesforce orientada a la gestión de posibles clientes potenciales que

puede tener una empresa, oportunidades de negocio y la gestión de contratos.
Figura 12: Logo de la nube de ventas [12]
Esta nube permite tener un mayor rendimiento a nivel comercial, ya que, cada uno de
los comerciales de la empresa, podrá tener acceso a su propia cartera de clientes,
gestionar las ventas que ha realizado, e incluso, permite realizar automatizaciones en
cuanto a los vencimientos de los contratos.
Nube de servicios
Es la nube de Salesforce orientada al servicio de soporte de una empresa, permitiendo

gestionar incidencias, mejorando la satisfacción del cliente por las numerosas vías de
contacto que pueden configurarse entre cliente y empresa.
Figura 13: Logo de la nube de Servicios [13]
Esta nube permite tener un incremento de la productividad de los gestores encargados

de la gestión de incidencias y, por tanto, obtener un incremento de la satisfacción del
cliente. Además, permite tener varias vías de comunicación entre cliente y empresa
16
orientadas al soporte y resolución de incidencias como pueden ser el correo electrónico,
formularios web, integraciones con centralitas de telefonía e incluso una base de
conocimientos pública para que los clientes puedan solucionar incidencias comunes por
ellos mismos, sin tener la necesidad de contactar con la empresa.
Nube de marketing
Es la nube de Salesforce orientada al contacto con clientes permitiendo crear un mayor

vínculo con los mismos y de manera personalizada.
Figura 14: Logo de la nube de Marketing [14]
A través de los diferentes medios de comunicación que aporta la nube de marketing,

como pueden ser, campañas publicitarias, análisis de interacciones de clientes y redes
sociales, la empresa puede tener un trato más cercano con el cliente, afianzando así la
confianza que éste deposita en la empresa. Además, a través de integraciones con
sistemas externos como puede ser Google Analytics, se pueden realizar informes y
gráficos que permitan al departamento de marketing de la empresa, evaluar el impacto
que su publicidad tiene en los clientes.
Nube de comunidades
Es la nube de Salesforce orientada proporcionar una facilidad en cuanto a la

comunicación del cliente o el socio con la empresa. Se basa en aportar un portal en el
que, a tiempo real, el cliente o socio puede consultar sus incidencias, oportunidades de
negocio o incluso convertirse en un cliente potencial.
Figura 15: Logo de la nube de comunidades [15]
Existen varios tipos de comunidades que pueden ser utilizadas. Para las comunidades de
cliente, éste puede consultar a tiempo real el estado de sus incidencias, contactar con la
empresa, crear nuevas incidencias o incluso, si la comunidad tiene preguntas frecuentes,
solventar problemas que pueda tener en la utilización de un servicio.
Para las comunidades de socios, éstos pueden consultar el estado de sus oportunidades,
contratos o incluso visualizar informes para tener una visión ampliada de su trayectoria
con la empresa.
En este proyecto se propone la utilización de la nube de servicios y la nube de

comunidades, ya que está enfocado a la mejora de atención al cliente y que la empresa
tenga un mejor rendimiento en la resolución de incidencias.
17
2.3.1 Licenciamiento
Para la utilización de esta plataforma, solo es necesario tener conexión a internet y obtener
una licencia por cada uno de los usuarios que la utilice. Cada una de las nubes
mencionadas en el punto anterior se adquiere a través de una licencia propia. De esta
manera, si la empresa no desea tener funcionalidades de otras nubes, solo se le
proporciona las funcionalidades estándar que vienen en el sistema por defecto. Este punto
hace que los costes se abaraten, teniendo en cuenta que muchos de los procesos que
Salesforce tiene implementados de serie, cubren las necesidades básicas de cualquier
empresa que no enfoque la utilización de su CRM en varias nubes sino solamente en una.
En función del tipo de licenciamiento que la empresa contrate con Salesforce, podrá
obtener más o menos funcionalidades estándar. A continuación, se muestra una tabla con
las diferentes licencias que una empresa puede obtener, haciendo referencia únicamente
a las dos principales nubes de Salesforce, así como el detalle de algunas funcionalidades
estándar que se obtiene con cada una de ellas:
Essentials Professional Enterprise Unlimited

(25$/mes) (75$/mes) (150$/mes) (300$/mes)
Sales Gestión de cuentas, clientes potenciales y ✔ ✔ ✔ ✔
Cloud oportunidades
Integración con Gmail o Outlook ✔ ✔ ✔ ✔
Salesforce Mobile App ✔ ✔ ✔ ✔
Priorización de clientes potenciales ✖ ✔ ✔ ✔
Medidor de pronósticos de ventas ✖ ✔ ✔ ✔
Automatización de procesos de aprobación ✖ ✖ ✔ ✔
Soporte técnico 24 horas todos los días ✖ ✖ ✖ ✔
Service Gestión de Casos ✔ ✔ ✔ ✔
Cloud
Consola del agente ✔ ✔ ✔ ✔
Knowledge4 ✔ ✔ ✔ ✔
Contratos de Servicio e Hitos ✖ ✔ ✔ ✔
Integración con telefonía (CTI) ✔ ✔ ✔ ✔
Conexión con sistemas externos ✖ ✖ ✔ ✔
Soporte técnico 24 horas todos los días ✖ ✖ ✖ ✔
Tabla 1: Licencias de las principales nubes de Salesforce
Las licencias de la nube de Marketing Cloud por su parte tienen una estructura diferente
la cual no necesita una licencia por usuario, sino que las licencias son al mes por
funcionalidad:
Growth Plus Advance

(1250$/mes) (2500$/mes) (4000$/mes)
Pardot Generación, calificación y gestión de clientes potenciales ✔ ✔ ✔
Personalización de emails orientados al marketing ✔ ✔ ✔
Inteligencia de Marketing aplicada a ventas ✔ ✔ ✔
Generación, calificación y automatización avanzadas ✖ ✔ ✔
4
Knowledge: Funcionalidad que permite tener una base de datos de preguntas frecuentes o información
sobre incidencias recurrentes, a través de las cuales los clientes de la empresa son capaces de resolver sus
casos sin necesidad de contactar con la empresa.
18
Informes avanzados ✖ ✔ ✔
Focalización de procesos en necesidades de clientes ✖ ✖ ✔
Inteligencia artificial para Marketing y ventas ✖ ✖ ✔
Basic Pro Corporate Enterprise

(400$/mes) (1250$/mes) (3750$/mes)
Email, Email orientados al Marketing ✔ ✔ ✔ ✔
Mobile Creación de contenido ✔ ✔ ✔ ✔
and Web Integración con Salesforce Sales Cloud ✔ ✔ ✔ ✔
Jorney Builder5 ✖ ✖ ✔ ✔
Desarrollos con Mobile Message ✖ ✖ ✔ ✔
Inteligencia artificial ✖ ✖ ✔ ✔
Manejo de multiples negocios ✖ ✖ ✖ ✔
Tabla 2: Licencias de la nube de Marketing de Salesforce
2.4 Oracle
Oracle (Ellison, Oracle CRM, 1977), empresa fundada por Larry Ellison en el año 1977,
a lo largo de su historia desarrollo inficidad de productos que facilitaron la gestión de
cualquier empresa independientemente del tamaño que tuviera. Oracle no es una empresa
enfocada únicamente a la nube, como sí lo es Salesforce, sino que además proporciona
sus propios sistemas de bases de datos, software totalmente empresarial a medida e
incluso desarrollos de software basados en la nube. En este aspecto, Oracle es una
empresa más competente en cuanto a diversidad de opciones que puede ofrecer una
contratación con ellos.
Basándonos en el CRM de Oracle, al igual que el CRM de Salesforce, Oracle está basado
en nubes enfocadas en aportar valor, a la empresa que las contrate, facilitando el trabajo
de sus trabajadores, estableciendo tareas automáticas e incluso permitiendo obtener
información de sistemas externos.
2.4.1 Nubes de Oracle

A continuación se definirá la arquitectura de nubes en la que se basa el CRM de Oracle.
Al igual que en Saleforce, las nubes con más desarrollo son la nube de Ventas, Servicios
y Marketing.
Nube de ventas
Esta nube de Oracle está enfocada a la automatización de procesos de ventas que realizan
diariamente el departamento comercial de cualquier empresa. Con las funcionalidades
estándar que aporta esta nube, la empresa consigue un mayor rendimiento del área
comercial, una mayor relación con los clientes y a los altos cargos, les permite tener una
mayor visibilidad del funcionamiento del área comercial a través de análisis avanzados.
Otra de las funcionalidades que aporta esta nube es que facilita la realización de un
pronóstico de ventas estandarizado.
5
Journey: Funcionalidad que permite construir relaciones estrechas con el cliente respondiendo a la
actividad de un cliente durante su ciclo de vida.
19
Nube de Servicio
Es la nube de Oracle destinada a la atención al cliente. Esta nube proporciona diversos

canales a través de los cuales los clientes pueden contactar con la empresa para poder
gestionar sus reclamaciones, quejas o incidencias. Al igual que en Salesforce, permite
integraciones con sistemas de CTI, bandejas de correo electrónico o incluso atención al
cliente desde la web.
Además proporciona funcionalidades que permiten medir la satisfacción del cliente y
mejorar el rendimiento del área de soporte de la empresa para que la satisfacción aumente.
Nube de Marketing
Con esta nube, la empresa puede explotar de una manera más eficiente la relación entre
la misma y el cliente. Para ello, la nube de Marketing permite el envío de campañas
publicitarias, por ejemplo, lo cuál hace que la relación entre empresa y cliente sea más
continua. Además, se puede tener una visión más directa de los intereses de los clientes o
los posibles clientes potenciales de una empresa. Esto facilita la tarea del departamento
de ventas, ya que los comerciales pueden enfocarse en los clientes que muestran algún
tipo de interés.
En resumen, la nube de marketing da una visión más exacta de los intereses de los clientes
y clientes potenciales, por lo que el departamento de ventas puede trazar estrategias de
ventas con un mejor rendimiento.
El licenciamiento de Oracle es muy similar al de Salesforce. Tiene las mismas divisiones
por nubes para que el usuario únicamente contrate lo que va a utilizar. Cada uno de los
usuarios que utilicen el sistema y desee tener acceso a las funcionalidades de una de las
nubes de Oracle, deberá tener la licencia.
A continuación se detallan los precios de algunas de las nubes de Oracle y, además, se

especificarán las funcionalidades que entra en cada una de las licencias:
Professional Standard Enterprise Premium

(65$/mes) (100$/mes) (200$/mes) (300$/mes)
Sales Core de Oracle ✔ ✔ ✔ ✔
Cloud Aplicación móvil ✔ ✔ ✔ ✔
Analiticas de venta ✔ ✔ ✔ ✔
Pronóstico de ventas ✔ ✔ ✔ ✔
Campañas ✔ ✔ ✔ ✔
Herramientas de configuración ✔ ✔ ✔ ✔
Manejo de multiples negocios ✔ ✔ ✔ ✔
Integración con Outlook ✖ ✔ ✔ ✔
Gestión de territorios ✖ ✔ ✔ ✔
Aplicación de iPad para ventas ✖ ✖ ✔ ✔
Compensación de incentivos ✖ ✖ ✔ ✔
Gestión de presupuestos ✖ ✖ ✔ ✔
Integración con Gmail ✖ ✖ ✔ ✔
Predicción de ventas ✖ ✖ ✔ ✔
20
Oracle Voice6 ✖ ✖ ✖ ✔
Enterprise Contracts7 ✖ ✖ ✖ ✔
Tabla 3: Licencias Oracle Sales Cloud
Standalone Standard Enterprise Enterprise

Chat Dynamic Dynamic Contact
(90$/mes) (110$/mes) (140$/mes) Center
(250$/mes)
Service Funcionalidad de analítica ✔ ✔ ✔ ✔
Cloud Portal de clientes ✔ ✔ ✔ ✔
Chat ✔ ✖ ✖ ✔
Gestión de contratos de sevricio ✔ ✔ ✔ ✔
Plataforma en la nube ✔ ✔ ✔ ✔
Encuestas por chat ✔ ✖ ✖ ✖
Knowledge ✔ ✔ ✔ ✔
Gestión de emails ✖ ✔ ✔ ✔
Consola del usuario dinámica ✖ ✔ ✔ ✔
Multicanal de comunicación de incidencias ✖ ✔ ✔ ✔
Asistente guiado en la plataforma ✖ ✖ ✔ ✔
Gestión del feedback del cliente ✖ ✖ ✔ ✔
Personalización de comunicaciones de email ✖ ✖ ✔ ✔
Registro de productos ✖ ✖ ✖ ✔
Tabla 4: Licencias Oracle Service Cloud
En cuanto al licenciamiento de la nube de Marketing Cloud de Oracle, existen varios

factores que lo determinan como el número de contactos que se van a utilizar, veces que
se contacta a los clientes, métodos de contacto…
En comparación con Salesforce, el licenciamiento de Oracle está mucho más segmentado

de tal manera que la licencia Standard Dynamic, por ejemplo, no tiene licencia de Chat y
si la empresa quisiera obtener esta funcionalidad tendría bien que coger una licencia más
barata que le incluya menos funcionalidad pero sí incluya el Chat, o bien, coger la licencia
más cara que tiene todas las funcionalidades de la nube de Service Cloud.
2.5 SAP
Esta empresa fue fundada por cinco ingenieros trabajadores de IBM en el año 1972 (SAP
CRM, 1972). Al igual que la empresa Oracle, SAP no solo se dedicó al desarrollo de
productos en la nube sino que también proporciona programas de software que, como
empresa, le permite abrirse mercado en muchos sectores. El éxito de SAP es
completamente su software ERP. Este software esta completamente orientado a facilitar
la labor de los trabajadores de cualquier empresa aportando una solución enfocada en las
funciones que realiza cada uno de los deparmentos de la misma.
En cuanto al CRM de SAP, desde su nacimiento, ha sido un CRM on premise.

Recordemos que un CRM on premise es un programa informático que se instala en un
dispositivo (ordenador) y que funciona en local. Con el auge de los productos en la nube
6
Oracle Voice: Sistema de chat a través del cual el cliente puede comunicarse con la empresa.
7
Enterprise contracts: Funcionalidad que permite mejorar el proceso de contratación estándar aportando
rapidez en las búsquedas, renovaciones y visibilidad de los contratos dentro del CRM.
21
y queriendo hacer competencia a Salesforce, SAP CRM comenzó a migrar su CRM a la
nube y así poder seguir siendo líder del mercado. En este aspecto, SAP continúa migrando
sus sistemas a la nube y asegura que no se va a retirar el producto CRM on premise, dado
que muchos de sus clientes lo continúan utilizando e incluso sus nuevos clientes lo
compran.
2.5.1 Nubes de SAP

A continuación se detallarán las principales nubes del CRM de la empresa SAP. Estas
nubes son la nube de Ventas, Servicios y Marketing.
Nube de ventas
Es la nube que facilita las labores comerciales aportando funcionalidades orientadas al
sector de las ventas y la captación de clientes potenciales.
Figura 16: Logo de la nube de ventas de SAP [16]
Al igual que en Oracle y Salesforce, esta nube permite obtener funcionalidades de ventas
que facilitan a los comerciales las labor que realizan a diario. Además, con la
funcionalidad estándar que aporta, se puede explotar de una manera más productiva las
relaciones con los clientes e incluso saber cuales son las oportunidades de venta más
calientes.
Nube de Servicios
Es la nube destinada a la atención al cliente, solución de incidencias e incluso la nube que
permite medir la satisfacción que un cliente tiene con respecto a una empresa.
Figura 17: Logo de la nube de servicios de SAP [17]
Esta nube permite a los usuarios que la utilicen tener una visión completa de todas las
incidencias que están gestionando así como una vista 360º de las incidencias abiertas por
el cliente. Dicho esto, se puede deducir que los tiempos de gestión de incidencias de una
empresa bajan y por consiguiente, la satisfacción del cliente, en este ámbito, aumenta.
Nube de Marketing
Esta es la nube encargada de la gestión de la comunicación entre cliente y empresa,
haciendo que sea más fluida y continua mediante las funcionalidades que aporta.
22
Figura 18: Logo de la nube de martketing de SAP [18]
Con esta nube la empresa obtendrá funcionalidades que permita que el departamento
comercial mejore las relaciones con los clientes. Dado que está orientada a la mejora de
la comunicación permite que el comercial que la utilice obtenga más información de los
intereses del cliente y pueda trazar un plan de ventas acorde a dicha información. Además,
también permite el envío de campañas, lo cual hace que la conversación empresa-cliente
sea más fluida y constante.
A diferencia de las otras empresas, el licenciamiendo de la empresa SAP es privado y
únicamente lo habilitan para clientes potenciales de la compañía. Es por esto que no es
posible detallar un informe de precios con las funcionalidades incluidas por cada una de
las nubes mencionadas en el apartado anterior.
2.6 Ventajas sobre la utilización CRM en la nube

A continuación, se citarán algunas de las ventajas identificadas en la utilización de la
herramienta de Salesforce como CRM.
Costes
En primera instancia, el coste de esta herramienta es mínimo. En función del tipo de
licencia que se obtenga se tendrá acceso a más o menos funcionalidades. Por defecto,
además, este tipo de herramientas vienen preparadas para su utilización aportando un
modelo de datos estándar de negocio y además algunas automatizaciones, como puede
ser, recordatorios de las fechas de vencimiento de contratos.
Es por lo explicado anteriormente, que, en primera instancia, la empresa solo pagaría las
licencias requeridas en función del número de usuarios que utilicen la plataforma. Es
durante su uso, cuando las empresas contratan a especialistas en Salesforce que sean
capaces de aportar más funcionalidad que la que viene dentro de la plataforma.
Customización
Estas herramientas permiten tener una gran personalización, tanto a nivel de visualización
corporativa como a nivel de automatizaciones y desarrollos personalizados.
Su uso permite personalizar totalmente en cuanto a las automatizaciones que necesita el
cliente, como pueden ser envíos de correo, integraciones con otros sistemas o incluso
gestionar la visibilidad en función de la jerarquía que tenga la empresa.
En cuanto al tema estético de la plataforma permiten tener una interfaz de usuario

intuitiva, lo que facilita también la gestión del cambio entre los trabajadores de una
empresa. La interfaz se puede personalizar con los colores corporativos de la empresa,
establecer el logo de la misma, e incluso los formatos de página.
23
Salesforce es una de las herramientas más versátiles en este punto, en cuanto a CRM en
la nube se refiere, del momento.
Rendimiento
Permiten explotar el rendimiento de los trabajadores de la empresa, ya que, como se
comenta en la ventaja anterior, muchas de las tareas que habitualmente una persona
realiza de manera manual, como puede ser el envío de un email, se puede automatizar sin
necesidad de que el usuario haga un click en la pantalla.
Además, al ser un sistema en el cual la información está centralizada y al alcance del

usuario en cualquier momento, mejora las búsquedas de datos y ayuda a que los tiempos
disminuyan.
Facilidad de uso
Tal y como se indica en la ventaja de customización, la interfaz de usuario es intuitiva y
fácil de manejar. Además, la posibilidad de adaptación al requerimiento de la empresa y
algunas funcionalidades de ayuda que aportan estas herramientas, son configurables para
guiar al usuario y hacen que la gestión del cambio de las empresas sea menos drástica.
Evolución
Estos sistemas suelen tener varias actualizaciones al año que permiten obtener nuevas
funcionalidades o mejoras en funcionalidades que ya estaban dentro de lo estándar.
En Salesforce, estas actualizaciones se llaman Release y se realizan tres al año. Las

Release se basan en ideas aportadas por los usuarios de Salesforce. Estas ideas se reflejan
en un portal público en el que los usuarios votan por las mejores ideas y Salesforce las
incluye en sus actualizaciones. De esta manera, cada año obtienes, de forma estándar con
la plataforma, funcionalidades que pueden interesar a tu negocio.
Por otro lado, en cuanto a funcionalidades que puedas obtener out of the box8, Salesforce
permite realizar multitud de desarrollos e integraciones que pueden surgir durante el uso
de la plataforma en una empresa. Estas actualizaciones, suelen ser realizadas por personas
especializadas en la herramienta, y pueden realizarse sin que la herramienta sufra ninguna
suspensión de uso.
En este aspecto, Salesforce es una de las herramientas en estudio que más despunta. Al
tener tres actualizaciones al año y ser sugerencias de los propios usuarios que las utilizan,
cubren cada poco tiempo funcionalidades nuevas que se pueden explotar dentro de
cualquier organización
Accesibilidad
En cuanto a la accesibilidad a la plataforma, estas herramientas son accesibles desde
cualquier dispositivo que tenga conexión a internet. Al ser una plataforma en la nube, es
accesible en cualquier momento. En este caso, Salesforce cuenta con una aplicación
móvil, llamada Salesforce, que permite tener una interfaz diferente a la interfaz del
ordenador y, a nivel comercial, es muy útil ya que reciben alertas de eventos programados
8
Out of the box: Funcionalidad no incluida en el paquete contratado y que puede ser desarrollada por un
tercero.
24
en forma de notificaciones y tienen toda la información necesaria sobre los contratos de
los clientes en su dispositivo móvil.
A continuación, al igual que hemos realizado con la parte de CRM, haremos un estudio
de los diferentes asistentes de voz que hay en el mercado contando su historia y las
ventajas que se tiene al utilizar dichos aparatos electrónicos.
2.7 Historia de los asistentes de voz

En primer lugar y antes de comenzar a detallar la historia de los asistentes de voz, se debe
definir dicho término.
Un asistente de voz es un software que tiene la capacidad de ofrecer uno o varios servicios
a la persona con la que interactúa. Algunos asistentes de voz no solo ofrecen algún tipo
de servicio como pueden ser recordatorios o poner música, sino que son capaces de hacer
tareas como realizar una compra online, realizar una llamada telefónica o incluso poner
una reclamación a una empresa por un pedido que está defectuoso.
La historia de estos dispositivos data del año 1940 cuando surgió el primer software que
permitía un reconocimiento de voz en la empresa AT&T Bell. Esta empresa decidió
apostar por seguir investigando y desarrollando esta tecnología dado que eran conscientes
de que era una tecnología de la que eran pioneros y querían explotar.
Continuando con su desarrollo, en el año 1952, AT&T Bell dio a luz al primer sistema
que era capaz de reconocer números del 0 al 9. Este sistema se denominó Audrey. Dado
el éxito de Audrey, las grandes empresas decidieron apostar por la investigación sobre el
campo del reconocimiento de voz en sistemas automatizados y desarrollar softwares que
fueran capaces de interactuar con el ser humano.
Figura 19:Imagen de (Audrey) [19]
IBM, la empresa desarrolladora más grande de software de esa época, diez años más tarde
(1962) fue la primera en sacar al mercado el primer prototipo de un sistema que era capaz
de reconocer una totalidad de dieciséis palabras y los números del 0 al 9. Además, era
capaz de realizar operaciones simples como sumas y restas. Esta herramienta se le bautizó
como Shoebox.
25
Figura 20: Imagen de (Shoebox) [20]
Tras el modelo de IBM, la Universidad Carnegie Mellon situada en Pensilvania apoyados

por el departamento de Defesa de los EEUU, desarrolló un asistente de voz que permitía
reconocer más de mil palabras. Lo denominaron Harpy.
Los mismos científicos que desarrollaron el sistema Harpy, diez años más tarde
desarrollaron un programa que no solo reconocía palabras sueltas, sino que era capaz de
reconocer enunciados completos. Para ello, utilizaron el modelo de Márkov. Dicho
modelo trata de predecir a través de cálculos estadísticos las palabras que pueden ir a
continuación de una palabra.
Con esto el desarrollo de sistemas de reconocimiento de voz aumentó exponencialmente
dado que su capacidad era infinitamente mayor al poder reconocer frases completas,
siendo los primeros asistentes de voz digitales los contestadores automáticos, por
ejemplo.
Ya en los años 90, las empresas como Microsoft, IBM y Philips dieron el paso de llevar
esta tecnología a una máquina física con la que el usuario puede interaccionar. Fue en
esta misma época cuando el desarrollo de los sistemas de reconocimiento de voz se paró
por completo debido a la crisis de las punto com, que azotó fuertemente a las empresas
tecnológicas.
Pasada la crisis, en el año 2011, sale a la luz a través de la empresa Apple Inc. el primer
asistente virtual digital instalado en un dispositivo móvil, el Iphone 4s. Este asistente de
voz obtuvo el nombre de Siri. Este asistente, cuando Apple decide implantarlo en su
teléfono móvil, ya llevaba tres años desarrollado.
Siri surge de un proyecto CALO del Centro de Inteligencia Artificial de SRI International
como uno de los desarrollos del mayor proyecto de inteligencia hasta la fecha. Como
curiosidad se puede comentar que en un principio, Siri iba a estar disponible en los
terminales de iOS, Android y Blackberry. Esto no sucedió dado que Apple adquirió Siri
en el año 2010 convirtiéndose en la única empresa que podía tener Siri en sus dispositivos.
26
Figura 21: Logo de Siri [21]
Tras el nacimiento de Siri, empresas como Microsoft, Amazon y Google comenzaron a

desarrollar sus propios asistentes de voz o incluso, crear sus propios dispositivos que
únicamente son asistentes de voz digitales.
Unos meses más tarde del surgimiento de Siri, Google lanzo al mercado su primer
asistente de voz, Google Allo. Este desarrollo de Google se vió completamente opacado
por el surgimiento de Siri, ya que Google Allo no era capaz de mantener una conversación
con una persona sino que simplemente era un asistente de búsqueda por voz. Este no fue
el mejor asistente de voz de google puesto que, años más tarde, en el 2016, surge la nueva
actualización de Google Allo, denominado, Google Assistant.
En el año 2014 surge Cortana, herramienta de asistente de voz de Microsoft. El nombre

de Cortana surge de la saga de videojuegos Halo, también de la empresa Microsoft, siendo
la misma actriz que dobla el videojuego, la voz del asistente. Este asistente solo está
disponible para ordenadores que lleven el sistema operativo Windows.
Figura 22: Logo de Cortana [22]
En el mismo año, la empresa Amazon lanza junto a su dispositivo Echo su asistente de

voz, Alexa. Actualmente este asistente de voz es uno de los más reconocidos y utilizados
mundialmente por la funcionalidad tan amplia que tiene. Echo de Amazon es el primer
dispositivo dedicado exclusivamente a contenter un asistente de voz como Alexa.
Dada su repercusión, Amazon continuó desarrollando este tipo de dispositivos, añadiendo

funcionalidades como, por ejemplo, conexión con dispositivos domóticos de una vivienda
y permitir crear a desarrolladores sus funcionalidades. Las Skills de Alexa son programas
de reconocimiento de voz adicionales a lo que Alexa proporciona de serie, que permiten
personalizar la experiencia de usuario incluyendo funcionalidades out of the box. De esta
manera, el usuario puede personalizar su asistente de voz y compartir sus propias Skills
con el resto de la comunidad Alexa. En el apartado de diseño de este trabajo de fin de
grado, profundizaremos más en el desarrollo de Skills de Alexa.
27
Figura 23: Logo de Alexa [23]
A lo largo de los años, Amazon ha conseguido realizar toda serie de eventos en los que
ha patrocinado el nombre de su dispositivo y obteniendo uno de los asistentes de voz más
reconocidos mundialmente. Algunos de estos eventos son:
• Premio Alexa en el año 2016, el cual estaba completamente orientado a conseguir
continuar con el desarrollo de este tipo de tecnologías
• Conferencias por todo el mundo: La primera conferencia entorno al dispositivo
Alexa se celebró en el año 2017.
• Introducción en vivienda: Alexa se convirtió en el primer dispositivo en ser parte
de una serie de viviendas domóticas en el año 2018.
Todos estos eventos permitieron que la compañía Amazon continuara con su producto
estrella hasta la actualidad, haciéndose con una cifra de más de cien millones de
dispositivos vendidos por todo el mundo.
Como curiosidad, desde el inicio de Alexa, para poder activar el asistente de voz, se le
debe llamar por su nombre. En este aspecto, Amazon reflejó de manera excepcional el
comienzo de una conversación real cuando una persona quiere dialogar con otra y llama
su atención diciendo su nombre. Este detalle, hace que Alexa simule una situación real y
por tanto, el impacto
Dos años más tarde de la aparición de Alexa (2016), la compañía Google, apostó por
sacar al mercado un nuevo asistente de voz llamado Google Assistant. Al igual que el
asistente de voz de amazon, Google decidió invertir en su asistente de voz y crear un
dispositivo físico que únicamente estaría destinado a ser, en sí mismo, un asistente. El
dispositivo que salió junto con Google Assistant se denominó Google Home.
Figura 24: Logo de Google Assistant [24]
En sus inicios, el asistente de Google, solo podía integrarse con móviles de la marca
Google Pixel, la cúal tenía el sistema operativo de Chrome OS o incluso algunos de ellos
Android. Teniendo en cuenta esta limitación, Google, en el año 2017, anunció que su
28
asistente de voz sería capaz de conectarse a otro tipo de terminales como teléfonos que
utilizaban el sistema operativo Android Marshmallow o Android Nougat.
Durante los siguientes años hasta la actualidad, Google ha seguido mejorando su

dispositivo permitiendo, por ejemplo:
• Realizar integraciones con el sistema Raspberry Pi.
• Integrarse con dispositivos domóticos de una vivienda.
• Permitir a los desarrolladores realizar sus propias funcionalidades dentro del
dispositivo.
• Introducir el sistema de asistente de voz en pantallas digitales.
Se puede observar, por la historia descrita en este apartado, que los dos asistentes de voz
con más repercusión son Alexa y Google Assistant. Es por esto que a continuación se
realizará un análisis de ambos dispositivos y, posteriormente, se explicará porqué se
decidió desarrollar este trabajo de final de grado con el dispositivo Alexa.
2.8 Alexa
Alexa es el asistente de voz de la empresa Amazon que está integrado en sus dispositivos
Echo. Alexa se basa en unas pequeñas funcionalidades que se denominan Skills. En los
siguientes apartados se detallará que es una Skill de Alexa y analizaremos los diferentes
dispositivos Echo especificando sus características.
2.8.1 ¿Qué es una Skill?

Una Skill de Alexa es una funcionalidad realizada por un desarrollador que te permite
interactuar con el asistente de voz a través de ciertos comandos de voz. El simil de una
Skill con algo más cotidiano pueden ser los canales de televisión, las aplicaciones del
móvil… Todos ellos están contenidos en dispositivos, pero cada uno tiene una
función/contenido diferente.
Por tanto, como comentábamos en el apartado de la historia de Alexa, ésta se activa con
un comando de voz, que, en este caso, es su nombre. Para poder comenzar un dialogo con
Alexa, se debe decir el comando de voz “Alexa” y a continuación pronunciar la frase que
hará que se active la Skill, por ejemplo: “Alexa, pon música jazz”. Por defecto, Alexa
viene con Skills ya instaladas que te permiten utilizar tu asistente de voz desde el primer
momento para cosas como buscar algún dato en internet, poner música o incluso jugar a
algún juego.
Alexa permite que sus propios usuarios puedan desarrollar Skills y de esa manera
personalicen aún más su experiencia de usuario. Los lenguajes de programación de una
Skill de Alexa pueden ser: Java, JSON, C++, JS, Python… Dando así al usuario la
facilidad de poder programar en el lenguaje que más experiencia tenga.
2.8.2 Dispositivos Echo

Un dispositivo Echo no es más que un altavoz en el que se reproduce el asistente de voz
Alexa. Dentro de la gama de los dispositivos Echo de Amazon hay diferentes tamaños.
Cada uno tiene unas características en función del uso que se le quiera dar. A
continuación, se listan los diferentes Echo que se pueden encontrar actualmente en el
mercado:
29
• Echo
• Echo Plus
• Echo Dot
• Echo Spot
Echo
Es el primer asistente virtual que sacó al mercado Amazon. Su precio oscila entre los 90
y los 110 euros. Las características del dispositivo son las siguientes:
• Siete micrófonos incorporados con cancelación de ruido, lo que permite que se el
dispositivo tenga una mejor escucha.
• Cuenta con dos altavoces en su interior y tecnología Dolby, la cual permite mayor
calidad de sonido.
• Dada su forma cilíndrica, el sonido es capaz de ser envolvente hasta 360º.
• Conexión Wifi
• Conexión bluetooth: permite conectar Alexa a otros dispositivos.
Figura 25: Echo de Amazon [25]
Echo Plus
Este asistente fue la evolución del asistente Echo. El precio de este dispositivo es
aproximadamente de 150 euros. Tiene exactamente las mismas características que el
primero pero Amazon añadió más funcionalidad y realizó los siguientes cambios:
• En cuanto a lo estético, es muy similar. Tiene forma cilíndrica pero en este caso,
el Echo Plus es más estético.
• Incorpora una integración con Zigbee. Zigbee es una interfaz que se usa en
tecnología domótica que permite a Alexa conectarse con otros dispositivos. En los
otros modelos de Echo, si se quiere conectar el dispositivo, hay una Skill que debe
estar programada para poder hacer esa vinculación.
Figura 26: Echo Plus de Amazon [26]
30
Echo Dot
Este es el asistente virtual más pequeño que tiene Amazon en el mercado y a su vez el
más barato y asequible siendo su precio 60 euros. Las características técnicas de este
dispositivo son:
• Cuatro micrófonos incorporados: Permite que el dispositivo escuche a pesar de
que pueda haber ruido
• Clavija para conectarse a la corriente.
• Conexión Wifi
• Conexión bluetooth: le permite conectarse con otros dispositivos.
Dentro de esta gama de dispositivos, Amazon ha ido evolucionando en cuanto al diseño,

desde una forma cilíndrica pequeña hasta ser de forma esférica. Además, ha incluido en
modelos superiores un reloj digital que se visualiza en el propio altavoz. El precio de este
dispositivo con reloj incorporado incrementa a 70 euros aproximadamente.
Figura 27: Echo Dot de Amazon [27]
Echo Spot
Este asistente es el único hasta la fecha que tiene una pantalla táctil que permite
seleccionar la Skill que se va a utilizar como si fuera una aplicación de un teléfono móvil.
El costo del dispositivo es de 130 euros. Las características de este dispositivo son las
siguientes:
• Cuatro micrófonos incorporados
• Pantalla táctil.
• Cámara en la parte delantera que te permite poder realizar videollamadas por
ejemplo.
• Wifi
• Bluetooth
Figura 28: Echo Spot de Amazon [28]
31
En este trabajo de final de grado se va a utilizar el aparato Echo Dot ya que el
desarrollador es usuario de este dispositivo.
2.9 Google Assistant

Google Assistant es el asistente de voz de la empresa Google que viene integrado en su
dispositivo Google Home. Al igual que Alexa, Google Assistant se basa en “acciones”.
En este apartado se detallarán las posibilidades que ofrece Google Assistant con respecto
a sus “acciones” y las características técnicas de los diferentes modelos de dispositivos
de Google assistant que existen actualmente en el mercado.
2.9.1 ¿Qué es una acción?

Una acción de Google Assistant es una funcionalidad que permite al asistente de voz
interactuar con la persona a través de comandos de voz pudiendo así realizar tareas, tener
una conversación o incluso jugar a algún juego.
Al igual que Alexa, Google permite que sus usuarios se creen sus propias acciones
añadiendo funcionalidad extra y creando así su experiencia a medida. Además, Google
proporciona a sus desarrolladores lo que denominan rutinas. Las rutinas son un conjunto
de acciones que permiten que, con un solo comando de voz, el asistente de voz pueda
realizar varias tareas o responder al usuario con diferentes oraciones. Por ejemplo, al decir
“buenas noches” el asistente podría poner el despertador a una hora en concreto,
contestarte “que descanses” y decirte el tiempo que hará al día siguiente.
Los lenguajes de programación que soporta Google Assistant para sus acciones son JS,
C/C++, Python o Java… Por lo que el usuario también tendrá la facilidad de poder
programar en el lenguaje que más experiencia tenga.
2.9.2 Dispositivos de Google Home

Los dispositivos de Google son aquellos que únicamente se utilizan para contener el
asistente de Google Assistant. Entre ellos existe una diferencia en cuanto a diseño e
incluso en funcionalidades que permiten. Entre ellos se encuentran los siguientes:
• Google Home
• Google Home mini
• Google Nest audio
• Google Nest Hub
Google Home
Es el primer dispositivo que salió al mercado cuando apareció el asistente de Google. El
precio de Google Home oscila los 150 euros. Las características técnicas son las que se
detallan a continuación:
• Tiene dos micrófonos que permiten hablar a distancia y que el aparato reconozca
la voz.
• Un altavoz con capacidad de reproducir los graves de manera clara y los graves
sin distorsión.
• Wifi
• Bluetooth
32
Figura 29: Google Home [29]
Google Home mini

Esta es la versión más compacta del aparato Google Home y también la más reconocida.
Su costo es de unos 70 euros aproximadamente. Las características técnicas del producto
son:
• Contiene dos micrófonos que permiten captar la voz a grandes distancias
• Chromecast integrado: Chromecast es un dispotivo de Google que permite que
una televisión reciba contenido desde otro dispositivo como puede ser un móvil o
un ordenador portátil. De esta manera, el usuario puede ver en la televisión un
video de youtube aunque la televisión no tenga dicha aplicación.
• Altavoz con sonido 360º
• Wifi
• Bluetooth
Figura 30: Google Home mini [30]
Google Nest Audio

Este dispositivo es la versión mejorada del primer Google Home. Su diseño es más
refinado y compacto y además, aúna características de Google Home y de Google Home
mini. Su precio actualmente es de 99 euros. Las características técnicas de este dispositivo
son:
• Tiene tres micrófonos de larga distancia.
• Chromecast integrado
• Wifi
• Bluetooth
Una curiosidad sobre este dispositivo es que la estructura del altavoz está hecho con un
70% de material reciclado por lo que lo hace bastante sostenible y favorece al medio
ambiente.
33
Figura 31: Google Nest audio [31]
De este modelo existe una versión mini con prácticamente las mismas características y
con el formato de Google Home mini, denominado Google Nest mini. Este dispotivo está
hecho con un 100% de material reciclado y es el más económico, sorprendentemente
porque tiene las mismas características que el Google Nest audio, y tiene un percio de 39
euros.
Google Nest Hub

El Google Nest hub es la primera pantalla táctil que albergaba un asistente de voz que
sacó google al mercado. Su precio ronda los 60 euros en la actualidad. Sus
características técnicas son:
• Pantalla táctil de 7 pulgadas
• Dos micrónofos con largo alcance.
• Conexión wifi
• Bluetooth
Figura 32: Google Nest Hub [32]
34
III. Análisis y diseño
En este apartado, se describirá la selección y utilización de los diferentes
sistemas/dispositivos dentro del proyecto, así como el modelo de datos que se empleará
para el almacenado de la información dentro del CRM.
3.1 Salesforce
En primer lugar, el sistema de almacenado de datos elegido para el desarrollo de este
proyecto de final de grado será el CRM Salesforce. Esta elección se basa en la amplia
experiencia del desarrollador del proyecto en esta herramienta, además de las titulaciones
que tiene certificadas por la compañía Salesforce.
En concreto, este proyecto se basará en la nube de Service, nube de Salesforce orientada
al soporte que proporciona la empresa a su cartera de clientes para la resolución de
incidencias. Nuestra propuesta se basará en proporcionar a cualquier empresa que tenga
un servicio de soporte, un sistema centralizado donde almacenar su información de
clientes e incidencias con varios canales de entrada, entre ellos, Alexa.
A continuación, se definen algunos términos que se utilizarán a lo largo del TFG 9, para
un mejor entendimiento de la propuesta:
• Modelo de datos: El modelo de datos es la arquitectura en la que se almacenarán
los datos de la empresa dentro del sistema de gestión de información (CRM). En
este TFG y, como buena práctica de la propia empresa Salesforce, se tratará de
almacenar la información a través del modelo de datos estándar del CRM.
• Objetos: Los objetos son los módulos donde se almacena la información dentro
de Salesforce. Los diferentes objetos, vinculados entre sí con diferentes relaciones
que se explican a continuación, construyen el modelo de datos. En este apartado
realizaremos una breve descripción de los objetos que se utilizarán para la
construcción del proyecto.
• Registros: Se trata de la información que almacena la empresa categorizada por
cada uno de los objetos. Por ejemplo, en el objeto Cliente la empresa tendrá
almacenados los datos de Alba González. Dentro del objeto cliente, no solo
estarán los datos de Alba González sino de los demás clientes. Cada uno de esos
clientes, incluida Alba González, es un registro.
• Tipos de registro: A la hora de optimizar un sistema CRM, cada uno de los
objetos cuenta con la posibilidad de tener varios tipos de registro. Los tipos de
registro te permiten tener diferentes formatos de página, lo cual es muy útil si se
tiene diferentes procesos de soporte.
• Procesos de soporte: Se define como proceso de soporte al conjunto de estados
por el que tiene que pasar un registro desde su creación hasta su cierre. Cada
proceso de soporte va relacionado a un tipo de registro. Por ejemplo, existe la
posibilidad que el cliente utilice los canales de entrada de soporte para incidencias
o para dudas. Para cada una de las variantes mencionadas anteriormente se tendrá
un proceso de soporte ya que los estados serán diferentes.
• Formatos de página: Permiten configurar como el usuario del CRM visualizará
la información dentro de un registro. Se compone por campos y listas
relacionadas. Los formatos de página además dan la posibilidad de marcar los
campos como obligatorios (no se permite almacenar la información del registro si
9
TFG: Trabajo de final de grado
35
no se rellena el campo obligatorio) o como solo lectura (el valor del campo no lo
puede modificar el usuario, aunque si se puede modificar a través de un
automatismo).
• Campos: Espacios donde se almacena la información dentro de los diferentes
registros. En función de la tipología del campo (numero, texto, fecha, lista de
selección…) se podrán introducir unos valores u otros. Además de en los formatos
de página, los campos también se pueden marcar como obligatorios desde su
creación en la parte de configuración del CRM. Esto no es aconsejable ya que, si
tienes varios procesos de soporte, la obligatoriedad a nivel de campo es trasversal
a cualquier proceso. Es por ello que la buena práctica indica que la obligatoriedad
de campos se realice a través del formato de página.
• Relaciones entre objetos: Son la manera de determinar cómo interactúan los
registros de los diferentes objetos entre ellos. Por ejemplo, Alba Gonzalez puede
tener una o más incidencias abiertas con la empresa y, por tanto, el objeto Cliente
estará directamente relacionado al objeto Incidencias. Cabe destacar los tipos de
relaciones que maneja Salesforce de manera estándar:
o Lookup: Es una relación de 1 a N o de N a 1. Es decir, este tipo de
relaciones se utilizan para buscar dentro de un registro uno o varios
registros que están relacionados. No existe, en este caso, una dependencia
de un objeto principal y otro secundario por lo que es posible que uno de
los registros de un objeto no tenga la necesidad de tener un registro de otro
objeto relacionado. Por ejemplo: el contacto Alba González pertenece a la
empresa Alba Inc. y por tanto está relacionado a ella. Pero es posible que
el cliente Alba González sea un particular y, en ese caso, no estará
relacionado a ningún registro de empresa.
o Master-Detail: Es una relación de 1 a N y existe un objeto que es principal
y otro que es secundario. Este tipo de relaciones se utilizan para constituir
relaciones estrechas de registros. Existe por definición una dependencia
entre el registro padre y el registro hijo, de tal manera que, al crear el
registro hijo, siempre se debe relacionar con el registro padre. Además, en
caso de que el registro padre se elimine, el registro hijo también se
eliminará. Por ejemplo: El contacto Alba González pertenece a la empresa
Alba Inc. y por tanto está relacionado a ella. Al contrario que en el ejemplo
anterior, el servicio que se ofrece no es apto para particulares por lo que
todos los contactos que se tengan estarán relacionados a Alba Inc.
Salesforce, con el fin de adaptar el modelo de datos lo máximo al proceso de negocio,

permite, bajo petición, activar otro objeto similar a uno de sus obejtos estándar. El objeto
Cuenta está diseñado para albergar la información de las empresas que tienen contratado
un servicio (tipo de negocio business to business o B2B). No obstante, existen empresas
que tratan directamente con la persona y no a través de otra empresa (tipo de negocio
business to customer o B2C). El modelo de datos estándar de Salesforce no serviría para
esta útilma casuística ya que el objeto cuenta está diseñado para albergar la información
de una empresa. Por ello, bajo petición, Salesforce te permite activar el objeto Cuentas
personales. Este objeto es el que utilizaremos en nuestro proyecto ya que la empresa que
adquiera el CRM tratará directamente con el cliente y no con una empresa.
36
A continuación, se mostrará el modelo de datos diseñado para este proyecto, indicando
sus tipos de relaciones y algunos campos relevantes.
Figura 33: Modelo de datos
3.2 Amazon Web Services

La herramienta que utilizaremos y en la cual se apoyará la skill de Alexa de este trabajo
de final de grado es Amazon Web Services.
Amazon Web Services es una plataforma desarrollada por la empresa Amazon, alojada en
la nube que provee servicios a empresas y clientes que buscan desarrollar su potencial a
nivel de seguridad, almacenamiento de datos, funcionalidad y accesibilidad entre otros.
De todos los sistemas alojados en la nube que proveen servicios a quien lo utiliza, Amazon
Web Services está catalogada como la plataforma más potente del mercado (Holori,
2021).
Para poder utilizar esta herramienta, será necesario crear un usuario. Para ello, será
necesario navegar a la dirección https://aws.amazon.com/es/ y hacer click en Crear una
cuenta de AWS. En este punto, el asistente de creación de cuentas de Amazon solicitará
los siguientes datos:
• Dirección de correo electrónico
• Contraseña
• Nombre de la cuenta AWS
• Selección de uso de AWS
o Profesional : Para el trabajo, escuela u alguna otra organización
o Personal: Para proyectos propios
• Nombre completo
• Número de teléfono
• País o región
37
• Dirección
• Ciudad
• Estado, provincia o región
• Código postal
• Aceptar los términos del contrato del usuario de AWS
El servicio de dar de alta una cuenta en AWS, es totalmente gratuito. No obstante, en el

registro, se solicita un método de pago de tarjeta bancaria y Amazon te hace un cargo de
1€ hasta que verifica la identidad de la persona asociada a la cuenta. Una vez verificada
la identidad, esta cantidad es devuelta en un periodo de 3 a 5 días laborales.
Una vez finalizada la suscripción, se tendrá acceso a la consola de administración de

Amazon Web Services donde se podrá comenzar la configuración de las diferentes
funcionalidades que se utilizarán en este TFG.
Figura 34: Consola de AWS
3.3 Alexa Skills Kit

Alexa Skills Kilt (ASK), son herramientas, documentación y self-service APIs con las que
puedes desarrollar skills de Alexa.
Para poder comenzar con la creación de la skill de Alexa, se deberá disponer de una cuenta
de Amazon. Esta cuenta no es la misma que la cuenta creada para AWS. En caso de no
tener una cuenta de Amazon, se navegará a la dirección
https://developer.amazon.com/alexa/console y, haciendo click en Identificarse, se
navegará a la página de login. Dentro de la página de login, existe la opción de crear una
nueva cuenta. Para este registro se solicitará la siguiente información:
• Nombre
• Correo electrónico
• Contraseña
Cuando se hayan introducido estos datos, Amazon proporciona una contraseña de un solo
uso, a través del correo electrónico indicado en el formulario, con el fin de verificar el
correo electrónico introducido.
38
Al introducir esta contraseña de único uso, se redirigirá al siguiente formulario en el cual
se solicitará información personal como:
• Apellidos
• Ciudad
• Nombre de la empresa/desarrollador
• Número de teléfono
• Dirección
• Código postal
• Términos de Amazon Developer Services Agreement
Finalmente, se navegará a la página Alexa Developer Console donde se podrá comenzar

la implementación de la skill. En esta pantalla, se podrán visualizar las diferentes skills
que se tengan implementadas con la cuenta de desarrollador de Alexa, así como su estado,
lenguaje de la skill o fecha de última modificación.
Figura 35: Alexa Developer Console
39
IV. Implementación y Desarrollo
El inicio de la implementación de este TFG se basará en la creación y configuración del
entorno CRM que utilizaremos, así como la integración con los diferentes canales de
comunicación que el cliente tendrá disponibles para la gestión de sus incidencias. La
implementación del sistema CRM permite gestionar a los agentes del departamento de
atención al cliente las incidencias en una misma plataforma, teniendo acceso así a una
visión 360º de sus clientes y pudiendo anticipar sus necesidades.
Teniendo en cuenta el modelo de datos detallado en la sección anterior, se realizará la

configuración de los siguientes objetos dentro del CRM:
• Cuenta personal
• Casos
• Pedidos
• Líneas de pedido
• Productos
• Catálogo
• Entrada de listas de precios
Por otro lado, se realizará la integración de los diferentes canales de contacto por los que
el cliente puede ponerse en contacto con la empresa. Los canales implementados son:
1. Manual por el agente
2. Email
3. Formulario Web
4. Integración con Alexa
Por último, se realizará la integración con la plataforma Amazon Web Services para
ofrecer al cliente un canal de contacto con la empresa adicional a través del dispositivo
Alexa.
El proceso de negocio que se implementará dentro Salesforce será un proceso de soporte

en el que se dará entrada a las incidencias a través de los diferentes canales de entrada.
La implementación cuenta con un sistema de asignación a los agentes disponibles,
priorización de incidencias y gestión de tiempos, así como un sistema de escalado o
traspaso de incidencias a otros agentes. El agente será capaz de tener un seguimiento de
la incidencia que al inicio le fue asignada hasta su finalización.
A continuación, se muestra el diagrama de flujo del proceso de soporte que se

implementará en este trabajo de final de grado.
40
Figura 36: Proceso de soporte
4.1 Implementación de Salesforce

Para comenzar con la implementación de Salesforce, es necesario adquirir uno de los
licenciamientos que se explican dentro de la sección de Estado del Arte, licenciamientos.
Dado que no se dispone de dichas licencias, Salesforce proporciona licencias gratuitas
para desarrolladores. Este tipo de licencia será la utilizada en este TFG.
Para obtener la licencia de desarrollador, navegamos a la URL

https://developer.salesforce.com/signup e introduciremos los datos de la empresa. En
este proyecto la empresa se llamará AGlexa. Los datos para introducir son:
• Nombre: Alba
• Primer apellido: González
• Email: alba.ggines@gmail.com
• Puesto dentro de la compañía: Elegimos el puesto de administrador dado que el
usuario dentro del CRM será el administrador del sistema.
• Compañía: AGlexa
• País: España
• Código postal: 28006
• Nombre de usuario: Corresponde al nombre de usuario que se tendrá dentro de
Salesforce. El nombre de usuario será: alba.ggines+tfg@gmail.com
Una vez introducidos los datos y aceptada la política de privacidad, se genera el entorno
de Salesforce donde comenzaremos a configurar la herramienta.
4.1.1 Modelo de datos

Dentro de esta sección se detalla la configuración de los diferentes objetos, campos y
formatos de página dentro de Salesforce.
41
Previo a realizar cualquier configuración del modelo de datos y como se explica en la
sección anterior, hay que enviar una petición a Salesforce para que nos activen la
utilización de Cuentas personales. Previo a realizar esta petición, desde el menú de
configuración de Salesforce, se accede a la sección de Configuración de Cuentas y se
habilita la casilla “Permitir al servicio de atención al cliente activar cuentas personales”.
Figura 37: Configuración de cuentas personales
Tras haber seleccionado esta opción, se realiza la petición a Salesforce a través su propio
equipo de soporte, abriendo una incidencia a través de la página
https://help.salesforce.com/s/. Una vez Salesforce activa la opción, se tiene disponible el
uso de cuentas personales.
Los campos en Salesforce se definen por dos etiquetas, el Nombre del campo; que es lo
que el usuario del CRM visualiza por pantalla; y el nombre API; que es lo que se utiliza
en desarrollo y configuración de la herramienta para identificar un campo de un objeto.
Entre los campos de cada una de los objetos definidos en el modelo de datos
encontraremos:
Cuentas personales
Como en apartados anteriores hemos definido, las cuentas personales las utilizaremos
para almacenar la información de los clientes. Los campos que se utilizarán dentro del
objeto Cuenta personal serán:
42
Cuentas personales
Nombre del campo Nombre API Tipo de dato
Nombre FirstName Texto
Apellido* LastName Texto
Cumpleaños PersonBirthdate Fecha
Número de documento* DocNumber Texto
Tipo de documento* DocType Lista de selección
Código de cliente Number Texto
Teléfono* Phone Telefónico
Móvil PersonMobilePhone Telefónico
Email* PersonEmail Correo electrónico
Dirección de envío ShippingAddress Texto
Dirección de facturación BillingAddress Texto
Valoración Rating Lista de selección
Activo Active Casilla
Acepta política de privacidad PrivatePolicyAccepted Casilla
Acepta el envío de comunicaciones InformationPolicyAccepted Casilla
Tabla 5: Campos del objeto cuenta personal
Los campos marcados con un asterisco rojo están configurados como campos obligatorios
dentro del sistema. Esto quiere decir que, cuando el gestor cree un registro de cuenta
personal o lo edite, siempre le pedirá que esos campos obligatorios estén cumplimentados
antes de guardar.
Para los campos de tipo lista de selección, se configurarán los valores que se detallan a
continuación:
• Tipo de documento
o CIF
o NIE
• Clasificación
o VIP
o Caliente
o Frio
En la configuración del formato de página se utilizarán diferentes secciones de tal manera

que la información quede ordenada según el tipo de datos que contengan.
• Información de la cuenta personal
• Información de Contacto
• Dirección
• Privacidad
43
Figura 38: Formato de página de cuentas personales
Casos
El objeto Casos se utiliza para almacenar la información referente a las incidencias
abiertas por los diferentes clientes a través de los diferentes canales de contacto.
Los campos que se utilizarán dentro del objeto Casos serán:
Casos
Cuenta AccountId Buscar (Cuenta)
Estado Status Lista de selección
Asunto Subject Texto
Descripción Description Texto
Prioridad Priority Lista de selección
Motivo del Caso Case Reason Lista de selección
Comentarios internos InternalComments Texto
Tipo Type Lista de selección
Número del Caso CaseNumber Autonumérico
Origen del Caso CaseOrigin Lista de selección
Correo electrónico de ContactEmail Correo electrónico
contacto
Teléfono de Contacto ContactPhone Teléfono
Fecha y hora de apertura OpenedDate Fecha y hora
Fecha y hora de cierre CloseDate Fecha y hora
Pedido Order__c Buscar (Pedido)
Correo electrónico Web SuppliedEmail Correo electrónico
Teléfono Web SuppliedPhone Texto
Propietario del Caso OwnerId Buscar(Usuario, Cola)
Tabla 6: Campos del objeto Caso
continuación:
• Estado
o Nuevo
o En análisis
44
o Pendiente información cliente
o Pendiente información interna
o Cerrado
• Prioridad
o Alta
o Media
o Baja
• Motivo del Caso
o Queja
o Pedido se retrasa
o Pedido no ha llegado
o Producto equivocado
o Otros
• Tipo
o Incidencia
o Consulta
o Sugerencia
• Origen del Caso
o Teléfono
o Web
o Email
o Manual
o Alexa
En la configuración del formato de página se utilizarán diferentes secciones de tal

manera que la información quede ordenada según el tipo de datos que contengan.
• Información del Caso
• Información de contacto
• Descripción
• Información Web
Figura 39: Formato de página de Casos
45
Pedidos
Para poder utilizar el objeto Pedidos y que quede relacionado a los Casos, dentro de la
configuración de Salesforce, en la sección de “Configuración de pedidos”, marcamos la
casilla de Activar pedidos. De esta manera, Salesforce da acceso al objeto estándar de
pedidos.
Figura 40: Activación de pedidos
El objeto Pedidos se utiliza para almacenar la información referente a los productos

contratados o adquiridos por los clientes a modo de agrupador. Cada uno de los productos,
se relacionarán al pedido a través del objeto línea de pedido que se detallará más adelante
en este apartado. Los campos que se utilizarán dentro del objeto Pedidos serán:
Pedido
Cuenta AccountId Buscar (Cuenta)
Estado Status Lista de selección
Número de pedido OrderNumber Autonumérico
Fecha inicial del pedido InitialDate Fecha
Fecha de finalización del EndDate Fecha
pedido
Tipo de pedido Type Lista de selección
Cantidad del pedido Amount Moneda
Dirección de facturación BillingAddress Texto
Dirección de envío ShippingAddress Texto
Gastos de envío ShippingCost Fórmula
Importe total TotalAmount Fórmula
Tabla 7: Campos del objeto Pedido
46
continuación:
• Estado
o Borrador
o En reparto
o Enviado
• Prioridad
o Normal
o Recurrente
Los campos formula, son un tipo de campos que se auto calculan en la creación o edición
de los registros. Para el objeto de Pedidos, se han creado dos campos formulas que
calculan:
• Gastos de envío
o Calcula los gastos de envío del pedido en función de la valoración de la
Cuenta asociada. Si el cliente es un cliente “VIP”, los gastos de envío son
0€; si el cliente es un cliente “Caliente”, los gastos de envío es 1€; y para
cualquier otro cliente, los gastos de envío son 2,50€.
• Importe total
o Calcula el importe total sumando la cantidad del pedido más los gastos de
envío.
• Información del pedido
• Datos de contacto
• Datos de incidencia
Figura 41: Formato de página de pedidos
Producto de pedido
El objeto Producto de pedido se utiliza para relacionar los productos
solicitados/contratados por el cliente al pedido. Los campos que se utilizarán dentro del
objeto línea de pedido serán:
47
Producto de pedido
Pedido OrderId Buscar (Pedido)
Producto Product2Id Buscar (Producto)
Precio por unidad UnitPrice Moneda
Precio total TotalPrice Moneda
Descripción de la partida Description Texto
Precio de lista ListPrice Moneda
Id externo ExternalId Texto
Tabla 8: Campos de Línea de pedido
Los campos monetarios, reflejan los siguientes datos:

• Precio por unidad: Es el precio que tiene una unidad del producto seleccionado.
Este valor se puede modificar aplicando un descuento o un incremento del precio
del producto.
• Precio total: Es el precio total de la línea del pedido teniendo en cuenta la cantidad
de productos seleccionados.
• Precio de lista: Es el precio del producto según el catálogo. Este precio no es
modificable, es el valor por defecto.

• Información del producto
• Precios
Figura 42: Formato de página de línea de pedido
Producto
El objeto Producto se utiliza como objeto maestro de productos, es decir, se almacenan
los datos de los productos y servirá para relacionarlo con las demás entidades que
completan el modelo de datos. Los campos que se utilizarán dentro del objeto producto
serán:
Producto
Activo Active Casilla
Código de producto ProductCode Texto
Descripción del producto Description Texto
Id externo ExternalId Texto
Nombre del producto Name Texto
Tabla 9: Campos de producto
48
En la configuración del formato de página se utilizará una única sección denominada
Información del producto.
Figura 43: Formato de página de producto
Entrada de lista de precios

El objeto Entrada de lista de precios se utiliza para establecer un precio genérico a un
producto. Es decir, cada uno de los registros de este objeto, estará relacionado a un
producto y tendrá un campo donde se indique el precio de este. Los campos que se
utilizarán dentro del objeto entrada de lista de precios serán:
Entrada de lista de precios

Activo IsActive Casilla
Catálogo PricebookId Buscar (Catálogos)
Producto Product2Id Buscar (Producto)
Precio de lista ListPrice Moneda
Código de producto ProductCode Auto calculado (Texto)
Tabla 10: Campos de entrada de lista de precios

Información.
Figura 44: Formato de página de entradas de lista de precios
Catálogo
El objeto Catálogo se utiliza como maestro agrupador de entradas de precios de
productos. Es decir, un catálogo está relacionado con las diferentes entradas de precios
agrupándolas y constituyendo la oferta de productos que el cliente tiene disponibles, así
como sus precios. Para el caso de AGlexa, solo utilizaremos un catálogo que será el que
por defecto nos proporciona la plataforma Salesforce.
Los campos que se utilizarán dentro del objeto catálogo serán:
Catálogo
Nombre Name Texto
Activo IsActive Casilla
Código de producto ProductCode Auto calculado (Texto)
Tabla 11: Campos de objeto catálogo
49
Información.
Figura 45: Formato de página de catálogo
4.1.1.1 Proceso de soporte

Un proceso de soporte en Salesforce sirve para definir los estados por los que cada tipo
de Caso puede pasar.
La tipología del Caso viene definida por el tipo de registro. El tipo de registro en
Salesforce especifica el proceso de negocio que ese registro sigue, personalizando así el
formato de página y los valores de selección de los campos de tipo lista de selección.
En el escenario de la empresa AGlexa, se tendrán tres tipos de Casos como ya se ha
comentado en apartados anteriores: Incidencias, Consultas y Sugerencias; aunque, se
tendrán dos tipos de registro: Incidencias/Consultas, Sugerencias y Casos genéricos.
La decisión de tener esos tipos de registro se basa en que, tanto las incidencias como las
consultas, tendrán disponibles los mismos estados del proceso de soporte y las
Sugerencias, seguirán otro proceso. El tipo de registro Casos genéricos, aplicará para los
Casos que provengan de un canal en el que no se pueda tipificar el Caso desde un inicio,
sino que haga falta un gestor que lo realice, por ejemplo, los Casos creados a través del
correo electrónico.
Para configurar los dos procesos de soporte que se han definido, dentro de la
configuración de Salesforce en el apartado Servicio > Procesos de soporte, al hacer click
en el botón Nuevo, se navegará a una pantalla donde se establecerá únicamente el nombre
del proceso de soporte y la descripción.
Figura 46: Creación de proceso de soporte de incidencias y consultas
50
Figura 47: Creación de proceso de soporte de Sugerencias
A continuación, se navegará a una pantalla donde se tendrán que elegir los estados por
los cuales, los Casos que tengan ese proceso de soporte, tendrán la opción de pasar además
de seleccionar el estado predeterminado, en nuestro caso será “Nuevo”.
Figura 48: Selección de estados de proceso de soporte de incidencias y consultas
Figura 49: Selección de estados de proceso de soporte de sugerencias
51
Para configurar los tipos de registro que se definen para los Casos, dentro de la
configuración de Salesforce, en la sección Gestor de Objetos > Caso, crearemos los dos
tipos de registro: Incidencias/Consultas y Sugerencias. Al hacer click en Nuevo, aparece
una pantalla donde se rellena:
• Nombre del tipo de registro
• Proceso de soporte al que pertenece
• Descripción
• Activo
• Acceso a esta tipología de registro por los diferentes usuarios del sistema.
Figura 50: Configuración tipo de registro Incidencias y Consultas
Al continuar con la configuración, se establece el formato de página que se utilizará para

este tipo de registro de Casos. El formato de página para ambos tipos de registro de Casos
será el mismo.
Figura 51: Configuración tipo de registro de sugerencias
En cuanto a la selección del tipo de registro, en la creación del Caso, el usuario tendrá
que decidir que tipo de Caso quiere crear, una incidencia/consulta o una sugerencia. En
cambio, para las creaciones automáticas de Casos, esta selección de tipo de registro
deberá ser automática y se basará en el campo Tipo de Caso.
52
Para esta selección automática, se ha desarrollado un Flujo de Salesforce. Un Flujo en
Salesforce permite realizar operaciones de creación, actualización, eliminación de
registros, presentar pantallas para introducir valores… Entre los tipos de flujos que hay
disponibles en la plataforma, los más utilizados son los siguientes:
• Flujo de pantalla: Permite realizar un proceso automático incorporando pantallas
que guíen al usuario a través de dicho proceso.
• Flujo desencadenado por un registro: La acción de creación o modificación de un
registro hace que se dispare este tipo de flujos que realizan un proceso.
• Flujo desencadenado por programación: Se programa el proceso el cual se va a
desencadenar.
Para la asignación del tipo de registro en los Casos automático, se utilizará un flujo de
tipo desencadenado por un registro ya que será en la creación del Caso donde se ejecute
este proceso. El Flujo se denominará Asignación Tipo de Registro y se configurará de la
siguiente forma:
1. Se establece que el objeto donde se va a aplicar el automatismo es en el objeto
Caso, así como que el momento de desencadenar la acción de actualizar el tipo de
registro es en la creación de un Caso. Además, se selecciona que esta acción
únicamente ocurra siempre y cuando el campo Tipo del objeto Caso, no esté vacío.
Figura 52: Pantalla de inicio de configuración del flow
2. Establecer la decisión en base al campo Tipo de Caso. Una decisión en un flujo

tomará tantos caminos como tenga dicha decisión configurada. En nuestro Caso
tendrá tres caminos: Incidencia/Consulta, Sugerencia u Otros. Cada uno de esos
caminos conduce a una actualización de Tipo de registro diferente.
53
Figura 53: Pantalla de configuración de decisión en el flow
3. Buscar el id único del tipo de registro de Caso que se requiere. Para ello se hará
una búsqueda en el objeto que almacena todos los Ids de tipo de registro de
Salesforce y filtrando por el Objeto Caso y el Nombre del tipo de registro, se
obtiene la Id. Esta búsqueda se podría ahorrar si se cumplimenta el Id del tipo de
registro directamente en el flujo y se realiza la actualización, pero, siguiendo las
buenas prácticas, no es aconsejable tener ningún Id escrito dentro de un flujo. El
Id del Tipo de registro se almacena en la variable que se ha denomina “RTId”.
Figura 54: Pantalla de obtención de tipo de registro
4. Actualización del Caso con el tipo de registro que corresponda. Se selecciona que
el campo Tipo de registro del Caso, se actualice con el valor de la variable “RTId”.
54
Figura 55: Pantalla de modificación de registros
Una vez se ha configurado el flujo entero, para que comience a ser funcional, se activa
haciendo click en el botón activar.
Figura 56: Flow de asignación de tipos de registro
4.1.2 Configuración de seguridad

Salesforce divide la seguridad del dato entre dos vías: qué puedo hacer y qué puedo ver.
Para la configuración de “qué puedo hacer” existen lo que se denomina perfiles y
55
conjuntos de permisos y, para la configuración de “qué puedo ver” existen lo que se
denomina roles y reglas de colaboración.
Un perfil determina que es lo que dentro de Salesforce puede hacer un usuario. El perfil
gestiona desde las acciones que puedes hacer dentro de un registro, las aplicaciones a las
que puedes acceder, hasta los permisos por cada uno de los campos de los diferentes
objetos (si puedes únicamente verlo o editarlo también). Además, es la manera de común
de agrupar permisos para un grupo de usuarios dentro de la organización. En caso de que
se quiera dar permisos extras a uno o varios usuarios en concreto, se utilizarán los
conjuntos de permisos.
Los conjuntos de permisos son complementarios al perfil, es decir, no quitan permisos,
sino que otorgan más. Es un complemento ya que, se puede dar el caso, que una persona
tenga permisos especiales dentro de una empresa, y como buena práctica, no se configura
un perfil único para dicha persona, sino que se añade ese usuario al perfil que más se
asemeje y se establece el conjunto de permisos que necesite.
En la organización construida para la empresa AGlexa, se definen tres perfiles:

Administrador, Supervisor y Agente:
• Perfil Administrador: Tiene acceso a realizar cualquier acción dentro de la
herramienta. Puede realizar configuraciones nuevas, así como eliminar registros
o acceder a cualquier campo de cualquier objeto y modificarlo. Este perfil es con
el perfil que se configura Salesforce ya que es el único que tiene acceso a la
configuración de la herramienta.
• Perfil Supervisor: Tiene acceso a la aplicación de AGlexa y a modificar cualquier
campo de los objetos mencionados en el apartado anterior. Además, tiene acceso
a la eliminación de Productos, Entradas de listas de precios y Pedidos. No tendrá
acceso a eliminar Cuentas, Casos o Pedidos.
• Perfil Agente: Tiene acceso a la aplicación de AGlexa y a modificar cualquier
campo de los objetos mencionados en el apartado anterior. No tendrá acceso a
eliminar ningún registro de ninguno de los objetos, aunque si podrá modificarlos.
Salesforce determina la visibilidad a partir del campo propietario del registro. Siempre
que un usuario sea propietario de un registro, puede visualizar dicho registro. Si el
propietario del registro es una Cola, cualquier usuario que esté en la Cola tendrá los
mismos permisos de visualización o edición (si tiene acceso a nivel de perfil para editar).
Para configurar la visibilidad de los registros de un objeto, se tiene la configuración de
colaboración. Esta configuración permite establecer si un objeto es:
• Privado: Únicamente puede visualizar los registros de ese objeto el propietario.
Es decir, una cuenta cuyo propietario sea Alba González, si el objeto es privado,
solo la podrá ver Alba González.
• Solo lectura pública: Independientemente de quién sea el propietario del registro,
cualquier usuario puede verlo. Es decir, una cuenta cuyo propietario sea Alba
González, si el objeto es público en lectura, lo podrá ver cualquier otro usuario.
• Lectura/Escritura publica: Independientemente de quién sea el propietario del
registro, cualquier usuario puede verlo/editarlo (en caso de que por perfil tenga
permisos de edición del objeto). Es decir, una cuenta cuyo propietario sea Alba
González, si el objeto es público en lectura y escritura, lo podrá ver/editar
cualquier otro usuario.
• Controlado por principal: Si el objeto tiene una relación de tipo Principal detalle,
tal y como se explicaba en apartados anteriores, la visibilidad de los registros de
56
este objeto queda sujetas a la visibilidad del padre. Por ejemplo, si el Pedido está
ligado a la Cuenta con una relación principal detalle y la Cuenta tiene la visibilidad
privada, el Pedido también será privado.
En la organización de AGlexa, se tendrá configurada la visibilidad de cada uno de los

objetos de la siguiente manera:
Objeto Visibilidad
Cuentas Privado
Casos Privado
Pedido Controlado por padre
Línea de pedido Controlado por padre
Producto Público
Catálogo Público
Entrada de lista de precios Público
Tabla 12: Tabla de visibilidad de Objetos de Salesforce
A nivel de visibilidad de registros entre usuarios, también se tiene la configuración de los

roles. Los roles permiten tener una jerarquía que se aplica a la visualización de los datos
en el que, el usuario que tenga el rol superior tendrá acceso a toda la información de sus
roles inferiores. Para AGlexa, se tendrá configurada la jerarquía de roles de la siguiente
manera:
• Director general: Tiene acceso a ver toda la información de la compañía
independientemente de a que departamento pertenezca o a que ciudad.
• Director Dpto. Atención al cliente: Tiene acceso a toda la información referente
al departamento de atención al cliente de la compañía, independientemente de la
oficina a la que pertenezca o al usuario propietario del registro.
• Supervisor Madrid: Solo tiene acceso a la información de atención al cliente de
Madrid. Es decir, solo podrá ver Cuentas, Pedidos y Casos de Madrid. Además,
puede visualizar cualquier registro cuyo propietario sea uno de los agentes a su
cargo.
• Supervisor Barcelona: Solo tiene acceso a la información de atención al cliente de
Barcelona. Es decir, solo podrá ver Cuentas, Pedidos y Casos de Barcelona.
Además, puede visualizar cualquier registro cuyo propietario sea uno de los
agentes a su cargo.
• Agente Madrid: Solo tiene acceso a la información de atención al cliente de
Madrid. Es decir, solo podrá ver Cuentas, Pedidos y Casos de Madrid.
• Agente Barcelona: Solo tiene acceso a la información de atención al cliente de
Barcelona. Es decir, solo podrá ver Cuentas, Pedidos y Casos de Barcelona.
57
Figura 57: Jerarquía de roles en Salesforce
La visibilidad de los departamentos, con la configuración de objetos realizada no sería

suficiente ya que, los registros tanto de Cuentas, Pedidos, Líneas de Pedidos y Casos están
privados y, por tanto, el Agente de Madrid, solo verá su información y no la de sus
compañeros. Para solventar este punto, existen las reglas de colaboración. Las reglas de
colaboración permiten a través de ciertos criterios, compartir la información entre
usuarios. Por ejemplo, siempre que el registro tenga como propietario un usuario que
tenga el rol de Agente Madrid, compártelo con todos los usuarios que tengan ese rol. De
esta manera, la información quedará compartida entre usuarios.
A continuación, se detallan las reglas de compartición desarrolladas:
• Cuentas
o Si el campo Ciudad o Provincia de la cuenta contiene el término “Madrid”
se comparte con el rol Supervisor Madrid con acceso a lectura y escritura.
o Si el campo Ciudad o Provincia de la cuenta contiene el término “Madrid”
se comparte con el rol Agente Madrid con acceso a lectura.
o Si el campo Ciudad o Provincia de la cuenta contiene el término
“Barcelona” se comparte con el rol Supervisor Barcelona con acceso a
lectura y escritura.
o Si el campo Ciudad o Provincia de la cuenta contiene el término
“Barcelona” se comparte con el rol Agente Barcelona con acceso a lectura.
o El director del departamento de atención al cliente verá todas las cuentas.
o El director general verá todas las cuentas.
• Casos
o Si el campo Ciudad o Provincia de la Cuenta asociada al Caso contiene el
término “Madrid” se comparte con el rol Supervisor Madrid con acceso a
término “Madrid” se comparte con el rol Agente Madrid con acceso a
lectura.
término “Barcelona” se comparte con el rol Supervisor Barcelona con
acceso a lectura y escritura.
término “Barcelona” se comparte con el rol Agente Barcelona con acceso
a lectura.
o El director del departamento de atención al cliente verá todos los Casos.
o El director general verá todos los Casos.
58
• Pedidos: La visibilidad de los pedidos estará gestionada por la visibilidad de la
Cuenta a la que están relacionada. Por tanto, la visibilidad de los Pedidos será la
siguiente:
término “Madrid” se comparte con el rol Supervisor Madrid con acceso a
término “Madrid” se comparte con el rol Agente Madrid con acceso a
lectura.
término “Barcelona” se comparte con el rol Supervisor Barcelona con
acceso a lectura y escritura.
término “Barcelona” se comparte con el rol Agente Barcelona con acceso
a lectura.
o El director del departamento de atención al cliente verá todos los Casos.
o El director general verá todos los Casos.
• Productos
o Tanto el director del departamento de atención al cliente como sus
subordinados tendrán acceso a visualizar la información.
o El director general tendrá acceso a ver y editar cualquier producto.
4.1.3 Interfaz de usuario

Una vez configurado el modelo de datos junto con los campos y los formatos de página,
dentro de esta sección se detallará la configuración de la interfaz del usuario: navegación,
componentes dentro de la visualización de cada uno de los objetos, tema con colores
corporativos…
4.1.3.1 Consola
Para navegar a través de los diferentes registros y objetos, Salesforce proporciona las
denominadas aplicaciones. Las aplicaciones son un agrupador de funciones y objetos que
permiten al usuario realizar su trabajo diario. A nivel de aplicación se define el logo, los
objetos a los que se tiene acceso, qué perfiles de la organización tiene acceso a que
aplicación y las funciones estándar.
En cuanto a los tipos de aplicaciones, basándonos en la navegación, existen dos tipos:

estándar y por consola.
La navegación estándar permite tener una barra de navegación con acceso a cada uno de
los objetos configurados en la aplicación. La navegación de cualquier objeto o registro
implica recargar la página, por lo que, si el usuario necesita consultar información de
varios registros a la vez, debería tener varias pestañas del navegador abiertas. Esto, desde
el punto de vista de atención al cliente, ralentizaría los tiempos y disminuiría la
satisfacción del cliente.
59
Figura 58: Pantalla de inicio en consola de Salesforce
La navegación por consola tiene una barra de navegación colapsada a través de la cual
puedes acceder a todos los objetos que tenga configurada la aplicación. Este tipo de
navegación, por el contrario de la estándar, permite tener varias pestañas abiertas dentro
de Salesforce, reduciendo tiempos para los usuarios que la utilizan. Es por ello, por lo que
en este TFG se configurará la navegación por consola.
Salesforce proporciona una aplicación estándar de consola orientada a la nube de

Servicios. Para configurar esta aplicación y personalizarla, desde la configuración de
aplicaciones (Configuración > Aplicaciones > Gestor de aplicación), editamos la
configuración de la aplicación llamada “Consola de Servicio”.
En la primera pantalla se establece el nombre de la aplicación, en el caso de la empresa

AGlexa, se denomina AGlexa Servicios, el logo y el color principal.
Figura 59: Configuración de aplicación de consola I
60
En la segunda pantalla, se establece las funciones que estarán disponibles en la barra de
pie de pantalla o footer. En el escenario de una consola utilizada para atención al cliente,
se configurarán las siguientes funcionalidades:
• Omni-channel: Es el enrutador de Casos a los diferentes agentes que estén
disponible y a través de cualquier canal de entrada (email, web…). Más adelante
en este TFG se explicará su configuración.
• Macros: Sirven para configurar de manera automáticas tareas repetitivas que
realizan los agentes como enviar un email, comunicarse con otro departamento o
crear una tarea.
• Histórico: Proporciona al usuario una lista de los últimos elementos a los que ha
accedido recientemente.
Figura 60: Configuración de aplicación de consola II
En la tercera pantalla se establecen los elementos de navegación u objetos que el usuario

tendrá disponibles en esta aplicación. Para nuestra aplicación, seleccionaremos la pantalla
de inicio, Casos, Cuentas, Pedidos, Productos, Catálogos, Informes y Paneles.
Figura 61: Configuración de aplicación de consola III
61
En la cuarta pantalla, se configuran las reglas de navegación. En estas reglas de
navegación se establece que registro es la pestaña principal y cuáles son las subpestañas.
Debido a que la consola está enfocada a la atención al cliente, configuraremos los
registros del objeto Caso como la pestaña principal y el resto derivarán de ellos.
Figura 62: Configuración de aplicación de consola IV
Finalmente, la consola quedará configurada visualizándose como se muestra a

continuación.
Figura 63: Vista de consola de servicio con registro abierto
Una vez configurada la consola, cada uno de los objetos del modelo de datos, tendrá una
configuración de su propia página con los componentes necesarios para que el gestor
tenga una vista 360º de los clientes, sus productos e incidencias.
4.1.3.2 Páginas de registro

Dentro de Salesforce existen dos personalizaciones en referencia a la interfaz de usuario:
los formatos de página y las páginas de registro. Los formatos de página definen que
información del propio registro se ve, se puede editar o incluso las secciones en las que
se divide esta información. Las páginas de registro definen los componentes que el
usuario visualizará en la pantalla, además del formato de página como, por ejemplo,
registros relacionados, funcionalidades como Chatter (herramienta de comunicación
dentro de Salesforce) …
Cada uno de los objetos tendrá una página de registro diferente y cuya configuración se
adecuará a la utilidad del objeto.
62
Cuentas personales
Para la configuración de la página de registro de cuentas se tendrá en cuenta que es el
registro donde se almacena toda la información de la persona. Es por ello que de un solo
vistazo, el usuario debe disponer de toda la información posible relacionada a dicha
persona.
La página quedará configurada de tal manera que la información se distribuya en tres
columnas:
• En la columna de la izquierda se visualizarán los Casos y Pedidos relacionados a
la cuenta.
• En la columna central se encontrará la información propia de la cuenta distribuida
acorde al formato de página configurado.
• En la columna de la derecha se podrán visualizar las actividades, así como
llamadas, envío de correo electrónicos, citas que se hayan realizado con esta
cuenta. Además, también quedará disponible en esta columna Chatter. Chatter es
la herramienta de comunicación interna de Salesforce. Permite mencionar
usuarios, poner hashtags10 o realizar publicaciones relacionadas a cualquier objeto
que lo tenga disponible.
Figura 64: Página de registro de cuentas personales
Casos
En este TFG, este es el objeto sobre el que trabajarán los gestores de incidencias por lo
que, la distribución del formato de página de este objeto es uno de los puntos importantes
a tener en cuenta para facilitar el trabajo y obtener una mayor productividad de los
usuarios.
La página quedará configurada de tal manera que la información se distribuya en tres
columnas:
• En la columna de la izquierda se visualizará la información de la cuenta a la que
está relacionada el Caso.
• En la columna central se encontrará la información propia de la cuenta distribuida
acorde al formato de página configurado.
• En la columna de la derecha se podrán visualizar las actividades, así como
llamadas, envío de correo electrónicos, citas que se hayan realizado con esta
cuenta. Además, también quedará disponible en esta columna Chatter. Chatter es
10
Hashtags: Define una palabra que es clave y lo convierte en vínculo, permitiendo así exportar toda la
información referente a dicha palabra.
63
la herramienta de comunicación interna de Salesforce. Permite mencionar
usuarios, poner hashtags o realizar publicaciones relacionadas a cualquier objeto
que lo tenga disponible.
4.1.4 Configuración de Omnichannel

Omnichannel es la herramienta que, dentro de Salesforce, realiza la repartición equitativa
del trabajo entre los agentes disponibles.
En el escenario de la empresa AGlexa, requiere que los gestores que se encargan de

resolver las incidencias, consultas o sugerencias de los clientes, trabajen de manera
equitativa en base a los canales de entrada de Casos al sistema. En el siguiente apartado,
se detallará la configuración de los canales que se han implantado en este TFG: Email,
Web y Alexa. Para cada uno de ellos, se establece el campo Origen del Caso, de tal manera
que la distribución por agentes es posible realizarla por canales de entrada.
Para la configuración de Omnichannel, se van a definir las diferentes colas en la que los
agentes estarán trabajando. Una cola en Salesforce es un conjunto de agentes.
• Casos Email: Cola destinada a agentes que gestionen Casos con origen Email.
• Casos Web: Cola destinada a agentes que gestionen Casos con origen Web.
• Casos Alexa: Cola destinada a agentes que gestionen Casos con origen Alexa.
• Casos genéricos: Cola destinada a agentes que gestionen Casos que no sea con
ninguno de los orígenes anteriores.
La creación de las colas se realiza desde el apartado de configuración de Salesforce,

navegando a la sección Colas. Haciendo click en el botón Nuevo, se establecen los
siguientes parámetros para la definición de la cola:
• Etiqueta
• Nombre de la cola
• Objetos admitidos: En este TFG, el objeto admitido que se selecciona es Caso.
• Miembros de la cola: Se agregan todos los usuarios que pertenecerán a la cola.
Figura 65: Configuración de la colas del objeto Casos
Cuando se hayan configurado todas las colas, se procede a realizar la configuración de

Omnichannel donde se definirá la carga de trabajo de los gestores, cuál es la prioridad de
enrutamiento de Casos y los estados a través de los cuales los agentes se pondrán como
disponibles o ausentes.
A continuación, se definen las diferentes configuraciones que se han de realizar para

habilitar Omnichannel a los usuarios.
64
Canales de servicio
Para iniciar la configuración de Omnichannel, se ha de definir el canal de servicio. Un
canal de servicio es lo que proporciona que se enrute trabajo a los agentes en base a un
objeto de Salesforce; en nuestro escenario, los Casos. Por tanto, si se quisieran tener
varios objetos enrutados por Omnichannel, se deberían configurar varios canales de
servicio.
La configuración del canal de servicio parte por navegar desde la configuración de

Salesforce al apartado de Canales de Servicio. Una vez dentro, seleccionando el botón
Nuevo, se cumplimentan los siguientes datos:
• Nombre de canal de servicio
• Nombre del desarrollador: Se cumplimenta de manera automática cuando se
establece el nombre del canal. Si hubiera desarrollos en el sistema vinculados a
canales de servicio, en el desarrollo se utilizaría este valor en vez del nombre del
canal de servicio.
• Salesforce Object: Se selecciona el objeto a través del cual se van a enrutar los
trabajos al agente. En este TFG, el objeto seleccionado es el Caso.
Una vez guardado, ya se tendrá definido el canal de servicio a través del que se enrutarán
los Casos en el sistema desarrollado para la empresa AGlexa.
Figura 66: Pantalla de configuración de canales de servicio
Estados de presencia
Dentro de la configuración de Salesforce, navengado a la pestaña de Estados de presencia,
se definirán los estados a través de los cuales los agentes indican que están disponibles o
no para recibir carga de trabajo desde Omnichannel, es decir, el agente tiene la potestad
de decidir si está o no está en línea para gestionar los Casos que le entren desde
Omnichannel. Entre los estados de presencia, para este TFG se definirán dos:
• En línea: El agente está disponible para recibir Casos. Este estado se relaciona al
canal de servicio que se ha configurado antes de Casos para que sea el estado que,
cuando los agentes lo seleccionen, les enrute los diferentes Casos que se vayan
generando.
• Ocupado: El agente no está disponible para recibir Casos. Este estado se ha de
marcar como ocupado para que, cuando el agente lo seleccione, no reciba ningún
Caso. Este estado no se relaciona a ningún canal de servicio.
65
Figura 67: Configuración de estado de servicio En línea
Figura 68: Configuración de estado de presencia Ocupado
Configuración de presencia
En esta configuración se define la capacidad que tiene el agente en cuanto a la cantidad
de trabajos que realiza a la vez. En el escenario de AGlexa, los trabajos que entrarán por
Omnichannel únicamente serán Casos. Adicionalmente en esta configuración se definen
las acciones que pueden realizar los agentes en Omnichannel, como por ejemplo si pueden
o no rechazar trabajos entrantes.
Desde el apartado de configuración de Salesforce, navegando a la pestaña de

Configuración de presencia y haciendo click en el botón Nuevo, se establecen los
siguientes parámetros:
• Nombre de la configuración de presencia
establece el nombre de la configuración de presencia.
• Capacidad: Es la cantidad de trabajo que puede un agente ejecutar a la vez (Casos
cuya pestaña está abierta al mismo tiempo en la consola de servicio del agente).
Para AGlexa, se define una capacidad por agente de tres Casos.
• Usuarios asignados: Al ser la configuración estándar, si no hay otra configuración
disponible y activa en Salesforce, todos los usuarios del CRM quedan
automáticamente asignados a esta configuración. En caso de tener que configurar
66
los usuarios, se seleccionan cada uno de los usuarios que requieren tener acceso
al canal de servicio de Casos y a la configuración que se ha realizado para la
capacidad.
Figura 69: Pantalla de configuración de presencia
Configuraciones de enrutamiento
Esta configuración define las reglas a través de las cuales se enrutan los diferentes trabajos
a través de Omnichannel. Desde la empresa AGlexa, se detecta la necesidad de establecer
la siguiente prioridad de enrutamiento de Casos:
1. Casos registrados a través de email
2. Casos registrados a través de web
3. Casos registrados a través de Alexa
Para establecer esta configuración, desde el apartado de configuración de Saleforce,

navegando a la sección de configuraciones de enrutamiento y haciendo click en el botón
Nuevo, se establecen los siguientes valores:
• Nombre de configuración de enrutamiento: Casos
establece el nombre de la configuración de enrutamiento.
• Prioridad de la ruta: Se establece la prioridad que tiene esta ruta con respecto al
resto de rutas. Para los Casos registrados a través de email se establece la prioridad
uno, para web se establece la prioridad dos y para Alexa se establece la prioridad
tres.
• Modelo de la ruta: Se establece bajo que criterio se enrutan los Casos entre los
diferentes agentes que se encuentren activos en Omnichannel.
o Menos activo: Usuario con menos carga de trabajo
o Mayor disponibilidad: Es el método seleccionado para la empresa AGlexa.
El agente con mayor disponibilidad será al agente al que se le enruten los
casos de manera prioritaria.
67
• Tamaño de los trabajos: Se pueden establecer diferentes pesos para los diferentes
trabajos que se enruten a través de Omnichannel. Por ejemplo, los Casos de email
pueden tener un peso igual a tres, de tal manera que el agente solo pueda gestionar
un Caso de email a la vez ya que llenaría la capacidad definida en la configuración
de presencia. Para la empresa AGlexa, todos los Casos tendrá el tamaño uno
asignado.
Figura 70: Pantalla de configuración de enrutamiento
A continuación de crear cada una de las configuraciones, se relacionan cada una de las
colas creadas con anterioridad a la configuración de enrutamiento. Dentro de cada una de
las colas, se establece la configuración de enrutamiento correspondiente. Para ello,
navegando a la pestaña de Colas dentro de la configuración de Salesforce y accediendo a
la cola que corresponda, haciendo click en el botón Modificar, se especifica la
configuración de enrutamiento que aplique.
• Cola Email con Configuración de enrutamiento Casos email
• Cola Web con Configuración de enrutamiento Casos Web
• Cola Alexa con Configuración de enrutamiento Casos Alexa
Figura 71: Pantalla de configuración final de cola asociada a Omnichannel
68
De esta manera, la configuración para el enrutamiento entre cada uno de los canales que
se definen a continuación quedaría finalizada.
4.1.5 Configuración de asignación de Casos

Cuando los Casos se crean en Salesforce para que se enruten por Omnichannel, el
propietario del Caso ha de ser una de las colas que se han definido en el apartado anterior.
Para ello, Salesforce proporciona las reglas de asignación de Casos las cuales, en base a
los criterios que se establezcan, asignan los Casos de manera automática en la creación a
usuarios o colas.
Desde la configuración de Salesforce, navegando a la sección Reglas de asignación de

Casos, se podrán configuran estas reglas en base a los siguientes criterios:
• Caso con Origen Email -> Cola Casos Email
• Caso con Origen Web -> Cola Casos Web
• Caso con Origen Alexa -> Cola Casos Alexa
• Caso con origen diferente a Email, Web, Alexa o Manual -> Cola Casos genéricos
Los parámetros de asignación de los Casos a las colas que correspondan siempre se ha de
hacer en base a los campos del objeto Casos o de registros relacionados directamente al
mismo. Es decir, no se puede asignar en base a criterios de otros objetos que no estén
relacionados al Caso.
Figura 72: Configuración de reglas de asignación de Casos
A continuación, se configurarán los canales a través de los cuales entrarán Casos a

Salesforce.
4.1.6 Configuración canales

En esta sección se detallará la configuración de cada uno de los canales a través de los
cuales el cliente puede contactar con la empresa AGlexa para informar una incidencia.
69
4.1.6.1 Email-to-Case
En la configuración del canal de contacto por email, la empresa para la que se está
desarrollando este TFG, tendrá que disponer de un buzón específico para la entrada de
incidencias. En el caso de la empresa AGlexa, no dispone de ese buzón por lo que se ha
de crear dicho buzón.
Para crear la cuenta de correo electrónico, navegaremos a https://www.gmail.com y
haremos click en nueva cuenta y se introducen los datos.
Figura 73: Pantalla de creación de cuenta de google
Una vez introducidos los datos y aceptada la política de privacidad de Gmail, la cuenta
se habrá creado.
En la parte de configuración de Salesforce, se configurará la herramienta estándar email-

to-case. Email-to-Case permite de manera estándar que, al enviar un correo electrónico a
un buzón determinado, se genere un Caso en Salesforce de manera automática. La
configuración de email-to-case no solo se realiza desde Salesforce sino también desde el
buzón de correo electrónico destinado a la creación de Casos:
Configuración en Salesforce
Dentro del módulo de configuración de Salesforce, se accede a la ruta Servicio>Correo
electrónico para registro de Casos. La configuración de este canal tiene las siguientes
opciones que pueden ser marcadas:
• Activar el correo electrónico para el registro de Casos: Esta opción permite activar
la funcionalidad.
• Notificar a los propietarios del Caso sobre los nuevos correos electrónicos: Envía
una notificación por correo electrónico a la persona que ha sido asignada al Caso.
• Establecer origen de Casos como correo electrónico: El campo Origen del Caso
se cumplimentará con el valor correo electrónico si esta opción está marcada.
• Guardar archivos adjuntos del correo en Salesforce Files: En el escenario en que
un Caso tenga un archivo adjunto, éste quedaría relacionado al Caso en la sección
70
de archivos adjuntos. Para marcar esta opción es importante tener en cuenta que
el espacio de almacenamiento de archivos en Salesforce es limitado y por tanto,
se desaconseja marcarla.
En nuestro escenario, marcaremos todas las opciones exceptuando la de almacenar los
archivos adjuntos al Caso automáticamente. Si el usuario quisiera realizar esta tarea,
podrá hacerlo de manera manual.
Una vez se ha realizado la configuración básica, estableceremos la dirección de correo a

través de la cual llegarán los Casos a Salesforce. Para ello, en la misma pantalla de la
configuración, en la sección Direcciones de ruta, haremos click en el botón Nuevo y
cumplimentaremos los siguientes datos:
• Nombre de la ruta: Casos AGlexa Email
• Dirección de correo: atencionalclienteaglexa@gmail.com
• Propietario del Caso: Permite seleccionar dos tipos de propietario, usuario y cola.
Tal y como se indica en apartados anteriores, configuraremos la cola Email para
que los Casos queden asignados a la misma.
• Prioridad del Caso: Media
• Origen del Caso: Correo electrónico
Figura 74: Pantalla de configuración de email-to-case
Al hacer click en Guardar, Salesforce de manera automática envía un correo electrónico

a la dirección que se ha establecido para verificar la cuenta.
71
Figura 75: Correo de verificación de creación de email-to-case
Haciendo click en el link que aparece en el correo electrónico, la cuenta quedará

verificada y, automáticamente, Salesforce genera una URL de redirección que permitirá
que los correos electrónicos que se envíen a la dirección establecida generen Casos en
Salesforce.
Figura 76: Email-to-Case de Salesforce creado
Configuración en Gmail
Con el fin de que cada uno de los emails que se envíen al correo de
atencionalclienteaglexa@gmail.com generen la creación automática de Casos en
Salesforce, desde el propio Gmail, se ha de configurar la redirección de la URL que
Salesforce proporciona al configurar el Email-to-Case.
Para ello, dentro de la configuración de Gmail, en la sección “Reenvío y correo

POP/IMAP” añadimos la dirección que Salesforce nos ha proporcionado (URL larga).
Figura 77: Redirección desde el buzón de Gmail I
72
Una vez añadida esta URL como dirección de Gmail te solicita un código de verificación.
Este código es enviado automáticamente a través de la creación de un Caso en Salesforce,
que, en su descripción, contiene dicho código de verificación necesario para vincular
ambos sistemas.
Figura 78: Verificación de redirección de gmail en Salesforce
Una vez se ha generado el Caso en Salesforce, se introduce el código en Gmail y la

dirección de reenvío queda configurada. A continuación de esta configuración, se
establece la política de reenvío correspondiente en la sección de ajustes de Gmail de
“Filtros y direcciones bloqueadas”.
En esta sección se configura que, todo correo que llegue con el campo “Para:” igual a
atencionalclienteaglexa@gmail.com, se reenvíe a la dirección que se ha configurado
anteriormente. De esta manera, Gmail, automáticamente redirigirá el correo y
desencadenará la creación de un Caso en Salesforce.
Figura 79: Redirección desde buzón Gmail II
73
4.1.6.2 Web-to-Case
El objetivo de la configuración de este canal es que, en la página web de la compañía
AGlexa, se introduzca un formulario que permita a los usuarios de dicha página un Caso
en Salesforce. En este TFG no se realizará el desarrollo de la página web aunque si se
realizará la configuración del formulario web.
Para la configuración del formulario, desde la configuración de Salesforce, se accede a la

sección Servicio > Web-to-Case para poder activar el canal de web. En esta sección, se
habilita el canal además de configurar los siguientes puntos:
• Requerir un reCAPTCHA: Al activar esta opción, dentro del código del
formulario se podrá añadir el desarrollo de la verificación de autenticidad del
reCAPTCHA. Añadir una autenticación de este estilo al formulario evita la
generación de Casos por contactos no deseados, por ejemplo. Para el formulario
desarrollado para AGlexa, no utilizaremos un reCAPTCHA como método de
autenticación.
• Origen predeterminado del Caso: Siempre que se genera un Caso de formulario,
el campo origen se completará con el valor que se introduzca en esta
configuración. En nuestro caso, el origen seleccionado será Web.
• Plantilla de respuesta predeterminada: Siempre que se genere un Caso en
Salesforce, se enviará un email con la plantilla de correo electrónico que se
establezca en esta configuración. Para la empresa AGlexa, desarrollamos una
plantilla personalizada que se explicará a continuación.
La plantilla que se utilizará para la comunicación de la apertura de un Caso a través del

canal web se configura en Salesforce accediendo a la sección Correo electrónico >
Plantillas de correo electrónico.
Se pueden configurar cuatro tipos de plantillas diferentes:
• Texto: Plantilla de texto estándar que no permite la personalización con HTML.
• HTML: Plantilla personalizada que permite incluir estilo con HTML y cabecera.
• Personalizado: Plantilla personalizada que permite incluir estilo con HTML pero
no permite modificar la cabecera del correo electrónico.
• Visualforce: Plantilla hecha a través de código y totalmente personalizable.
Para la empresa AGlexa, la plantilla a utilizar será una plantilla de texto plano. Para ello,
dentro de la sección Plantillas de correo electrónico, al hacer click en Nuevo, se
selecciona la opción Texto.
Figura 80: Pantalla de configuración de tipo de plantilla
A continuación, se abre el creador de plantillas de Salesforce en el que se tiene acceso a

los nombres API de los campos para que puedan ir dentro de la plantilla. Estos valores,
cuando se visualice el correo electrónico, vendrán cumplimentados con la información
del cliente o del Caso (o de cualquier otro objeto si fuera necesario).
El correo electrónico configurado contendrá la siguiente información:
• Nombre de la plantilla: Creación de Casos Web
74
• Asunto: Su Caso {!Case.CaseNumber} se ha generado con éxito
• Cuerpo del mensaje:
Estimado cliente,
Hemos recibido su petición que responde al número {!Case.CaseNumber} con los

siguientes datos aportados:
- Asunto: {!Case.Subject}
- Descripción: {!Case.Description}
- Email de contacto: {!Account.PersonEmail}
- Tipo: {!Case.Type}
Nos pondremos en contacto con usted a la mayor brevedad.

Saludos cordiales
Figura 81: Configuración de plantilla de correo electrónico
Una vez configurada la plantilla, dentro de la configuración de web-to-case, establecemos

que se envíe por defecto cuando se genere un Caso a través del formulario de tal manera
que la configuración del web-to-case quedará como se muestra en la siguiente imagen.
75
Figura 82: Configuración de casos web con plantilla de correo electrónico
El siguiente paso de realizar la configuración general, es el desarrollo del formulario.

Salesforce proporciona un generador de HTML estándar que permite establecer los
campos que serán visibles en el formulario. Para ello, dentro del menú se accede a la
sección Servicio > Generador HTML del Caso.
Dentro de la herramienta de generación del formulario, seleccionamos los campos que se

visualizarán, además de establecer la URL de retorno. La URL de retorno es la URL
donde navegará el usuario que utilice el formulario cuando haga click en el botón Enviar.
Los campos que se mostrarán en el formulario serán los siguientes:
• Nombre del contacto
• Correo electrónico
• Asunto
• Descripción
• Tipo
• Motivo del Caso
Figura 83: Pantalla de configuración de Web-to-Case
Al hacer click en el botón generar, automáticamente se generará el código en HTML del

formulario web. En el escenario en el que la empresa tenga su página web, el código
76
generado se copiaría y pegaría dentro del código de la página web para que apareciese.
Para la empresa AGlexa, copiaremos este formulario y lo almacenaremos en un fichero
HTML para poder utilizarlo en la generación de Casos de tipo web.
Figura 84: Formulario Web-to-Case
El campo Origen del Caso, se establecerá a través del código del formulario sin que el
cliente lo visualice cuando introduzca los datos. De esta manera, se podrá detectar desde
donde se produce la creación del Caso.
4.2 Desarrollo de skill de Alexa

El objetivo de la conexión de Salesforce con Alexa es proporcionar un canal adicional,
fuera de los canales estándar, que aporte al usuario otro método innovador de contacto
con la empresa. Para ello, se propuso a la empresa desarrollar los siguientes casos de uso
para que Alexa en esta primera fase del proyecto:
• Crear una nueva incidencia
o En este caso de uso, Alexa responderá a frases o preguntas como “Alexa,
quiero abrir una nueva incidencia” o “Alexa, tengo un problema, ponme
en contacto con soporte”
En la integración de Salesforce con Alexa, intervienen varios sistemas/capas que permiten

lo que recoge el dispositivo a través de la voz del cliente, se traslade a Salesforce en forma
de registro.
Figura 85: Flujo de sistemas de integración
Alexa Skill Kit (ASK) es una colección de APIs11 y herramientas que permiten crear y
diseñar nuevas capacidades para el dispositivo de Alexa.
Cada usuario que tenga un dispositivo Echo, en el caso de este TFG será el Echo Dot,
puede acceder a cualquier skill de Alexa invocándola con un comando de voz específico
como por ejemplo “Alexa, dime qué tiempo hace hoy”. El modelo de reconocimiento de
voz y de los comandos que el usuario le traslada a Alexa es el siguiente:
11
API: Es la interfaz de programación de aplicaciones que se usa para integrar softwares de diferentes
aplicaciones.
77
Figura 86: Modelo de reconocimiento de voz de Alexa
Alexa tiene una serie de desarrollos que le permite obtener una traducción de la frase que
transmite el usuario a realizar una acción. Dentro de este TFG, se tratará de realizar el
desarrollo tanto la lógica de la skill como la API para que Alexa pueda reconocer el
comando y ejecutar la acción de creación de un registro en Salesforce.
La traducción del lenguaje de la skill que se desarrollará en este TFG para que Alexa
entienda cual es la acción que realizar, se desarrollará utilizando Alexa Skill Kit. En
cambio, la lógica de la skill será desarrollada con AWS Lambda.
Lambda es un servicio que permite ejecutar código sin la necesidad de tener ningún
servidor específico en el que hacerlo. El motivo por el cuál se decide utilizar AWS Lambda
es porque cuando se ejecuta la skill no hay que revisar asignación de recursos de CPU ni
comprobar conectividad, sino que este servicio te lo proporciona directamente.
Para poder realizar el desarrollo de la skill, hay que darse de alta en la página de
desarrolladores de Amazon. Navegando a la página https://developer.amazon.com/login
y haciendo click en el botón “Crea tu cuenta de”, se establecen los datos para poder
generar la cuenta. Este registro es completamente gratuito, al igual que toda la
funcionalidad de Alexa que se va a utilizar en este TFG.
Figura 87: Pantalla de creación de cuenta de developer de Alexa
78
Una vez dentro, Alexa Skill Kit proporciona una consola para desarrolladores a través de
la cual pueden manejar las diferentes skills que tengan hechas, probarlas o modificarlas
en caso de que sea necesario.
Figura 88: Pantalla de consola de desarrollo de skills de Alexa
4.2.1 Configuración de la skill

Para la creación de la skill, se hace click en el botón Crear Skill y se selecciona la plantilla
de skill disponible como “Hello world”. Esta plantilla proporciona una construcción
básica de una skill que, cuando la ejecutas, Alexa contesta “Hello World”.
Para comenzar la configuración de la skill se seguirán los pasos siguiendo el menú que
aparece a la derecha de la pantalla en la siguiente imagen:
Figura 89: Pantalla principal de configuración de skill
En primer lugar, se configurará el Invocation name. Este parámetro es el desencadenante

a través del cuál Alexa reconoce que skill tiene que ejecutar, en el caso de este TFG, el
Invocation name será “soporte aglexa” ya que el nombre de la skill por obligatoriedad
debe de tener al menos dos palabras.
79
Para cada uno de los cambios que se realizarán a continuación, antes de continuar, se ha
de hacer click en el botón Save model ya que sino se perderán los cambios realizados.
En segundo lugar, se realizará la configuración de los Intents y Slots. Un intent para Alexa
será el equivalente a la acción que el usuario quiera realizar. Por ejemplo, si quisiéramos
pedir ayuda a Alexa, diciendo la frase “Alexa, necesito tu ayuda”, ésta ejecutaría el intent
help que viene configurado por defecto.
De entre los intents que Alexa proporciona por defecto, se encuentran los siguientes como
los más utilizados por los usuarios que desarrollan skills de Alexa:
• Cancel Intent: Es el intent que permite parar la ejecución de la skill. Además,
también permite parar la ejecución de alguna de las interacciones que están en
curso.
• Help Intent: Es el intent a través del cuál se le puede pedir ayuda a Alexa con
respecto a la skill que está ejecutando.
• Stop Intent: Es el intent que, aunque Alexa esté hablando, te permite parar la
ejecución completa de la skill.
Los tres intents descritos anteriormente, son de uso obligatorio en todas las skills, aunque
a la hora de desarrollar una skill personalizada, como es el caso de AGlexa, no sería
necesario implementarlos.
Los intents como se puede deducir, se ejecutan una vez se le envía un comando de voz
concreto a Alexa. Estos comandos de voz que hacen que los intents se ejecuten se
denominan Utterances. Los utterances son las frases que el usuario puede decir a la hora
de solicitar a Alexa que realice alguna acción. Siguiendo con el ejemplo anterior de
solicitar ayuda a Alexa, el intent sería el HelpIntent y algunos de los utterance podrían
ser: “necesito ayuda”, “ayúdame”, “por favor, sácame del apuro” …
Adicionalmente, dentro de algunas de estas frases (utterance) que sean más concretas
como por ejemplo “ayúdame con la comida”, podemos decirle a Alexa algunos
parámetros a través de los cuales ella pueda realizar alguna búsqueda. A la hora de definir
este tipo de frases, se ha de pensar como un usuario puede realizar cierto tipo de peticiones
y, cuantas más maneras se tengan de realizar la petición, más exacto será que se ejecute
el intent correcto.
En el ejemplo anterior de solicitar ayuda con la comida, Alexa detectará que estamos
solicitándole información sobre comida y a eso es lo que se define como slot. El slot es
una variable que proporciona el usuario a Alexa, de tal manera que pueda realizar alguna
acción sobre ese slot en concreto.
Haciendo una síntesis de los párrafos anteriores, podemos definir los siguientes términos
con los cuales trabajaremos a lo largo de este TFG:
• Intent: Es una petición de un usuario a Alexa.
• Utterance: Conjunto de frases que puede decir un usuario a Alexa y relacionadas
a los intents.
• Slots: Argumentos que los usuarios utilizan en frases y que proporciona
información a Alexa para ejecutar los Intents. Los slots están contenidos en los
utterance.
80
Para crear el intent dentro del apartado del menú “Intents, Samples y Slots”, se hace click
y se navega a la siguiente pantalla.
Haciendo click en el botón Add intent, se genera el nuevo intent con nombre NewCase.
Una vez generado el intent se procederá a definir tanto los slots como los dialogs que el
usuario podrá mantener con Alexa para la generación del Caso.
Figura 90: Pantalla de resumen de Intents de la skill
Dentro de la pantalla del intent se definirán las frases que el usuario le dirá a Alexa para
que comience la conversación de creación de Caso. Estas frases deben escribirse en un
uso coloquial del mensaje ya que, será la frase que desencadene la recogida de datos de
la skill. Estas frases se denominan Utterance y se han definido las siguientes para
desencadenar la conversación:
• “Tengo una incidencia”
• “Tengo una consulta”
• “Tengo un problema”
• “Quiero contactar con la empresa”
Figura 91: Pantalla de configuración de intent de la skill
A continuación, se realizará la definición de los slots o variables que donde queremos

almacenar la información con los datos necesarios para la creación del Caso. Alexa
proporciona diferentes tipologías de datos a través de la cual puedes almacenar valores.
En el caso de este TFG, se ha creado un tipo de slot nuevo para almacenar el tipo de Caso
81
que el cliente quiere crear. Navegando a través del menú lateral a la sección Slot Types y
haciendo click en el botón Add Slot Type, se establece el nombre “Text” para denominar
a la nueva tipología de slots y, haciendo click en Siguiente, se establecen los valores que
tendrá está tipología de slot. Para este TFG, se definieron los valores: “Incidencia”,
“Consulta”, “Sugerencia” y “Otros”.
Figura 92: Pantalla de configuración de tipo de slot
Una vez definido la nueva tipología de slot, se procede a crear los slots. Los slots
definidos serán:
Nombre del slot Descripción Tipo de dato

DNI Se almacenará el valor AMAZON.FOUR_DIGIT_NUMBER:
numérico del DNI del Tipo de dato que reconoce los números
cliente que quiera a través de la oz y lo traduce en valor
registrar un Caso. numérico.
Type Se almacenará el tipo Text
de Casos que se
almacenarán. Entre los
valores disponibles se
definen:
• Incidencia
• Consulta
• Sugerencia
• Otros
Subject Se almacenará el AMAZON.SearchQuery: es una

asunto por el cual el tipología de dato que permite
cliente contacta con la almacenar textos
empresa.
Tabla 13: Definición de slots utilizados en la skill
82
Figura 93: Pantalla de resumen de slots asociados al intent
Para cumplimentar el diálogo que Alexa mantendrá con el usuario durante la ejecución
de la skill, se estable por cada uno de los slots que se han definido, el diálogo que Alexa
y el usuario mantendrán para poder abrir el Caso en Salesforce.
En primer lugar, para el slot de DNI, el diálogo que se ha definido para la interacción
entre Alexa y el usuario es el siguiente:
- Alexa: “Por favor, dime tu DNI”

- Usuario: “Mi DNI es {DNI}” o “{DNI}”
En el diálogo del usuario, se puede ver como se utiliza el slot definido como DNI para
que Alexa identifique que las palabras que el usuario diga se corresponden con el slot
DNI. De esa manera, Alexa, almacena el valor para luego utilizarlo en la creación del
Caso.
Figura 94: Configuración del dialogo para obtener el DNI
83
En segundo lugar, para el slot de Type, el diálogo que se ha definido para la interacción
entre Alexa y el usuario es el siguiente:
- Alexa: “Que tipo de Caso quieres abrir a AGlexa, Incidencia,

Consulta, Sugerencia u Otros?”
- Usuario: “Mi Caso es una {Type}” o “{Type}”
En el diálogo del usuario, se puede ver como se utiliza el slot definido como Type para
Type. De esa manera, Alexa, almacena el valor para luego utilizarlo en la creación del
Caso.
Figura 95: Configuración del diálogo para obtener el Type
Por último, para el slot de Subject, el diálogo que se ha definido para la interacción entre
Alexa y el usuario es el siguiente:
- Alexa: “Dime el motivo de tu {Type}”

- Usuario: “{Subject}”
En el diálogo del usuario, se puede ver como se utiliza el slot definido como Subject para
Subject. De esa manera, Alexa, almacena el valor para luego utilizarlo en la creación del
Caso.
84
Figura 96: Configuración del diálogo para obtener el Subject
Una vez se ha configurado la skill, se comienza con la realización del código para
conectarlo con el servidor de AWS Lambda y así poder conectar con Salesforce.
Para la realización del código, se ha de crear una cuenta de AWS a través de la página
https://signin.aws.amazon.com/ y haciendo click en el botón Crear una cuenta de AWS.
A continuación, se establecerá el email y el nombre de la cuenta y llegará un código de
verificación para que, una vez que se haya verificado la identidad, se establezca la
contraseña. Al establecer la contraseña, directamente se navegará a la pantalla principal
de la consola de AWS.
Figura 97: Pantalla de inicio de AWS
Dentro de la consola, se ha de navegar a la opción de Lambda para desarrollar el código

que proporcione un servicio web para los métodos de la skill y cree el Caso en Salesforce.
Para ello se puede acceder desde la pantalla principal, buscando en el buscador o a través
de la opción de Services eligiendo Lambda.
85
Dentro de la consola de Lambda, se puede visualizar el menú lateral izquierdo donde se
encuentra la sección de Functions. En esa sección será donde se desarrolle el código
correspondiente a la ejecución de la skill. Para ello, se encuentra una vía rápida de crear
una función y es, desde la pantalla de la consola de AWS Lambda, haciendo click en el
botón Create function.
En la pantalla de la creación de la función, aparecen diferentes métodos a través de los

cuales de puede comenzar a construir la función Lambda de la skill:
• Author from scratch: Se comienza con una skill simple de ejemplo
• Use a blueprint: Construir una aplicación de lambda a través de ua configuración
con unos casos de uso comunes.
• Container Image: A través de una imagen se sube la función a AWS Lambda.
• Browse servlerless app repository: Se realiza la creación de la función a través de
una aplicación estándar de Lambda desde un AWS Servlerless Application
Repository.
Para este TFG, se seleccionará la creación a través de Author from scratch y se establecen
los siguientes valores para la generación de la función.
• Nombre de la función: “AlexaSkill”
• Runtime: Es el lenguaje con el cual se va a escribir el código de la función. Para
este TFG se utilizará “Node.js 16.x”
• Se creará automática un rol de ejecución con los permisos básicos de ejecución de
lambda.
Cumplimentados estos datos, se hace click en Create function y se generará la función.
Figura 98: Pantalla de creación de la función lambda
Para comenzar con la implementación, se ha de realizar la descarga de las diferentes

librerías externas que se van a utilizar en el código. En este caso serán las librerías de
nforce y aws-sdk que proporcionarán las APIs necesarias para la realización de la
integración.
• La librería de nforce proporciona una API codificada en Node.js que permite
realizar la conexión con Salesforce. Para importar esta librería, navegaremos a la
página de https://www.npmjs.com/package/nforce y existen dos opciones de
instalación:
86
o A través del comando de la consola “npm install nforce”
o A través del GitHub donde se encuentra el repositorio de la librería
completa. En este TFG se ha realizado la descarga a través de este método
ya que se descarga directamente el fichero comprimido. Navegando a la
página https://github.com/kevinohara80/nforce dentro del botón Code se
selecciona la acción Download ZIP y con ello se descarga el fichero.
• La librería de aws-sdk proporciona la API para los servicios de AWS de tal manera
que permite conectar la skill y ejecutarla utilizando métodos en la función de
lambda. Para descargar esta librería, navegando a la página
https://github.com/awsdocs/aws-javascript-developer-guide-v2 y haciendo click
en el botón Code se selecciona la acción Download ZIP y con ello se descarga el
fichero.
Una vez se tienen ambas librerías descargadas como fichero comprimido, se añadirán
como layers dentro de la consola de lambda. Un layer te permite añadir parte del código
de tal manera que no se tenga una sobrecarga de archivos en la ruta de la función lambda
que se crea dentro de la consola de desarrollo.
Para ello crear las layers, en el menú de navegación de la consola de lambda aparece la
opción Layers y, navegando a esa opción y haciendo click en Create layer se establecerán
los siguientes valores:
• Librería de aws-sdk
o Name: AWSSDK
o Description: Librería de aws-sdk
o Upload a .zip file: Se selecciona el fichero comprimido de la librería de
aws-sdk.
o Compatible runtimes: Se seleccionan los valores de lenguajes utilizados
en la función lambda con los que la librería ha de ser compatible. En este
caso, se selecciona el valor Node.js 16.x indicando la versión del código
con la que se desarrollarán los ficheros de la skill.
• Librería de nforce
o Name: nforce
o Description: Librería de nforce
o Upload a .zip file: Se selecciona el fichero comprimido de la librería de
nforce.
o Compatible runtimes: Se seleccionan los valores de lenguajes utilizados
en la función lambda con los que la librería ha de ser compatible. En este
caso, se selecciona el valor Node.js 16.x indicando la versión del código
con la que se desarrollarán los ficheros de la skill.
87
Figura 99: Configuración de layer
Cuando ya se han generado las capas, se procede a añadirlas a la función de lambda que
vamos a desarrollar. Para ello, se navega de nuevo a la consola de desarrollo de lambda
navegando a la sección de layers, haciendo click en el botón Add a layer se selecciona la
layer a añadir. Este paso se repetirá hasta que ambas layers estén añadidas en la función.
Figura 100: Pantalla de resumen de las layers
Previo a desarrollar el código que sustenta la conexión de la skill con el servicio de

lambda, se deberá añadir el desencadenador de la función lambda. En este caso, dentro
del diagrama de la función, al hacer click en el botón Add trigger se podrá establecer
como desencadenante la skill que se ha configurado en la consola de desarrollo de Alexa.
Para ello, cada skill tiene un identificador único y a través de él, se establecerá la skill
correspondiente como desencadenante. Este identificador se obtiene desde la consola de
desarrollo de skills de Alexa en la sección de Endpoints.
88
Figura 101: Configuración de endpoint
Figura 102: Pantalla de configuración de desencadenador de función lambda
Al hacer click en el botón Add quedará establecido que el desencadenante de la función

que se ha desarrollado será la ejecución de la skill de Alexa que se ha configurado.
Por último, para apuntar la skill al servidor de lambda es necesario modificar, en el

apartado de Endpoints de la consola de Alexa, estableciendo como endpoint la función
lambda. Para ello, la función tiene un identificador único a través del cuál se puede
apuntar la skill a dicha función. En el momento que se realiza esta acción, la skill
comienza a ser ejecutada desde el código que se ha desarrollado en vez de a través del
servidor por defecto que proporciona Alexa.
Dentro del campo de Default region es donde se establece este código único de la función
lambda.
89
Figura 103: Configuración de endpoint
Al modificarlo, se deberá guardar la skill y ya estará preparada para ejecutarse a través de

la función lambda.
4.2.2 Configuración de Salesforce

De cara a permitir que se generen registros a través de un servicio externo, se configurará
una Connected App. Las connected apps en Salesforce permiten que una aplicación
externa se conecte con Salesforce utilizando las APIs proporcionadas por la herramienta.
La connected app proporcionará las variables a través de las cuales se podrá establecer la
conexión desde la función lambda. Estas variables son:
• Client Id: Es el identificador único de la connected app.
• Client Secret Key: Es la clave de autenticación que se utilizará entre el servidor y
Salesforce.
Para configurar esta connectep app, dentro de Salesforce siguiendo la ruta Configuración
> Apps > App Manager, haciendo click en el botón New connected app, se establecerán
los siguientes datos para crear la aplicación:
• Connected App Name: AGlexa
• Api Name: AGlexa
• Contact email: alba.ggines@gmail.com
• Enable Oauth Settings: Habilitado para permitir la autenticación con las claves
que proporcione la aplicación.
90
Figura 104: Pantalla de configuración de connected app de Salesforce
Cuando ya se han establecido los parámetros, al hacer click en el botón guardar,

automáticamente Salesforce genera las dos variables mencionadas anteriormente.
4.2.3 Función lambda

En este apartado se expondrán algunas de las funciones principales del código
desarrollado para la función lambda.
En primer lugar, se definen cada una de las variables que se utilizarán en el código:
• CLIENT_ID: Variable que almacena el identificador único de la connected app
creada en Salesforce
• CLIENT_SECRET: Variable que almacena el número secreto único de la
connected app creada en Salesforce.
• USR: Usuario de Salesforce con el que se realizará la integración.
• PASS: Contraseña del usuario de Salesforce con el que se realizará la integración.
• APP: Identificador único de la skill de Alexa. Este identificador único es el que se
encuentra en la consola de desarrollo de skills de Alexa.
A continuación, se deberán referir las librerías de tal manera que, dentro de las funciones
desarrolladas, permita la utilización de los métodos y funciones que contengan. Esto se
realizará a través de la función require.
Una vez añadidas las librerías al código, se definirá el objeto de conexión con Salesforce
a través de uno de los métodos proporcionados por nforce.
Figura 105: Creación del objeto de conexión
91
La función createConnection de nforce se utiliza para poder crear el objeto con los
parámetros necesarios para poder realizar la conexión con el servicio que proporciona
Salesforce a través de la connected app que se creó en el apartado anterior. Esta conexión
se realizará en la función del intent de NewCase que se explicará más adelante en este
apartado.
Cuando desde Alexa el usuario ejecute la skill automáticamente se ejecuta el método

LaunchRequestHandler. Este método es el método estándar que lanza el mensaje de
bienvenida siempre y cuando en el inicio del diálogo que el usuario tiene con Alexa,
contenga el invocation name “mi app de aglexa” que se ha establecido para la ejecución
de la skill.
Figura 106: Método Launch Request de la función lambda
Dentro de la función se comprueba que la frase que el usuario ha pronunciado se

corresponde con el invocation name. En caso de que sea afirmativo, se lanza el mensaje
de bienvenida a la skill.
La función NewCaseIntentHandler será la función que realice la recogida de los

parámetros a través de la ejecución del intent desde la skill de Alexa. Además, se realiza
la autenticación a través del objeto createConnection para poder crear el objeto dentro de
Salesforce y, como último paso, se realiza la creación del objeto en Salesforce.
Figura 107: Función del intent New Case
92
El método de la librería de nforce createSObject permite definir los valores de los
diferentes campos del registro que se creará en Salesforce. Una vez definido, el método
authenticate autentica al usuario en base a los parámetros que se establecen y retorna la
creación del registro en Salesforce a través del método insert.
El resto de los métodos utilizados como intents se han configurado como los que Alexa
proporciona por defecto en cualquier skill, modificando las frases a través de las cuales
Alexa contestará a cada uno de ellos. Por ejemplo: En el método de ayuda, Alexa
interpreta este método cuando le dices “Alexa necesito ayuda”. Cuando el usuario diga
esa frase o similar, Alexa contestará “Para utilizar la skill por favor di la frase: Alexa,
tengo un problema”.
Por último, el método exports.handler es el controlador que hace que se ejecute alguno
de los intents desarrollados por código cuando desde Alexa se invoca la función lambda.
que el realiza la función de constructor de la skill ya que es donde se indican los handlers
que se han desarrollado y exporta la función.
Figura 108: Exports handler de lambda
En la función exports.hadler el método SkillBuilders.custom() es el que permite la

creación completa del objeto o instancia de la skill. Es por ello por lo que, a continuación,
se añaden a partir de la función addRequestHandlers los métodos de los intents que la
skill contiene.
Una vez se ha desarrollado la skill de Alexa y la función lambda, se procede a realizar la

publicación de manera que se pueda instalar en el dispositivo. Para ello, dentro de la
consola de desarrollador de la skill de Alexa, dentro de la skill en la barra de navegación,
navegando a la pantalla de Distribution se pueden establecer los datos para
posteriormente, en el apartado Certificación validar la skill y hacer que sea accesible. En
la sección de Distribution se establecerán los siguientes datos:
• Public Name: “AGlexa Skill Salesforce”
• One Sentence Description: “AGlexa Skill Salesforce for TFG”
• Detailed Description: “AGlexa Skill Salesforce es una skill desarrollada para un
TFG.”
• Example Phrases: Son las frases que se utilizarán para llamar a la skill. En el caso
de este TFG, al ser una skill con varias interacciones entre el usuario y Alexa, la
frase ha de contener el invocation name. Por tanto, el valor que se introdujo en
este campo fue: “Alexa, abre mi cuenta de aglexa”
• Small Skill Icon y Large Skill Icon: Es el icono que aparece cuando desde la app
de Amazon Alexa, visualizas la skill.
• Category: Categoría en la que se encontrará la skill dentro del catálogo de skills
de Alexa. En nuestro caso, “Utilidades – Device Tracking”
93
• Privacy policy: Dado que la skill de Alexa desarrollada recoge datos personales
del usuario que la utiliza, se ha de establecer la URL a través de la cuál los usuarios
pueden acceder a las políticas de privacidad establecidas en España. Para ello, se
establece la página web de https://www.aepd.es/es/politica-de-privacidad-y-
aviso-legal. Esta página web es página de la agencia española de protección de
datos.
Figura 109: Pantalla de Disposición de la consola de desarrolladores de Alexa
A continuación, se realiza un cuestionario sobre la privacidad de la skill. Se realizan

preguntas como si se recogen datos personales o si la skill va enfocada a personas menores
de 13 años. Una vez rellena ese formulario, se procede a establecer la disponibilidad de
la skill para el resto de los consumidores de skills de Alexa. En el caso de este TFG, la
skill está pensada para que las personas que sean clientes de la empresa AGlexa, puedan
utilizar la skill por lo que, se establece como pública.
Figura 110: Pantalla de Disposición de la consola de desarrolladores de Alexa II
94
Al hacer click en Save and continue, se navega automáticamente a la sección de
Certification. En esta sección se valida la skill previo de publicarla y, una vez validada,
se certifica y se publica. La certificación de la skill es una revisión que se hace desde el
departamento de desarrolladores de skills de Alexa y certifican si la skill puede ser
distribuida o no. La revisión de la skill puede tardar unos minutos y una vez está validada,
se publica automáticamente.
Figura 111: Pantalla de publicación de la skill
Para finalizar, cuando la skill esté publicada, se comenzarán las pruebas con usuarios y
se detallará la instalación de la skill.
95
V. EVALUACIÓN
Una vez se ha realizado el desarrollo del CRM, se comienza la fase de carga de datos en
la nueva organización. El cliente AGlexa proporciona los datos necesarios para la
realización de la carga y, desde la parte de desarrollo de este TFG, se realiza la carga
masiva a través de la herramienta de importación de datos de Salesforce. Se adjuntará
como anexo de este TFG la plantilla de carga de datos con la que se realiza la carga.
A continuación de cargar los datos correspondientes, comienza la fase de pruebas

unitarias de la herramienta. En esta fase de pruebas, se testearán todos los desarrollos que
se han realizado en Alexa por parte de algunos de los agentes que utilizarán la herramienta
(personas externas al desarrollo de este trabajo de final de grado). Para ello, se les
facilitará la siguiente platilla de pruebas para que puedan ir cumplimentándola.
Módulo Perfil Entrada Acción Salida

Casos Agente El agente ha Navega a la pestaña Tiene acceso a
Email iniciado sesión en de Casos en la visualizar los
Salesforce Consola de AGlexa Casos
Agente Desde la pestaña de Selecciona la vista de Visualiza los
Casos Casos Email Casos con
entrada Email
Agente El cliente envía un Se pone como Salta la alerta en
email disponible en Omnichannel
Omnichannel del Caso que ha
abierto el cliente
Agente Salta la alerta en Acepta el Caso de El Caso queda
Omnichannel de un Omnichannel asignado al
nuevo Caso agente
Agente Tiene un Caso Gestiona el Caso Se cierra el
asignado cambiando el estado Caso.
hasta su cierre
Web iniciado sesión en de Casos en la visualizar los
Casos Casos Web Casos con
entrada Web
Agente El cliente rellena el Se pone como Salta la alerta en
formulario creando disponible en Omnichannel
un Caso Omnichannel del Caso que ha
abierto el cliente
nuevo Caso agente
hasta su cierre
Alexa iniciado sesión en de Casos en la visualizar los
96
Casos Casos Alexa Casos con
entrada Alexa
Agente El cliente registra Se pone como Salta la alerta en
un Caso a través de disponible en Omnichannel
Alexa Omnichannel del Caso que ha
abierto el cliente
nuevo Caso agente
hasta su cierre
manuales iniciado sesión en de Casos en la visualizar los
Agente Desde la pestaña de Selecciona la vista de Visualiza todos
Casos Todos los Casos los Casos
abiertos creados
Agente Se ha recibido un Hace click en el botón Se crea un Caso
Caso a través de nuevo y cumplimenta asignado al
otro canal los campos agente
Tabla 14: Casos de uso de usuarios finales
Para la realización de las pruebas de la herramienta, se ha proporcionado un usuario del

sistema a uno de los gestores con el fin de que pueda realizar las pruebas y dar su opinión
sobre la herramienta. En esta evaluación de la herramienta, se le solicitó que comentara
puntos fuertes, puntos débiles y que comentara que le aportará la herramienta cuando se
comience a utilizar en su día a día.
A continuación, se muestran algunas de las capturas de pantalla de las diferentes pruebas,

que ha realizado el usuario, asociadas a los Casos de uso propuestos anteriormente.
• Caso de uso: creación de casos a través de email. Se adjunta la captura de pantalla

de como el usuario está disponible en Omnichannel y aparece el Caso con la
opción de aceptar.
97
Figura 112: Envío de correo electrónico al buzón de email-to-case
Figura 113: Pantalla de entrada de Caso email por Omnichannel
• Caso de uso: Creación de casos a través de web. Se adjunta la captura de pantalla

de como el usuario está disponible en Omnichannel y aparece el Caso con la
opción de aceptar.
98
Figura 114: Formulario web cumplimentado por el usuario de pruebas
Figura 115: Pantalla de entrada de Caso web entrando por Omnichannel
• Caso de uso: Creación de casos a través de Alexa. Se adjunta la captura de

pantalla de como el usuario está disponible en Omnichannel y no aparece el Caso
con la opción de aceptar. Esto es así debido a que finalmente por las versiones de
las herramientas y librerías utilizadas, no se ha podido realizar la integración
completa con Alexa.
99
Figura 116: Pantalla de simulación de conversación con Alexa
• Caso de uso: El usuario también realiza la prueba de establecer su estado de

Omnichannel como Ocupado para que no le entre Casos.
Figura 117: Pantalla de caso de uso de usuario ocupado en Omnichannel
100
• Caso de uso: El usuario realiza la prueba de que su capacidad de trabajo sea tres
Casos atendiéndose o en la cola para atenderse a la vez. Para ello, los clientes
abren Casos y el agente visualiza en pantalla a la vez únicamente tres Casos entre
los Casos de Omnichannel y en los que actualmente esté trabajando.
Figura 118: Pantalla de caso de uso de capacidad del agente
Finalmente, la mayoría de las pruebas que han realizado los usuarios han sido exitosas,
exceptuando las pruebas de la integración con Alexa.
5.1 Valoración de usuarios del sistema

El sistema se dio a probar a un usuario con estudios básicos de informática y dedicado al
sector de atención al cliente desde hace un par de años. El testimonio del usuario que
realizó las pruebas es el siguiente: “En cuanto al sistema, es un sistema muy intuitivo y
que a simple vista facilita la gestión diaria de las personas que damos soporte a clientes.
Anteriormente la gestión de los datos de los clientes los teníamos que buscar en correos
electrónicos, libretas o incluso de memoria. Parece un sistema que puede facilitarnos la
repartición de trabajo entre todos los que trabajamos en el servicio de atención al cliente
de AGlexa y así, no sobrecargar de trabajo a los agentes que más rápido solucionen las
incidencias o que mejor ratio de resolución de casos tengan.
Por último, quiero comentar que, de cara al histórico de los casos abiertos de cada uno de
nuestros clientes, se le puede dar una atención más personalizada. Además, si un cliente
contacta con uno de nosotros por un problema en concreto, cuando otro cliente contacte
por el mismo problema, podremos actuar con un mejor tiempo de resolución del caso. El
sistema permite realizar estas métricas y examinar ciertos índices como el de volumen de
casos por canal, volumen de casos atendidos por agente… De tal manera que se pueden
tomar acciones en el departamento de manera más ágil.”
101
VI. CONCLUSIONES
El principal objetivo del proyecto que era proveer al cliente de una herramienta de gestión
centralizada de datos con diferentes canales de entrada de Casos se ha cumplido de
manera satisfactoria. En cuanto a la satisfacción general del cliente, por los comentarios
tras realizar las pruebas, ha sido positiva ya que ha visto una mejora de su sistema de
gestión actual.
Dado que no es una implementación de una empresa real, sino que es una empresa ficticia
simulada para este TFG, las principales ventajas que se obtiene en un corto medio plazo
de la utilización de Salesforce son las siguientes:
• Reducción de los tiempos de gestión de Casos
• Centralización de los datos de los clientes
• Aumentar la satisfacción del cliente
• Distribución de la carga de trabajo en el departamento de atención al cliente.
• Aumento de la satisfacción de los trabajadores del departamento
A continuación, se detallan los evolutivos que se han detectado durante la implantación

de este TFG que pueden continuar aportando valor a la empresa:
• Finalización de la integración de Alexa y Salesforce.
• Notificaciones a clientes cuando se apertura su Caso por alguno de los canales
• Medición de tiempos dentro del sistema
• Generación de informes que permitan establecer indicadores de calidad por cada
uno de los agentes que utilizarán la herramienta
• Sistema de encuestas de NPS
• Tener su propio centro de conocimiento con preguntas frecuentes de tal manera
que, en la resolución de alguno de los Casos, se pueda dar una respuesta rápida
mejorando la satisfacción del cliente.
• Incorporar el canal de teléfono para atender a los clientes.
• Incorporar una comunidad de clientes a través de las cuales puedan realizar
consultas a las preguntas frecuentes.
• Habilitar otros canales de comunicación con el cliente como el chat, whatsapp o
Twitter.
• Relacionar el pedido de manera automática al Caso a través del formulario web.
• Añadir la base de productos para relacionarlo con los pedidos.
Este sistema, en un medio largo plazo, debido a la reducción de tiempos de los gestores
que trabajan en el departamento de atención al cliente, permitirá que la empresa pueda
aumentar dicho departamento, teniendo una mayor capacidad de resolución de Casos y
así seguir aumentando la satisfacción del cliente.
En cuanto a las conclusiones personales obtenidas, ha sido un TFG complicado de realizar

ya que, a la hora de montar el sistema, se tenían muchas configuraciones que realizar de
los diferentes sistemas. El punto más crítico de este TFG fue cuando tratando de hacer la
integración con Alexa, por la versión gratuita de Salesforce y algunas actualizaciones de
las librerías que se utilizaban en el código, complicó la finalización de la integración, a
pesar de haber realizado todos los pasos para desarrollarla según el manual de
desarrolladores de Alexa.
102
En cuanto a la planificación inicial del proyecto, no se ha podido cumplir debido a que se
ha desarrollado en paralelo con una jornada laboral con una tendencia de horas extras que
impedían dedicar el tiempo necesario a la realización del TFG. Como medida de
mitigación contra el tiempo, se excluyeron algunos de los canales que se tenía planificado
desarrollar como una comunidad pública en la que el cliente pudiera crear sus Casos y la
base de preguntas frecuentes que también estaría incluida en la comunidad pública.
103
VII. BIBLIOGRAFÍA
• https://formatalent.com/formacion-en-oracle-historia-y-caracteristicas/
• https://www.lahistoriadelapublicidad.com/protagonista-1050/philip-kotler
• https://www.oracle.com/index.html
• https://crearsoftware.com/2015/05/18/historia-del-crm/
• https://www.crmparaempresas.es/crm-su-historia/
• https://www.salesforce.com/mx/products/
• https://www.timetoast.com/timelines/historia-de-los-sistemas-de-
reconocimiento-de-voz-d775c41f-7117-40e8-a102-887c8332b84f
• https://www.ibm.com/ibm/history/ibm100/us/en/icons/speechreco/transform/
• https://www.exevi.com/la-batalla-de-los-asistentes-virtuales-ha-comenzado-
cual-es-tu-preferido/
• https://www.alisys.net/es/blog/de-audrey-a-siri-historia-y-uso-de-los-asistentes-
de-virtuales
• https://es.wikipedia.org/wiki/Asistente_virtual#cite_note-6
• https://en.wikipedia.org/wiki/Google_Assistant#cite_note-20
• https://es.wikipedia.org/wiki/Amazon_Alexa
• https://www.droneymas.com/amazon-echo-2a-genaracion/
• https://support.google.com/googlenest/answer/7072284?hl=es-419
• https://developer.amazon.com/en-US/docs/alexa/alexa-skills-kit-sdk-for-
nodejs/construct-skill-instance.html
• https://github.com/alexa-samples/skill-sample-nodejs-salesforce
• https://www.npmjs.com/package/nforce
• https://www.npmjs.com/package/aws-sdk
• https://www.npmjs.com/package/ask-sdk
nodejs/overview.html
nodejs/construct-skill-instance.html
nodejs/handle-requests.html
nodejs/build-responses.html
• https://developer.amazon.com/en-US/docs/alexa/ask-overviews/voice-
interaction-models.html
• https://developer.amazon.com/en-US/docs/alexa/custom-skills/host-a-custom-
skill-as-a-web-service.html
• https://developer.amazon.com/en-US/docs/alexa/custom-skills/create-intents-
utterances-and-slots.html
104
VIII. REFERENCIAS
[1] Figura1: Philip Kotler, catedrático de Marketing Internacional: https://www.reasonwhy.es
[2] Figura 2: Logos de CRM en estudio: https://www.oracle.com, https://www.salesforce.com,
https://www.sap.com
[3] Figura 3: Dispositivo de asistente de voz, Alexa: https://www.amazon.es
[4] Figura 4: Base de datos en la época de los 80: https://crearsoftware.com/2015/05/18/historia-del-crm/
[5] Figura 5: Tarjeteros Rolodex: https://www.julienslive.com/m/lot-details/index/catalog/146/lot/59724/
[6] Figura 6: Mike Munhey y Pat Sullivan, fundadores de ACT: https://www.mikemuhney.com/,
https://www.forbes.com
[7] Figura 7: Cofundadores de Oracle: https://www.businessinsider.com/
[8] Figura 8: Socios fundadores de SAP: https://aancos.com
[9] Figura 9: Thomas Siebel: https://en.wikipedia.org/wiki/Thomas_Siebel
[10] Figura 10: Marc Benioff, fundador de Salesforce: http://x-cellence.com/marc-benioff-the-genius-
behind-customer-relation-management/
[11] Figura 11: Logo oficial de las nubes de Salesforce: https://www.salesforce.com/eu/products/sales-
cloud/why-salesforce/
[12] Figura 12: Logo de la nube de ventas: https://www.salesforce.com
[13] Figura 13: Logo de la nube de Servicios: https://www.salesforce.com
[14] Figura 14: Logo de la nube de Marketing: https://www.salesforce.com
[15] Figura 15: Logo de la nube de Comunicades: https://www.salesforce.com
[16] Figura 16: Logo de la nube de ventas de SAP: https://www.sap.com/spain/products/crm.html
[17] Figura 17: Logo de la nube de Servicios de SAP: https://www.sap.com/spain/products/crm.html
[18] Figura 18: Logo de la nube de Marketing de SA : https://www.sap.com/spain/products/crm.html
[19] Figura 19: Imagen de Audrey: https://www.exevi.com/la-batalla-de-los-asistentes-virtuales-ha-
comenzado-cual-es-tu-preferido/
[20]: Figura 20: Imagen de Shoebox: https://www.ibm.com/
[21] Figura 21: Logo de Siri: https://www.freepng.es/hd-png/siri.html
[22] Figura 22: Logo de Cortana: https://commons.wikimedia.org
[23] Figura 23: Logo de Alexa: https://www.pinterest.es
[24] Figura 24: Logo de Google Assistant: https://es.wikipedia.org/wiki/Asistente_de_Google
[25] Figura 25: Echo de Amazon: https://www.electrowifi.es/es/altavoces/altavoz-amazon-echo-2-
generacion
[26] Figura 26: Echo Plus de Amazon: https://www.amazon.es
[27] Figura 27: Echo Dot de Amazon: https://www.amazon.es
[28] Figura 28: Echo Spot de Amazon: https://www.amazon.es
[29] Figura 29: Google Home: https://www.did.ie
[30] Figura 30: Google Home Mini: https://www.mediamarkt.es
[31] Figura 31: Google Nest: https://store.google.com/es/category/connected_home
[31] Figura 32: Google Nest Hub: https://www.powerplanetonline.com
105
IX. ANEXO
En este apartado se adjuntan las tablas de la carga de datos inicial que se realizó previo
a iniciar las pruebas con los usuarios de la herramienta. La herramienta utilizada es la
extensión de Google Chrome llamada Salesforce Inspector.
Salesforce Inspector permite la realización de carga de registros en la herramienta de

manera sencilla. Para la instalación de la herramienta, se ha de navegar a la página de
Chrome Web Store y hacer click en el botón Añadir a Chrome.
Figura 119: Extensión Salesforce inspector
Una vez instalada, desde la pantalla de Salesforce, en el lateral aparecerá una pestaña con
una flecha que simula un desplegable. Al hacer click, se visualiza la pantalla de Salesforce
inspector donde te permite realizar las acciones que se explican a continuación.
9.1 Data import

En esta opción, es a través de la cual se importan los datos dentro del sistema. Los datos
se pueden importan en diferentes formatos: Excel o csv. Los datos se cargan por objeto,
es decir, cada una de las tablas del Excel que se ha realizado, corresponde a cada uno de
los objetos de Salesforce que se van a cargar. En este caso, se realizará la carga de todos
los objetos, de tal manera que, el sistema contenga la información que previamente la
empresa AGlexa tenía en su sistema centralizado, exceptuando los Casos que se
comenzará con la gestión en la herramienta desde el inicio. Esto permite que la empresa
comience a trabajar en la herramienta con un histórico de sus datos.
En el caso de este TFG, se han realizado las siguientes plantillas de Excel que contemplan
los datos que se cargarán en el sistema. El formato de la plantilla de Excel que se ha
desarrollado es cabecera y cuerpo. En la cabecera se encuentra el Nombre de
desarrollador de cada uno de los campos del objeto del que se va a realizar la subida. Cada
106
fila que se muestra a continuación de la cabecera es un registro, es decir, se cargarán
tantos registros como filas haya en el Excel.
Plantilla de Cuentas
Esta plantilla está vinculada al objeto Cuentas personales de Salesforce y contiene la
información de los clientes de AGlexa.
Figura 120: Tabla de inserción de Cuentas personales
Plantilla de Productos
Esta plantilla está vinculada al objeto Productos de Salesforce y contiene la información
de los Productos del catálogo de AGlexa.
Figura 121: Tabla de inserción de Productos
Plantilla de Listas de precios

Esta plantilla está vinculada al objeto Listas de precios de Salesforce y contiene la
información de los precios de los productos del catálogo de AGlexa.
Figura 122: Tabla de inserción de listas de precios
Plantilla de Pedidos
Esta plantilla está vinculada al objeto Pedido de Salesforce y contiene la información de
los pedidos de los clientes de AGlexa.
107
Figura 123: Tabla de inserción de Pedidos
Plantilla de Productos de pedidos

Esta plantilla está vinculada al objeto Listas de precios de Salesforce y contiene la
información de los precios de los productos del catálogo de AGlexa.
Figura 124: Tabla de inserción de Productos de pedidos
Una vez se han realizado las plantillas de carga de datos, se realizará la importación con
la herramienta desde la sección Data import. Para ello, haciendo click en la opción Data
import se navega a la pantalla de importación de datos.
108
Figura 125: Pantalla de acciones de Salesforce Inspector
En la pantalla de importación, se deberán cumplimentar los siguientes datos:

• Action: Se define la acción que se va a realizar. Entre ellos, está la opción de
insertar registros, actualizar registros o eliminar registros. Se selecciona la opción
de importación.
• Object: Objeto donde se van a importar los registros. En cada una de las
importaciones de las plantillas anteriormente detalladas, se deberá seleccionar el
objeto que corresponde de Salesforce.
• Format: Se puede realizar la importación a través de un fichero Excel o un fichero
CSV. Las plantillas realizadas se importarán en formato Excel.
• Data: Se copiarán los datos de cada una de las plantillas en este campo con la
cabecera y las filas con los registros.
Figura 126: Pantalla ejemplo de inserción de registros
109
Cuando se tengan preparados los datos en la pantalla como se muestra en la imagen
anterior, se hace click en Import y los registros quedan almacenados en Salesforce.
Figura 127: Registros insertados en Salesforce
9.2 Data export

En esta opción, a través de consultas a la base de datos (Salesforce), se pueden obtener
tablas con los registros y la información que contengan en sus campos. Las consultas se
realizan con consultas de tipo Structure Query Language (SQL). Las consultas de tipo
SQL permiten realizar consultas a la base de datos de Salesforce de los diferentes Objetos
que se tienen disponibles.
Figura 128: Pantalla ejemplo de exportación de registros
110
Universidad de Alcalá
111

TFG Gonzalez Gines 2022

Cargado por

Información del documento

Descripción original:

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

TFG Gonzalez Gines 2022

Cargado por

Copyright:

Formatos disponibles

Universidad de Alcalá

Escuela Politécnica Superior

GRADO EN INGENIERÍA TELEMÁTICA

Trabajo Fin de Grado

Desarrollo de sistema de gestión de incidencias con la

Autor: Alba González Ginés

Tutora: Elisa Rojas Sánchez

GRADO EN INGENIERÍA TELEMÁTICA

Trabajo Fin de Grado

Autor: Alba González Ginés

Tutora: Elisa Rojas Sánchez

Presidente: Antonio García Herráiz

Vocal 1º: Juan Antonio Rodrigo Yanes

Vocal 2º: Bernardo Alarcos Alcázar

A mi familia, en particular a mi madre que ha sido mi punto de apoyo principal. En

El presente trabajo de final de grado titulado “Desarrollo de sistema de gestión de

El objetivo principal del proyecto es proporcionar a la empresa un sistema de gestión

Figura 1: Philip Kotler, catedrático de Marketing Internacional [1]

Abordando la definición de Philip Kotler, cualquier empresa se puede plantear la pregunta

En este caso, se utilizará la definición de CRM como aplicación o programa informático

En función del objetivo de la empresa, el modelo CRM se divide en tres categorías:

• CRM en la nube: Programa informático localizado en un espacio de la nube.

Existen múltiples sistemas de gestión de información para empresas, por tanto, se

Figura 2: Logos de CRM en estudio [2]

El sistema de CRM en el que se implementará el proyecto es Salesforce. Ya que es una

Dentro de la sección del estado de arte de este proyecto, se explicarán la arquitectura de

Además de la implementación del sistema CRM, se propone la realización de un canal de

Figura 3: Dispositivo de asistente de voz, Alexa [3]

1.1 Objetivo del proyecto

1.2 Estructura del documento

En los siguientes apartados se realizará un estudio de la evolución de los sistemas de

2.1 Historia del CRM

Figura 4: Base de datos en la época de los 80 (Historia del CRM)

Figura 5: Tarjeteros Rolodex [5]

El comienzo de la metodología CRM, surge previo a la utilización del término. Es en el

Figura 6: Mike Munhey y Pat Sullivan, fundadores de ACT [6]

Figura 7: Cofundadores de Oracle [7]

En 1978, uno de los cofundadores de la empresa, Miner, desarrolló la primera base de

Con el surgimiento de negocios que se dedicaban a almacenar la información de empresas

Figura 8: Socios fundadores de SAP [8]

SAP (Systemanalyse, Anwendungen und Programmentwicklung) surge de la unión de los

SAP evolucionaba acorde a las innovaciones tecnológicas de la época y se adaptaba a las

Figura 9: Thomas Siebel [9]

Tras el éxito de la compañía Siebel Systems, los competidores de la misma, viendo el

Marc Benioff, antiguo desarrollador de la empresa Apple y ex-trabajador de Oracle, funda

Actualmente la empresa Salesforce es uno de los líderes de mercado en soluciones CRM

A continuación, se realizará un estudio de tres de los sistemas mencionados a lo largo de

2.2 ¿Qué es la nube?

El almacenamiento en la nube implica una despreocupación por la capacidad de

A continuación se definirán las diferentes nubes que aporta Salesforce, el tipo de

2.3.1 Nubes de Salesforce

• Ventas: Nube enfocada a la atención comercial y a la generación de

Esta es la nube de Salesforce orientada a la gestión de posibles clientes potenciales que

Figura 12: Logo de la nube de ventas [12]

Es la nube de Salesforce orientada al servicio de soporte de una empresa, permitiendo

Figura 13: Logo de la nube de Servicios [13]

Esta nube permite tener un incremento de la productividad de los gestores encargados

Es la nube de Salesforce orientada al contacto con clientes permitiendo crear un mayor

Figura 14: Logo de la nube de Marketing [14]

A través de los diferentes medios de comunicación que aporta la nube de marketing,

Es la nube de Salesforce orientada proporcionar una facilidad en cuanto a la

Figura 15: Logo de la nube de comunidades [15]

En este proyecto se propone la utilización de la nube de servicios y la nube de