Londrina, 07 de outubro de 2015. EDITAL CONCORRÊNCIA PÚBLICA N.º 001/2015 PROCESSO ADMINISTRATIVO 009/2015 OBJETO: Art.1º. Constitui objeto desta licitação a aquisição de 01 (uma) Plataforma de Solução Unificada para Relacionamento com o Cliente, denominada Plataforma Unificada, contendo: Tecnologia IP, Telefonia, DAC, Contact Center, URA, CTI, Gravador, Discador, Tarifador, Bilhetador, Front End, Servidor de aplicação para Multimídia, Sistemas de Relatórios, Banco de Dados, WFM, SBC e outros agregados, devendo atender, integralmente, todas as condições exigidas na Especificação Técnica ETA 002/2015, Anexo I, desta Concorrência. QUESTIONAMENTOS/RESPOSTAS 003_CP001/2015 Esclarecimentos da ASK aos questionamentos referentes ao Edital da Concorrência Pública N.º 001/2015: QUESTIONAMENTO 01 O item 13.4.3 especifica: A ferramenta deverá gerar Front End (telas de atendimento) para as arquiteturas WEB e ClienteServidor de forma automática sem a necessidade de adequação de códigos. Precisamos confirmar se está sendo solicitada apenas uma versão WEB ou a expressão "C liente Servidor" quer indica uma versão desktop (instalável no computador da PA). A ferramenta que deverá gerar o Front End Telas de Atendimento deverá ser de arquitetura WEB e Cliente-Servidor, mas o resultado do desenvolvimento do Front End é via WEB. QUESTIONAMENTO 02 Precisamos confirmar se o toolbox utilizado na PA conseguirá abrir uma janela do navegador web Google Chrome ou similar, para chamar a URL do front end, enviando campos via GET para identificação do contato, como ANI, CPF, CNPJ, etc. A integração entre o Toolbox e o Front End é de responsabilidade do proponente vencedor do certame.
QUESTIONAMENTO 03 O item 13.4.13 especifica: O Front End deverá ter APIs para JAVA e.net ou DLL ou OCX. As APIs devem ser unificadas contendo todos os métodos com suporte aos distintos canais de atendimento (Chat, Email, Voz), visando possibilitar integrações de aplicações externas de maneira fácil, rápida e estruturada. Podemos fornecer API apenas no padrão.net. Precisamos detalhar melhor a finalidade deste item (o que se espera realizar com essa API). Não seria melhor o fornecimento de webservices, por se tratar de uma aplicação web? O banco de dados do front end deveria estar disponível apenas para acessos originados pelo servidor web. Pelo fato de ser JAVA e.net pode ser utilizado a solução WEBSERVICE. QUESTIONAMENTO 04 Item 13.4.14: O Front End deverá prover informações do perfil dos clientes e não clientes. Haverá uma visão geral de todas as informações de forma agregada numa única tela. Dessa visão, poderá ser feito o detalhamento (drill down) das informações até o nível mais específico disponível nos sistemas corporativos. As informações do perfil estarão na aplicação do front end ou devem ser obtidas por integração com outro sistema? Temos alguma previsibilidade de que informações são essas passíveis de detalhamento? Temos algo para ver neste momento, auxiliando o entendimento? O item acima esclarece a forma de prover as informações. A Ask em conjunto com o cliente estará disponibilizando procedure ou webservice com as informações dos seu clientes para o proponente vencedor do certame. QUESTIONAMENTO 05 Item 13.4.15: O Front End de atendimento deverá disponibilizar em tempo real todas as informações corporativas (cadastro de clientes, dados transacionais, etc.) residentes nos sistemas corporativos e/ou em bases de dados locais.
Quantas integrações serão necessárias para obtenção desses dados? O modelo de integração a ser adotado será via webservices? Não terá limites a quantidade de interações para obtenção dos dados. O modelo de interação será através de webservices ou através de procedures conforme a necessidade da Ask!. QUESTIONAMENTO 06 Item 13.4.16: O Front End deverá prover uma base de conhecimento estruturada, com busca de palavras chave para apoio da resolução de problemas ou esclarecimento de dúvidas. A base de conhecimento deve prever diferentes mídias, como imagens, vídeos, texto? Em texto. QUESTIONAMENTO 07 Item 13.4.17.1: Identificação positiva. A identificação positiva deverá ser feita através de alguns dados cadastrais escolhidos aleatoriamente de um subconjunto previamente definido. O agente digita as informações indicadas pelo cliente, que foram pedidas pelo sistema, e o sistema indica se a informação confere como cadastro. Precisamos detalhar melhor o funcionamento da identificação positiva. Temos algum exemplo de tela ou documentação para analisar? Um exemplo de identificação positiva é o agente digitando o número de inscrição de um telefone, o sistema verificando se a informação passada pelo agente existe ou não. QUESTIONAMENTO 08 Item 13.4.18.3: Informações pró ativas a clientes, atendentes e supervisores sobre mudanças no andamento das ocorrências.
Como as informações pró ativas estarão disponíveis para clientes? A partir de um site para consultar pelo protocolo de atendimento? Pró-ativa a cliente, seria o operador repassando a informação para o cliente pelos motivos abordados nesse edital. QUESTIONAMENTO 09 Item 13.4.21: O Front End deverá fornecer aos sistemas corporativos do Contact Center informações para análise de freqüência, recência e latência do relacionamento com o cliente. Em contato coma Angélica na sexta-feira, ela nos falou que a parte de relatórios não entraria no escopo da Datavolus. Precisamos confirmar se o front end Datavolus precisa gerar alguma visão/relatório. Não entendemos seus questionamentos. QUESTIONAMENTO 10 Item 13.5.6: O Sistema Ofertado deverá oferecer mecanismos de identificação e autenticação do usuário e controle de acesso através de listas de controle (ACL) ou RADIUS ou LDAP. A escrita deste item não possibilita o entendimento se os três mecanismos de identificação precisam ser desenvolvidos ou apenas um entre os três relacionados. A expressão ou indica que o proponente deverá oferece uma das condições desse item. QUESTIONAMENTO 11 Item 13.5.8: O Sistema deverá permitir o atendimento personalizado e diferenciado, de acordo com regras de segmentação e perfis de clientes. A repercussão sobre o front end não fica clara. Precisamos detalhar melhora amplitude desta personalização por perfil de cliente. A personalização será efetuada conforme a necessidade da Ask! E respeitando o cronograma descrito no item 4.5.
QUESTIONAMENTO 12 Item 13.5.9: O Sistema Ofertado deverá permitir a criação dos scripts em interface gráfica e a partir de informações fornecidas pelos sistemas corporativos. O script pode ser entendido como o texto de atendimento a ser utilizado pelo operador ou apresenta repercussão no fluxo de atendimento da ferramenta (campos e regras de preenchimento diferentes)? O Item 13.5.9 é referente à ferramenta de criação dos scripts. QUESTIONAMENTO 13 Item 13.5.12: O Sistema Ofertado deverá disponibilizar mecanismo de parametrização de forma a permitir ajustes e refinamentos dos processos de atendimento de forma a refletir a evolução das regras de negócio. Semelhante ao questionamento anterior, isso gera necessidade de autonomia da Ask sobre a gestão das regras de negócio do sistema de atendimento? Quando necessário a Ask deverá ter autonomia sobre a gestão das regras de negócio do sistema de atendimento. QUESTIONAMENTO 14 Item 13.5.16: O Sistema Ofertado deverá estar integrado e preparado para atendimento em todos os canais de interação (voz, fax, Chat, sms, e mail, etc). Cada canal demanda um fluxo de atendimento diferente? Sim, esta correto seu entendimento. QUESTIONAMENTO 15 Item 15.5 aborda WEB CHAT: Já existe solução definida para disponibilizar o web chat? Está fora do escopo front end?
A solução Web Chat será fornecida pela proponente vencedora do certame e entrará como um atendimento, atualmente a Ask não possui essa ferramenta e será visualizado pelo Front End. QUESTIONAMENTO 16 Itens 15.6.1 e 15.6.3: O Sistema Ofertado deverá ser totalmente inovador e interativo, atendimento on line, coma interface de atendimento via mensagem de texto (SMS). Ela permite que as mensagens recebidas pelo agente, através do módulo SMS, sejam registradas em um banco de dados e distribuídas aos atendentes da mesma forma que as ligações telefônicas. Exemplo de aplicação: um cliente envia um SMS para a ASK perguntando qual é o procedimento de troca de produto. O atendente recebe a mensagem no SMS, elabora a resposta e a envia ao celular do cliente. Este atendimento tem que passar pela fila de atendimento e fornecer protocolo. Quais são os rebatimentos de interface e integrações para o front end em relação ao atendimento via SMS? Essa visualização da mensagem e resposta acontece no front end? A integração será desenvolvida entre a proponente vencedora do certame e o cliente/ask utilizando Broker SMS. Sim será visualizado pelo Front End. QUESTIONAMENTO 17 Item 18.3.1.1: A Plataforma Unificada ofertada deverá permitir que um sistema externo, faça a alteração do status do operador, através de comandos SQL ou diretamente no Cliente de atendimento, em tempo real, sempre que for necessário. O PROPONENTE deverá disponibilizar toda a documentação e suporte para essa integração. Devemos entender que toda ação possível pelo front end deve também estar disponível para ser feita via integração? Novamente, isso pode ser feito via webservices? - Sim, deve estar disponível. - Através de comandos SQL ou diretamente no Cliente de atendimento... Se o acesso no cliente de atendimento for via webservices também é uma opção aceitável, ficará a escolha da Ask a melhor forma de acesso.
QUESTIONAMENTO 18 Item 18.3.1.2: A Base de dados deverá ser do tipo transacional e relacional e dimensionada para suportar o armazenamento de informações relativas as diversas soluções tecnológicas do Contact Center, considerando o armazenamento de dados históricos por prazo mínimo de dois anos, em disco rígido. Será especificado um prazo máximo de armazenamento, onde o expurgo de dados deve acontecer? Essa informação é fundamental para estabelecimento da infra estrutura. Prazo mínimo de armazenamento desse item é de dois anos, podendo ser expurgado para o storage da Ask após esse período. QUESTIONAMENTO 19 Item 19.1.4.1: O Sistema de Gerência Centralizada da Plataforma Unificada Ofertada deverá possuir as seguintes facilidades/funcionalidades: 19.1.4.1.1 Gerência de Falhas, Alarmes e Supervisão; [...] 19.1.4.1.6 Gerência de Manutenção. 19.1.4.2 Permitir a definição de usuários e senhas, limitando níveis de Acesso ao Sistema da Plataforma Unificada Ofertada com as seguintes características: 19.1.4.2.1 Cadastro e controle de usuários individuais e de Grupo de Usuários, parametrizável, com níveis de acesso controlado; Como o front end e seus próprios cadastros devem interagir como sistema de gerência centralizada? Estará tudo numa mesma interface? Item 19 é o Apêndice Técnico XV sobre Requisitos Técnicos Mínimos da Especificação para Arquitetura e Características Construtivas de Hardware e Software da Plataforma Unificada Ofertada. Quanto à interação entre o Front End e o sistema de gerência centralizado é de responsabilidade da proponente vencedora do certame. QUESTIONAMENTO 20 Item 21.2 Requisitos relativos a Interfaces com Sistemas Externos: 21.2.1 A Solução de integração deverá permitir a integração com servidores de aplicação compatíveis com o padrão Java EE ( Java Enterprise Edition) versão 7 ou superior.
Não sabemos se este item engloba o front end, mas podemos disponibilizar integração em.net. Deverá permitir a integração com servidores de aplicação compatíveis com o padrão Java EE ( Java Enterprise Edition) versão 7 ou superior. QUESTIONAMENTO 21 Item 28.5 Estabelece os níveis de suporte: A Datavolus precisará disponibilizar qual nível de suporte para o projeto? O período é de 12 meses após a entrada em operação? O suporte será oferecido pela proponente vencedora do certame. Atenciosamente, Paulo Sergio Mattos Cesar Presidente da Comissão Especial de Licitação Concorrência 001/2015