Documentos de Académico
Documentos de Profesional
Documentos de Cultura
Homologación Call
Técnico del Center –Portal Call
Proyecto Center
<<Código del Proyecto>>
NOTA DE CONFIDENCIALIDAD
La información incluida en este documento ha sido preparada para ser utilizada en el contexto de
este proyecto. No debe ser utilizada como modelo o precedente en ninguna situación fuera del
presente trabajo.
Este documento no debe ser copiado o reproducido por ningún medio sin la autorización de las
partes involucradas.
Se ha realizado un gran esfuerzo en la preparación de este documento para asegurar que la
información presentada es correcta y completa.
HISTORIAL DE VERSIONES
NÚMERO DE
TEMAS REVISADOS Y MODIFICADOS FECHA EFECTIVA INSERTADA POR
REVISIÓN
Contenido
Para esta solución se deberá seguir el patrón a capas que se describe a continuación.
cmp Components
Vista
Logica Interfaces
Acceso a Datos
Metas
• Se debe garantizar la integridad de la información que será utilizada.
• Toda información sobre Tarjetas de Créditos u otra información sensible deberá estar
cifrada en la Base de datos (en caso de ser almacenada por la solución)
• Se deberán seguir las directrices y recomendaciones de PCI sobre el uso de información de
TC (tarjetas de crédito / debito)
Restricciones
• Los cambios en el sistema debido a sinergias y/o definiciones no completas del negocio no
forman parte del alcance de este documento.
• La disponibilidad de la información, dependerá también de la disponibilidad de las
conexiones tanto de bases de datos, servidor web y/o conexión a internet/intranet
• La disponibilidad de información y/o tiempos de respuestas de otros sistemas
(middleware, feeManager) no hacen parte del diseño de esta solución
• Se debe tener en cuenta que al momento de tener definida la herramienta de reporteria
estándar, los reportes que hagan parte de esta solución deberán ser migrados a dicha
herramienta.
Asi mismo se plantea un segundo despliegue para efecto de testing de la aplicación, este se
plantea con redundancia para efectos de realizar pruebas de estrés sobre la aplicación.
1.3.2 Componentes
• Servidor de Aplicaciones: En este servidor se deberá alojar tanto los
componentes de lógica de la solución, las paginas aspx de la solución y los
componentes que realizaran interface con la base de datos y con terceros. Estos
deberán estar sobre un modelo de balanceo de cargas que permitirá controlar el
servicio de cada uno y así poder incrementar la disponibilidad y los tiempos de
respuesta, asi mismo se plantean servidores distribuidos geográficamente en SAL y
BOG debido a la ubicación geográfica con la que se contara en los call center
• El componente firewall: En este se deberán configurar temas de seguridad entre
otros.
• Servicios Externos: Servicios externos de los cuales hace uso la aplicación como
Middleware AVTA e integrador de ventas entre otros servicios.
• Base de Datos: Se refiere al servidor en donde se almacenara la persistencia de la
solución.
• SAN Principal, SAN de Respaldo: Se refiere al espacio compartido entre los
servidores para el almacenamiento de la data que permitirá que estos se
encuentran en un esquema fail load en caso de alguna eventualidad sobre alguno.
Vista
Interface de Usuario
Logica
Acceso a Datos
«interface»
Interfaces::Base de
Datos
• Componentes Arquitectónicos
Funcionalidad: la solución debe proveer al área de call center la gestión de solicitudes y ventas
de productos y servicios ofrecidos por Aviancataca.
Seguridad: Al manejar información sensible (como lo es TC, informacion de clientes entre otros)
la solución deberá incorporar logs de todas las transacciones que se realicen.
Portabilidad:. siendo una aplicación WEB se asegura la portabilidad sobre los navegadores este
debe asegurar que la aplicación funcione en I.E, Mozilla y Chrome mínimamente
Usabilidad: La usabilidad se deberá lograr con pantallas simples pero claras en su manejo. Es
fundamental este atributo de calidad para que el sistema se utilice y aporte lo que se busca.
A nivel de información sensible, se deberán seguir los lineamientos de PCI al tratar información
de Tarjetas de crédito/debito así como cifrar la información que se almacene en la BD e
incorporar seguridad en la comunicación de los canales entre los servidores con SSL/HTTPS.
Describir a detalle de cómo será diseñado el sistema, cuáles son las clases principales, por qué se
eligieron etc. Esta vista debe ser generada por el equipo de desarrollo.
Las clases principales dentro del Portal Call Center, son las siguientes:
Esta vista debe ser generada por el equipo de desarrollo. Debe incluir un diagrama de clases que
describa el tipo de información o nivel de detalle que debe colocarse en el diagrama de clases.
Especificar cómo será el montaje de las clases en cada uno de los componentes arquitectónicos.
Debe ser generado por el equipo de desarrollo.
Acceso a
datos
Logica de
negocio
Autorizació
n
1.6.2 Interfaces
Describir las interfaces que el sistema expone o consume
Interfaces que consume:
Portal-CCE-001
Firmar en IVR
Firmar en ARD
Autenticarse en la
Planta Telefónica
«uses»
Asignación de skill
Agente/Supervisor
Firmar en Portal
CCE
«uses»
Asignación de
perfil
Portal-CCE-002
«uses»
Carga de Identificación de
aplicativos homologados perfil
Carga de barra
integradora y tipificación
Agente/Supervisor
Portal-CCE-003
Cargado de
Ingresar ID para información de la llamada
identificación
«uses» «uses»
Cliente
Agente/Supervisor
Identificación del Cargado de
cliente información del cliente
Cargado de
información de la solicitud
Portal-CCE-004
ARD
Cotización de vuelo
Verificar
disponibilidad de viaje
Informar precio
total de vuelo
Cotización de TKT
«extends»
Carga de impuestos Carga de Service
Fee
«extends»
Verificación de datos
capturados en llamada y cargados
desde la BD Carga de impuestos
de vuelo
Cliente
Generación de PNR
Portal-CCE-005
Seleccionar tipo
de transacción
«uses»
Informar
formas/medios de pagos
Cliente
Agente Solicitar
forma/medio de pago
Portal-CCE-006
«uses»
Agente BD cliente
Solicitar datos de
TC
«uses»
Completar datos de
IVR TC
Portal-CCE-007
Portal CCE
Informar sobre TC
disponibles
«uses»
Cliente
Despliega
información de TC
Agente/Supervisor
«uses» IVR
Portal-CCE-008
Solicitar datos TC
«uses»
IVR Cliente
Completar datos TC
«uses»
Agente/Supervisor
Enviar información
Integrador de Ventas
Portal-CCE-009
Convertir PNR en
referencia de pago
«uses»
Enviar información
de valor a pagar
Autorización de
Integrador de ventas emisión
Banco
«uses»
Información de
autorización
Portal-CCE-010
Agente/Supervisor
Transferir llamada
Banco
Cliente
Autorización de
emisión
Portal CCE
Portal-CCE-011
Portal CCE
IVR
Elige opción de Muestra
proceso a seguir información del Cliente
Cliente
Conecta a IVR
Valida PIN de
cliente corporativo
Continúa proceso
segun opción
Nombre Descripción
Agente CCE Usuario que ingresa y hace uso del portal CCE.
Supervisor Usuario que ingresa y hace uso del portal CCE con privilegios.
Cliente Persona que realiza la llamada al Call Center para solicitar un
servicio.
IVR Captura datos y transfiere llamadas de cliente.
BD Clientes Repositorio que contiene la información personal de los clientes.
Banco Conjunto de entidades o instituciones que prestan el servicio de
pagos de transacciones.
Portal CCE Plataforma que reúne las funcionalidades del Call Center.
MiddleWare Intermediario de comunicación entre Amadeus y las aplicaciones.
Actores
Agente, Supervisor
Post Condiciones
Escenario de éxito:
1. Usuario se firma en IVR. (Regla de Negocio 1)
Flujos Alternativos(Extensiones)
Actores
Agente, Supervisor
Objetivo
Desplegar las opciones del usuario ingresado en el portal CCE.
Post Condiciones
Escenario de éxito:
1. El Portal CCE identifica el perfil del usuario ingresado. (Regla de Negocio 2)
Flujos Alternativos(Extensiones)
1. Usuario no tiene perfil asignado en el Portal CCE.
Actores
Agente, Supervisor, Cliente
Post Condiciones
Escenario de éxito:
1. Cliente se identifica por medio del IVR (Regla de negocio 4 y Regla de Negocio 5)
Flujos Alternativos(Extensiones)
1. Cliente no introduce la información correctamente.
5. El portal CCE no carga la información del tipo de solicitud que el cliente seleccionó.
Actores
ARD, Cliente, Agente, Supervisor y Fee Manager
Post Condiciones
Escenario de éxito:
1. Cliente proporciona información del viaje al asesor.(Regla de negocio 8 y Regla de
negocio 15)
6. Portal CCE se conecta con Fee Manager para cargar el Service Fee.
10. Agente/supervisor transfiere información del cliente para realizar la reserva. (Regla de
Negocio 9)
11. Agente/supervisor transfiere información del cliente a ARD para generar el PNR.
Flujos Alternativos(Extensiones)
1. Cliente no proporciona información del viaje al asesor.
6.1. El gente solicita el ID del cliente e incluye la información en la ventana del cliente
dentro del portal CCE.
7.1. Notificar error al cliente, a causa de la ausencia de algún dato faltante o mal
introducido.
el PNR.
Actores
Agente, Supervisor y Cliente
Post Condiciones
Escenario de éxito:
1. Cliente selecciona el tipo de transacción que desea efectuar. (Regla de negocio 10,
para aquetes turisticos Regla de negocio 16 y Regla de negocio 17)
Flujos Alternativos(Extensiones)
1. Cliente no selecciona tipo de transacción.
Nombre del caso de uso Registro de Cliente Nuevo y Tarjeta de Crédito del Cliente
Actores
Agente,Supervisor, BD Clientes, IVR
Post Condiciones
Escenario de éxito:
1. Agente/supervisor Solicita información del cliente.(Regla de negocio 11)
Flujos Alternativos(Extensiones)
1. Información del cliente no fue obtenida o completada
Actores
Agente, Supervisor, Cliente , IVR
Post Condiciones
Escenario de éxito:
1. Agente/supervisor selecciona la tarjeta de crédito que se utilizará. (Regla de
Negocio 11)
Flujos Alternativos(Extensiones)
1. Cliente no completa datos de tarjeta de crédito
1.1. Notificar al cliente los datos necesarios para completar la información de tarjeta
de crédito.
Nombre del caso de uso Autenticación de Cliente Existente y Tarjeta de Crédito Nueva
Actores
Agente, Supervisor, Cliente , IVR, integrador de ventas
Post Condiciones
Escenario de éxito:
1. Agente/supervisor guarda información de tarjeta de crédito del cliente. (Regla de
Negocio 11)
Flujos Alternativos(Extensiones)
1. Cliente no completa datos de tarjeta de crédito
Actores
Agente, Supervisor, Cliente, integrador de ventas, Banco
Objetivo Brindar los estatutos necesarios para la realización del pago por
medio de transferencia
Precondiciones • Información de cliente Adquirida
Post Condiciones
Escenario de éxito:
1. Agente/supervisor convierte el record de la reserva en referencia de pago. (Regla de
Negocio 12 y 13)
Flujos Alternativos(Extensiones)
1. Banco no autoriza emisión de transferencia.
Objetivo Brindar los estatutos necesarios para la realización del pago por
medio de Sistema de Audio-respuesta de entidad consolidadora
de bancos.
Precondiciones • Información de cliente Adquirida
Post Condiciones
Escenario de éxito:
1. Agente/supervisor transfiere llamada a Banco para solicitar servicio (Regla de Negocio
14)
Flujos Alternativos(Extensiones)
1. Banco no autoriza el servicio solicitado.
Actores
Agente, Cliente
Post Condiciones
Escenario de éxito:
1. Cliente ingresa el la opción de transacción que desea realizar a través del IVR
4. Asesor transfiere al cliente hacia el IVR para que ingrese su PIN corporativo.
Flujos Alternativos(Extensiones)
1. Cliente no posee PIN corporativo
Actores
ARD, Cliente, Agente, Supervisor y Fee Manager
Objetivo
Vender un servicio para las reservas
Post Condiciones
Escenario de éxito:
1. Agente realiza reserva con especificaciones proporcionadas por el cliente en ARD.
4. El portal CCE se conecta con Fee Manager para cargar el servicio e información de
reserva y pasajeros.
5. El agente elije a que pasajeros y para que piernas del itinerario asignar el servicio
seleccionado previamente.
Flujos Alternativos(Extensiones)
1. Cliente no proporciona información del viaje al asesor.
9.1 Mostrar mensaje de error con la causa por la cual la transacción no fue
aceptada por el integrador de ventas.
Actores
ARD, Cliente, Agente, Supervisor y Rapid Reprice
Objetivo
Realizar un cambio de fecha para una reserva
Post Condiciones
Escenario de éxito:
1. Agente coloca PNR/Ticket number en el portal call Center y el apellido del cliente
como mínimo y da clic en cargar.El agente/supervisor verifica disponibilidad de las
especificaciones del viaje.
2. El portal CCE se conecta con Rapid Reprice para validar si la reserva aplica a un
cambio de fecha.El agente/supervisor realiza la cotización del ticket.
3. El portal CCE conecta con Travelport para realizar el cambio de fecha acorde a las
necesidades del cliente.Portal CCE se conecta con Fee Manager para cargar el
Service Fee.
4. Luego de terminar el cambio en Travelport el portal despliega los totales para que
el agente notifique al cliente el costo total.
Flujos Alternativos(Extensiones)
1. Cliente no proporciona información del viaje al asesor.
2.5 de Negocio.
(Fase de Diseño, Ejecución e Implementación)
Así mismo se reconoce los ANI el origen de la llamada y los DNI a donde debe dirigir la llamada.
Cada Planta telefónica tiene un menú configurado para cuando llama el viajero escoja la opción
que desea realizar. *
Si no se pudieron capturar los datos del cliente en la llamada, el asesor solicita el ID del viajero y
lo incluye en la ventana de cliente que tiene el portal de CCE para hacer la búsqueda.
3. Compras o cambios a tkt comprados: En esta opción IVR ofrece dos opciones del menú: 1.
Compras y 2. cambios en tiquetes comprados.
El Porta CCE identifica la oficina según origen de la llamada, donde firma automáticamente al
asesor en el OID que aplique.
El portal de CCE tiene la opción de cambio manual de OID (se define por proceso los casos) y la
correspondiente firma en ese OID elegido.
5) Script de Venta
Según datos de viaje el asesor, así es la disponibilidad y cotización del TKT según origen de la
llamada en ARD.
Los impuestos se cargan de forma automática.
El Portal CCE está conectado a la aplicación de Fee Manager para cotizar los Service Fee
(servicios especiales).
La CCE muestra al Asesor el total del TKT + Service Fee para informarle al cliente el costo total
de su cotización.
Con esta información el Asesor informa al viajero las formas y medios de pago con las que cuenta
en el país donde está haciendo la llamada. Dichas formas y medios son:
• Pago por tarjeta de Crédito
• Pago por Depósito
• Pago por Transferencia
• Pago por cheque, efectivo y a domicilio.
• Pago por Sistema de audiorespuesta de entidad consolidadora de Bancos (PSE).
El asesor diligencia por medio de una ventana los datos de la TC los siguientes campos de
información:
o Número y tipo de documento (aplica solo para los casos que el ID sea alfanumérico
y esta fue la indicación del TH en el IVR)
o Entidad Bancaria (nombre banco emisor de la tarjeta)
o Dirección a donde recibe el extracto de la cuenta bancaria
o Nombres de como figura en el plástico
o Apellidos de como figura en el plástico
o Código de país
o Ciudad
o Estado
o Zip code (para US y CA)
• Cliente Existente y Tarjeta de Crédito Existente: El asesor puede ver las tarjetas de crédito
activas que tiene guardadas el Viajero en la BD.
Hay un botón para conectar al cliente con el IVR para completar los datos de TC, el IVR
informa al Cliente la TC seleccionada (4 últimos dígitos), Si el cliente está de acuerdo, se
continúa el proceso para solicitar CVV y Fecha de Vencimiento.
Los datos de CCV y fecha de vencimiento no se almacenan en la BD, estos datos deben
estar siempre encriptados y borrados después de que se haga la compra.
Existe un botón para poder guardar la información del viajero si el acepta, o que solo
estén temporalmente en la pantalla mientras se hace la venta.
• Cliente Existente y Tarjeta de no está creada: Si el cliente no tiene una tarjeta de crédito
creada o registrada se le solicitan los datos por medio de un IVR. Debe existir un botón
que lo conecte con este IVR. Luego se conecta con IVR para solicitar: Número de TC,
Fecha Vencimiento, CCV2.
Regla de Negocio 13: Formas de Pago mediante cheque, efectivo y el pago es hecho a
domicilio.
En el Portal de CCE hay un programa para que el asesor administre las solicitudes de domicilio.
En esta APP el asesor digita la forma de pago y la dirección donde se llevará el servicio a
domicilio, fecha y hora de entrega. Este aplicativo confirma si la dirección aplica para este
servicio, también consulta en qué estado se encuentra las solicitudes de domicilio.
El portal CCE tiene un programa para recolectar información del pago y armar una estructura al
enviarla al integrador de ventas para la emisión
El integrador de ventas ingresa automáticamente la forma de pago de acuerdo a la seleccionada
por el Asesor y emite el ticket para ponerlo en estado suspendido inmediatamente después de su
emisión cuando el viaje sea en las próximas 24 horas.
Una vez el mensajero confirme vía SMS "OK PAGO" el recibido del dinero, el portal de CCE
recolecta esta información para que el asesor de BO levante automáticamente el estado de
suspendido.
IVR de TC para que el cliente digite los datos de CCV2 y fecha de vencimiento de la TC
seleccionada.
El IVR envía estos datos a la BD única donde se almacenaran temporalmente ya que después de
la venta hay un procedimiento automático para que se borren los datos.
En el portal de CCE hay una ventana donde se muestre al asesor el nombre del cliente, tipo id,
numero id, correo electrónico, cuatro últimos dígitos de la TC, numero de cuotas y campos de
para que el asesor ingrese manualmente el valor a pagar del paquete turístico.
Los campos incluidos son: El costo del valor servicio, valor de impuestos, valor otros impuestos,
valor de Tarifa Administrativa y Total del Paquete turístico. Dichos valores serán digitados
manualmente por el agente.
El Portal de CCE genera un código de la transacción a realizar, ya que el paquete turístico no ha
generado hasta el momento PNR. La transacción se hace automáticamente y de forma offline.
El portal de CCE envía información del cliente, código transacción, información del pago del
paquete turístico al integrador de ventas para que se haga la validación automática con el
modulo antifraude y pase por la pasarela de pagos.
Politica de Seguridad
PCCE
4 Seguimiento a Riesgos
(Fase de Diseño, Ejecución e Implementación)
Informe GRTI-PCCE
PV
5 Pruebas funcionales
(Fase de Diseño, Ejecución e Implementación)
Completar la matriz de pruebas funcionales utilizadas para llevar el control de los cambios
realizados a los casos de prueba debido a cambios en documentación, requisitos u otras
modificaciones durante el ciclo de vida del proyecto.
QC TestScript - QC TestScript -
Desarrollo.xls Operaciones.xls
6 Control de Cambios TI
(Fase de Diseño, Ejecución e Implementación)
Completar en el archivo adjunto el detalle de las actividades que se deben tener en cuenta para
la salida en vivo del proyecto en ambiente productivo. Este es un requerimiento que debe ser
presentado y sustentado ante el Comité de Cambios de TI, con el fin de que dicho ente entregue
el aval para la implementación.
Control de Cambios
TI
7 Glosario
(Fase de Planteamiento y Viabilidad – Fase de Diseño, Ejecución e Implementación)
Definir o clarificar los términos principales del negocio utilizados en este documento.
TÉRMINO DEFINICIÓN