Request for Proposal

Request for Proposal
A Stone Pagamentos abre concorrência para
fornecimento de soluções tecnológicas.
São Paulo, 29 de Junho de 2016.
Sumário
1
INTRODUÇÃO ................................................................................................. 3
1.1
1.2
2
DECLARAÇÃO DO TRABALHO....................................................................... 4
3.1
3.2
3.3
3.4
3.5
3.6
4.
PROPÓSITO DA RFP (REQUEST FOR PROPOSAL) .............................................. 3
SOBRE A STONE PAGAMENTOS S.A. ..................................................................... 3
ENTREGA DA PROPOSTA ......................................................................................... 11
ESCLARECIMENTOS ................................................................................................... 11
CUSTO DA PROPOSTA .............................................................................................. 11
CONTEÚDO DA PROPOSTA .................................................................................... 11
ORÇAMENTO ............................................................................................................... 13
CRITÉRIOS DE SELEÇÃO............................................................................................ 13
RESPONSABILIDADES, TERMOS E CONDIÇÕES ....................................14
1 INTRODUÇÃO
1.1 PROPÓSITO DA RFP (REQUEST FOR PROPOSAL)
O time de Relacionamento com o Cliente da Stone Pagamentos S.A., convida através desse
documento empresas consolidadas no mercado com experiência comprovada para o
fornecimento de uma proposta de um software de atendimento que seja integrado a um
sistema PABX que forneça um serviço de telefonia fixa comutada.
O projeto tem como objetivo mostrar quais os parâmetros que o software de atendimento e
o PABX precisam possuir para atender as necessidades da empresa. Além disso, ele também
definirá o custo de orçamento, data para entrega, critérios de avaliação e responsabilidades
das empresas.
As principais entregas serão:
1. Um modelo completo sobre as funcionalidades do sistema do fornecedor;
2. Um orçamento sobre quanto custaria este sistema para a empresa contratante;
3. Prazo para implantação e implementação do sistema na Stone.
1.2 SOBRE A STONE PAGAMENTOS S.A.
A Stone é uma Adquirente de meios de pagamento, autorizada pela Visa e Mastercard a
credenciar lojistas, processar e autorizar transações de cartão de crédito com essas bandeiras
e outras.
A fundação da Stone se deu em 22 de Junho de 2012, tendo com o propósito principal de
fazer diferente, servindo aos comerciantes com excelência e provendo as melhores tecnologias
e inovações do mercado.
Um dos seus valores é ter o cliente como missão de vida. Desta forma a empresa preza pela
qualidade dos seus serviços prestados, precisando para isso ter ferramentas que a ajude a
melhorar a experiência do lojista.
2 DECLARAÇÃO DO TRABALHO
Seguem todos os detalhes em relação ao trabalho a ser executado.
1. SOFTWARE DE ATENDIMENTO
1. Foma de aplicação:
a. Aplicativo baseado na nuvem, SaaS.
2. Tickets
a. Características
i. Número de identificação – cada ticket deve possuir um número de
identificação;
ii. Split – função de dividir um ticket caso seja necessário
iii. Fusão de tickets – poder fundir tickets relacionados ao mesmo
assunto/organização;
iv. Departamentos – criação de departamentos dentro do sistema para
que toda a empresa possa utilizá-la;
v. Classificações:
1. Novo – ticket que acabou de chegar;
2. Aberto – ticket já respondido inicialmente;
3. Pendente – esperando alguma resposta do cliente;
4. Em espera – esperando alguma resposta interna;
5. Resolvido – quando o ticket realmente foi resolvido.
vi. Distribuição automática – o sistema distribui automaticamente os
tickets entre as caixas dos grupos de atendimento;
vii. Atribuição de tickets – atribuir o ticket a quem o está tratando ou
atendeu inicialmente para que possamos ter um tracking;
viii. Compartilhar Ticket;
ix. Acesso aos eventos ocorridos no ticket
x. Separação entre comunicação interna e externa
xi. Macros – ações desencadeadas pela seleção de uma macro.
xii. Opção de visualizar mais de um ticket ao mesmo tempo
xiii. Exibição de todos os agentes presentemente no ticket
xiv. Tags.
b. Tipos de tickets:
i. Dúvidas;
ii. Solicitações;
iii. Incidentes;
iv. Problema;
c. Visualizações:
i. Criar caixas de visualização distintas
ii. Inserir condições de filtro lógico (Ex: ||, &&)
iii. Atribuição de visualizações para um usuário ou um grupo de
usuários
iv. Opções de filtro de visualização, por atualização, sla entre outras;
d. Usuários:
i. Níveis distintos de agente com atribuições distintas
ii. Grupos de usuários (mais de um grupo por usuário)
iii. Usuários finais
iv. Organizações com opção de mais de um usuário por organização.
v. Organizações com informações pegas de nossa base;
vi. Atribuição de tags a usuários.
e. Campos de Tickets
i. Criação ilimitada de campos de tickets dos tipos
1. Checkbox
2. Lista suspensa
3. Texto livre
4. Numérico
5. Personalizado (Captura uma entrada que é verificada de
acordo com a expressão regular definida por você. )
f.
Formulários
i. Formulários – Ter diferentes formulários para os diferentes grupos;
ii. Seleção de campos diferentes por formulário.
iii. Escolha condicional de campos.
g. SLA
i. SLA de primeira resposta
ii. Atribuição de SLAs diferentes de acordo com campos do ticket
(assunto)
iii. Atribuição de SLA por canal de contato
iv. Atribuição de SLA por grupo de usuários
v. Atribuição de SLA por usuário
vi. Definição de horários de atendimento
vii. Metas
viii. Condições lógicas
h. Gerenciamento de Ticket
i. Ações em massa – poder fazer ações em massa em diversos tickets;
3.
4.
5.
6.
ii. Filtro de spam – ter um filtro de spam para bloquear mensagens
indesejadas;
iii. Substituição de palavras – substituir palavras ou sequência de
números que não deveriam estar aparecendo para o agente ou ficar
registradas no helpdesk;
iv. Agrupamento de tickets – agrupar e desagrupar os tickets pelos
diferentes meios de entrada (E-mails, Chats, Calls, Facebook &
Twitter);
v. Automações
vi. Gatilhos
vii. Chat
1. Integração – que o chat seja integrado no sistema, não
havendo necessidade de se estar em várias telas para
conversar com o cliente;
2. Criação de log – Que todo chat crie um ticket com o log da
conversa;
viii. Telefone
1. Integração - que o telefone esteja integrado com a
ferramenta, gerando um ticket ao atender uma ligação;
ix. Facebook e Twiitter
1. Integração - que a ferramenta esteja integrada com estas
redes sociais para que da ferramenta possamos postar as
respostas;
Base de conhecimento
a. Ter uma base de conhecimento interna e externa com artigos, fóruns e
feedbacks
Busca Livre:
a. Busca por usuários, organizações, tickets, tags e termos dentro dos
comentários dos tickets
Canais de contato:
a. Criação de email personalizado (EX: “@portalstone.nomedosoftware.com”)
Métricas:
a. Integração com software de BI. (Ex: Gooddata, MS Power BI, BIME)
b. Métricas nativas
7. Plugins e aplicativos e integrações:
a. Ter uma integração com um pabx na nuvem;
b. Possibilidade de migrar os tickets do Zendesk para a nova ferramenta;
c. Integração com aplicativos 3rd party.
d. Possibilidade de criar e integrar aplicativos de acordo com a necessidade da
empresa.
e. Personalização do software ( Ex: Edição de CSS)
8. Restrição:
a. Não pode ser open source.
b. Possuir uma White List (processo que limita a administração da Zendesk em
ambientes que não são da Stone, só seria possível acessar a Zendesk na rede
da Stone);
c. Possuir Custom SSL: processo para fazer com que a URL da Zendesk seja
com um domínio da Stone;
d. Controles de ISO 27.000
e. Possuir Polítias de Segurança;
f. Possuir uma Política de Privacidade;
g. Possuir Credit Card Security
2. PABX
1) Itens técnicos:
a) Utilizar o protocolo SIP;
b) Possuir capacidade para pelo menos 300 ramais;
c) Ter a capacidade de pelo menos 100 ligações simultâneas;
d) Ser um PABX virtual;
e) Ter a capacidade de fazer redundância;
f) Poder fazer ligações internas entre ramais;
g) Não ser open source;
h) Fazer transferências pra números externos, como número de parceiros.
2) Funcionalidades:
a) Relatórios:
i)
Log de ligações com:
(1) O número que ligou;
(2) Quando ligou;
(3) Para qual número ligou;
(4) Status das chamadas;
(5) Tempo de duração das ligações feitas;
(6) Tempo de duração das ligações recebidas;
(7) Tempo total de ligações feitas e recebidas;
(8) Tempo médio de conversa;
(9) Quantidade das das ligações feitas;
(10) Quantidade das das ligações recebidas;
(11) Quantidade de ligações feitas que não tiveram resposta;
(12) Total das quantidades das ligações feitas e recebidas;
(13) Total de tempo falado;
(14) Total de chamadas que estouraram o SLA;
(15) Quanto tempo esperaram na fila;
(16) Tipo de chamada – se é originária de fixo, celular, inter-urbano etc;
(17) Quantidade de callbacks;
(18) Qual o custo da chamada;
(19) Para quais agentes a ligação tocou.
ii) Agentes:
(1) Quantidade de agentes logados/deslogados;
(2) Quantidade de tempo falado;
(3) Quantidade de ligações atendidas;
(4) Ramais dos agentes;
(5) Quais agentes estão em quais filas;
(6) Qual o tempo logado dos agentes.
iii) Filtros:
(1) Tipos:
(a) Por filas;
(b) Por agentes;
(c) Por dias;
(d) Por horas;
(e) Por mês.
(2) Periodicidade de entrega:
(a) Uma única vez;
(b) Diariamente;
(c) Primeiro dia da semana;
(d) Semanalmente.
iv) Exportação:
(1) Excel;
(2) PDF;
(3) CSV;
(4) Imagem.
b) Softphone:
i)
Ter um client individual para uso dos agentes;
ii) Ter acesso ao histórico de ligações recebidas naquele ramal;
iii) Ter um botão de presença – o usuário consegue de sua tela verificar o status
dos outros agentes;
iv) Botão para poder se logar e deslogar da fila, sem a necessidade de ir em
outra tela;
v) Power Call - Ligar para uma lista de números sem precisa ir discando número
por número. Ele iria ligando automático;
vi) Possuir uma agenda telefônica;
vii) Fazer callback;
viii) Fazer transferência de ligações entre ramais;
ix) Fazer transferência com supervisão – o agente poderá antes de passar a
ligação, conversar com o outro agente para saber se ele pode atender;
x) Fazer transferência assistida – uma transferência em que dois atendentes
possam estar na mesma ligação com o cliente, melhorando assim a
experiência do mesmo;
xi) Fazer conferências;
xii) Ter teclas de atalho.
xiii) Poder agendar um horário para fazer ligações;
xiv) Ser expansivel, seja por plugins, chamadas externas ou integração direta;
c) Switchboard – ter um switchboard online que forneça telas com as
informações:
i)
Visão de todos os atendentes com seus respectivos status;
ii) Visão de quantas pessoas estão atendendo;
iii) Opção de logar/deslogar pessoas sem precisar entrar na central administrativa em
si – sendo o adm da fila;
iv) Visão de quantas ligações os usuários estão atendendo;
v) Visão de qual o tempo falado dos usuários naquele dia;
vi) Wallboard contendo informações sobre:
(1) Quantidade de ligações na fila de atendimento;
(2) Quantidade de ligações atendidas;
(3) Quantidade de ligações abandonadas;
(4) Quantidade de ligações tatais na quele dia;
(5) Quantidade de agentes ocupados;
(6) Quantidade de callbacks;
(7) Tempo médio de espera.
d) Central administrativa:
i)
Ter uma central administrativa em que se possa configurar o pabx;
ii) Poder dar permissões diferentes entre os usuários a esta central
administrativa;
iii) Ter recepcionista digital;
iv) Ter regras de encaminhamento de ligações;
v) Ter opção de push;
vi) Possuir ramais virtuais;
vii) Poder colocar um tempo máximo para atendimento – SLA;
viii) Fazer gravações das ligações;
ix) Ter um ambiente de teste;
x) Ter opção de criar várias filas;
xi) Ter configuração de horário de expediente e feriados;
xii) Inclusão de gravações para aviso de horário de funcionamento;
xiii) Ter uma pesquisa de satisfação automática dentro do próprio pabx;
xiv) Poder selecionar os agentes nas filas e ter um agente em várias filas;
xv) Ter opções de integração para uso de funcionalidade click to call;
xvi) Poder configurar o modo de distribuição das ligações:
(1) Fazer busca aleatória;
(2) Espera mais longa;
(3) Tempo de conversa mais curto;
(4) Tocar para quem atendeu menos;
(5) Tocar para todo mundo.
(6) Criar regras próprias
(7) Ter um log das atividades do servidor;
(8) Ter opções de integração e customização de captura de dados de
usuário por URA
(9) Ter a possibilidade de integrar serviços próprios em conjunto aos
serviços do próprio PABX local
3) Outras necessidades:
a) Ter serviço de apoio 24x7;
b) Ser possível integrá-lo com outras ferramentas, como o a ferramenta de software de
atendimento;
c) Ter uma base própria (AD) de clientes discantes, configuravel e expansível, de forma a
identificar os clientes discantes sem a necessidade de integrações externas.
3. PROPOSTA
A proposta deve ser apresentada em formato PDF, tendo no cabeçalho o logo do fornecedor,
no rodapé o endereço completo e telefone para contato. Além de possuir o conteúdo
detalhado abaixo.
3.1
ENTREGA DA PROPOSTA
A proposta deve ser entregue dentro de uma semana a partir do recebimento deste RFP. Ela
deverá ser enviada para o e-mail: [email protected].
3.2
ESCLARECIMENTOS
Qualquer dúvida ou esclarecimento deve ser enviado para o e-mail: [email protected].
As respostas serão encaminhadas a todos os fornecedores que participam da RFP de modo a
garantir transparência do processo e simetria da informação.
3.3
CUSTO DA PROPOSTA
O custo para formulação da proposta não poderá exceder o valor máximo de $ 40,00.
3.4
CONTEÚDO DA PROPOSTA
A proposta a ser enviada pelo fornecedor deve conter as seções abaixo na sequencia sugerida:
Seq.
1
2
Tópico
Sobre a Empresa
Infraestrutura
necessária
3
Escopo
4
Premissas
5
6
Estratégia de entrega
Cronograma
Conteúdo esperado
Breve descrição da empresa;
Detalhar toda infraestrutura como equipamentos,
licenciamento e qualquer recurso adicional necessário
para implantação e implementação do sistema na
Stone;
Qualquer informação que julgar relevante sobre Escopo
contemplado;
Premissas que serão necessárias para a execução do
serviço;
Detalhar a estratégia de como será entregue o serviço;
Detalhar o cronograma do projeto com suas atividades
e duração, preferencialmente em formato MPP;
7
8
9
Lista de recursos / Detalhar os recursos necessários para o projeto;
horas de alocação
Orçamento
Detalhar a forma de pagamento;
Informações
Incluir qualquer informação que julgar relevante que
adicionais
não se encaixa nos tópicos anteriores.
3.5
ORÇAMENTO
O orçamento deve ser entregue seguindo o modelo a seguir:
Orçamento
Objeto do orçamento: (Colocar o objeto do orçamento)
Orçamento elaborado por: (Colocar o nome do prestador de serviço)
Orçamento elaborado para: Stone Pagamentos S.A.
Data do orçamento: (Colocar a data em que o orçamento será entregue à Stone
Pagamentos S.A.)
Prazo de validade do orçamento: (Colocar a validade do orçamento)
Relação da prestação do serviço: (Colocar os itens que serão prestados)
Prazo de execução do serviço: (Colocar o cronograma de execução).
Condições de pagamento: (Colocar o valor da proposta e suas condições de
pagamento).
Cidade e data.
_______________________________________________
Assinatura do responsável
3.6
CRITÉRIOS DE SELEÇÃO
Os critérios de seleção e classificação serão definidos pela empresa contratante.
4. RESPONSABILIDADES, TERMOS E CONDIÇÕES
Confidencialidade
Para propósito deste Contrato será considerada informação confidencial toda e qualquer
informação escrita ou verbal ou por qualquer outro meio disponibilizada pelas PARTES que
tenha como objeto quaisquer estudos, projeções, análises, projetos, materiais, relatórios, bem
como toda e qualquer conclusão ou proposta a respeito desta proposta. Caso uma Informação
Confidencial seja incorporada ou refletida em outros documentos, tanto separada ou
conjuntamente gerada pelas partes, estes outros documentos deverão ser considerados como
Informação Confidencial sujeita aos termos deste Acordo.
Vínculo Empregatício
As partes não manterão qualquer vínculo empregatício com funcionários, gerentes e / ou
representantes uma das outras ou entre si, nem tampouco se estabelecerá entre elas qualquer
forma de vínculo societário, competindo, portanto, a cada uma delas, particularmente e com
exclusividade, o cumprimento de suas respectivas obrigações trabalhistas sociais e
previdenciárias, na forma de legislação em vigor.
São Paulo, 05 de julho de 2016.
STONE PAGAMENTOS S.A.
Request for Proposal
English Version
Summary
1
INTRODUCTION .............................................................................................. 3
1.1
1.2
2
PURPOSE OF THE RFP (REQUEST FOR PROPOSAL)........................................... 3
ABOUT STONE PAGAMENTOS S.A. ........................................................................ 3
DECLARATION OF WORK .............................................................................. 4
3.1 PROPOSAL’S DELIVERY ............................................................................................. 11
3.2 PROPOSAL’S ANALISYS ............................................................................................ 11
3.3 PROPOSAL’S ADJUSTMENTS .................................................................................. 11
3.4 CLARIFICATION ........................................................................................................... 11
3.5 PROPOSAL’S COST ..................................................................................................... 11
3.6 PROPOSAL’S CONTENT ............................................................................................ 11
3.7 PROPOSAL’S CONTENT ............................................................................................ 12
3.8 CRITERIONS OF SELECTION .............................................................................................. 13
4. RESPONSIBILITIES, TERMS AND CONDITIONS ...................................................................... 13
4.1 CRITERIONS OF SELECTION .............................................................................................. 13
1 INTRODUCTION
1.1
PURPOSE OF THE RFP (REQUEST FOR PROPOSAL)
The Stone Pagamentos S.A. Customer Relationship Team, would like to invite experienced
companies to propose us a customer relationship software that would work seamlessly
integrated to a PABX system that would provide a landline communications service.
This document aims at showing a guideline of the features that the said softwares must have
in order to achieve the needs of the company; the responsibilities of the chosen company and
our criteria of evaluation.
The proposal must provide:
1. A provider system features complete model.
2. A cost estimative.
3. A system implementation deadline.
1.2
ABOUT STONE PAGAMENTOS S.A.
Stone is an acquiring company, authorized by VISA and Mastercard to process and authorize
credit cards transactions of merchants within the Brazilian territory.
Its foundation took place in June 22, 2012, with the purpose of bringing change to the
acquiring market, with excellence in customer relationship as well as providing the best
technology and innovations available on the market.
One of its key values translates to “keeping our client as our life’s mission”. To achieve it, Stone
strives for the best services it can have. Therefore, it needs the tools that help it improve the
experience of the merchants.
2 DECLARATION OF WORK
You’ll find bellow all the details of the tasks we must be able to perform.
1. CRM APPLICATION
1. Application Type
a. Cloud-based application, SaaS.
2. Tickets
a. Characteristics
i. Identification number – a unique identification number must be
assigned to each ticket;
ii. Split – if needed be, tickets can be split in two.
iii. Merge – Assignee must be able to merge two tickets into one;
iv. Departments – departments creation inside the system so that the
whole company could use it;
v. Classification:
1. New – newly arrived by mail or created by an agent;
2. Open – Ticket awaiting resolution (counting only work hours);
3. Pending – awaiting answer by solicitor (doesn’t count work
hours);
4. On Hold – awaiting answer from internal teams (counting
only work hours);
5. Solved – we have concluded the requested task.
6. Closed – Ticket information can no longer be changed.
vi. Automatic Distribution – the system automatically assigns tickets to
agents according to logic rules.
vii. Current Agent Assigned – The person who answers the call gets
automatically assigned to a new ticket.
viii. Access to all the events of the ticket (changes in statuses and
information)
ix. Clear separation between internal and external observations.
x. Macros – actions performed with the selection of a certain option.
xi. Option of more than one ticket visualization at the same time.
xii. Exhibition of all the agents currently reading or editing the same
ticket
xiii. Tags.
xiv. Ticket access available only to agents of a certain group
(department).
b. Ticket Types:
i. Doubts/Questions;
ii. Requests/Tasks;
iii. Incidents;
iv. Problems;
c. Visualizations:
i. Creation of distinct visualization windows
ii. Parameters of logic conditions for filtering the tickets. (Ex: ||, &&)
iii. Assignment of a visualization window to a certain agent or group.
iv. Visualization filter options, by update, sla among others;
d. Users:
i.
ii.
iii.
iv.
v.
vi.
Distinct agent levels with distinct attributions;
Users groups (more than one group per user);
Final users;
Organizations with more than one user per organization option;
Organizations with information taken from our database;
Tags to users atribution.
e. Ticket Fields
f.
i. Unlimited tickets of types field creation
1. Checkbox;
2. Suspendend list;
3. Free text;
4. Numeric;
5. Customized ( Captures one entry that is verified according to
the regular expression defined by you);
Forms
i. Forms – Have distinct forms for the distinct groups;
ii. Distinct fields selection per form;
Conditional field choice.
g. SLA
i.
ii.
iii.
iv.
v.
vi.
vii.
viii.
First answer SLA;
Distinct SLAs attribution according to ticket’s field (subject);
SLA Attribution by contact channel;
SLA attribution by users group;
SLA by user attribution;
Definition of attendence hours;
Goals;
Logic conditions .
h. Ticket management
i. Mass actions – being able to make mass actions in several tickets
ii. Spam filter – having a spam filter to block unwanted messages;
iii. Words replacement – to replace words or numbers sequence that
weren’t supposed to be visible for the agent or being registered in
the helpdesk;
iv. Agrupamento de tickets – agrupar e desagrupar os tickets pelos
diferentes meios de entrada (E-mails, Chats, Calls, Facebook &
Twitter);
v. Ticket aggroupment;
vi. Automations;
vii. Triggers;
viii. Chat;
3.
4.
5.
6.
1. Integration – the chat must be integrated to the system,
without the need of being in more than one screen to talk to
the client;
2. Log creation – Every chat must create a ticket with all the chat
log;
ix. Phone
x. Integration – The phone calls must be integrated with the system
tool, creating a ticket every time a call is picked up; Facebook and
Twiitter
1. Integration - The tool must be integrated with the social
networks allowing us to answer posts using the system tool;
Knowledge basis
a. Have an internal and an external knowledge basis, filled with articles, forums
and feedbacks
Free search tool:
a. User, organization, tickets, tags and terms search inside the tickets
Contact channels:
a. Customized e-mail creation (Ex: “@portalstone.softwarename.com”)
Metrics:
a. BI software integration. (Ex: Gooddata, MS Power BI, BIME)
b. Native metrics
7. Plugins and apps and integrations:
a. Have a cloud integration with a PABX;
b. Possibility of migrating the Zendesk tickets to the new tool;
c. 3rd party apps integration.
d. Possibility of creating and integrating apps as company needs.
e. Software customization ( Ex: CSS editing)
8. Restriction:
a. Can’t be open source.
b. Have a White List (process that puts an administrative limit to the zendesk
while in sites outside the Stone, it would only be possible to access the
Zendesk while in the Stone network);
c. Have Custom SSL: process to make the Zendesk URL a Stone domain;
d. ISO 27.000 control
e. Have a Security Policy;
f. Have a Privacy Policy;
g. Have Credit Card Security
2. PABX
1) Technical items:
a) Use SIP protocol;
b) Have at least a 300 extension lines capacity;
c) Have at least a 100 simultaneous call capacity;
d) Be a virtual PABX;
e) Have a redundancy capacity;
f) Be able to make internal extension line calls;
g) Don’t be an open source;
h) Be able to transfer calls to external lines, such as our partners.
2) Functionalities:
a) Reports:
i)
Call logs with:
(1) The phone number that called;
(2) When did it call;
(3) Which number did it call;
(4) Call status;
(5) Outgoing calls legth;
(6) Incoming calls length;
(7) Outgoing and incoming calls total length;
(8) Calls average time;
(9) Amount of outgoing calls;
(10) Amount of incoming calls;
(11) Amount of outgoing non responsive calls;
(12) Outgoing and incoming calls total amount;
(13) Speaking time total length;
(14) SLA overdue total calls;
(15) How long does a call wait in line to be picked up;
(16) Kind of call – landline, mobile, long-distance, etc;
(17) Callback total amount;
(18) Call costs;
(19) Which agents did the call rang to.
ii) Agents:
(1) How many logged and unlogged agents;
(2) Speaking time total length;
(3) Incoming calls answered;
(4) Agent extension line number;
(5) Which agents are in which queue;
(6) Agents total logged time.
iii) Filters:
(1) types:
(a) by queues;
(b) by agents;
(c) by days;
(d) by hours;
(e) by month.
(2) Deliver periodicity:
(a) One time only;
(b) Daily;
(c) First day in the week;
(d) weekly.
iv) Exportation:
(1) Excel;
(2) PDF;
(3) CSV;
(4) Image.
b) Softphone:
i)
Have an individual client for the agents use;
ii) Have the extension line incoming call history;
iii) Have a presence button – the user can verify other users status on his own
screen;
iv) Logging in an logging out of the queue button, without the need of
changing screens;
v) Power Call – Calling a list of phone numbers without the need of dialing one
by one. Like an automatic dialer;
vi) Have an electronic phone book;
vii) Callback option;
viii) Transfer between internal extension lines;
ix) Supervised call transfer – the agent will be able to talk to another agent
before transferring the call, to make sure the other agent can take that call;
x) Assisted transfer – a call transfer in which 2 agents can talk to the client
simultaneously, increasing the client experience;
xi) Conference calls;
xii) Shortcut keys.
xiii) Schedule calls;
xiv) Be expandable, by plugins, outgoing calls or direct integration;
c) Switchboard – have an online switchboard that provides info screens:
i)
Be able to visualize every agent status;
ii) Be able to visualize how many agents are answering calls;
iii) Logging in/logging out option without the need of entering the admin central –
just being a queue admin;
iv) Be able to visualize how many calls are being answered;
v) Be able to visualize the users speaking time length that day;
vi) Wallboard with info about:
(1) How many calls at the queue;
(2) How many answered calls;
(3) How many abandoned calls;
(4) Total amount of calls (at that day);
(5) How many busy agents (on calls);
(6) How many callbacks;
(7) Average waiting time.
b) Admin Central:
i)
The service must allow different permissions to the users of the
administrative central;
ii) The service must provide a digital receptionist;
iii) The service must have rules to forward calls;
iv) The service must have push options;
v) The service must have virtual extension numbers;
vi) The service must allow us to put a maximum service time – SLA;
vii) The service must record calls;
viii) The service must have a test environment;
ix) The service must have the option to create lines of service;
x) The service must have the option to customize office hours and workdays;
xi) The service must allow the inclusion of recordings to inform our clients
about office hours and workdays;
xii) The service must have an automatic customer satisfaction survey inside the
pabx;
xiii) The service must allow the selection of agents in each line and allow an agent
in many lines;
xiv) The service must have integration that allow the use of click to call;
xv) The service must allow the customization of how phone calls are distributed
with functionalities such as:
(1) Random search;
(2) Longer waiting time;
(3) Shorter talking time;
(4) Making phone ring to the agent that answered fewer calls;
(5) Making phone ring to all agents;
(6) Creation of specific rules;
(7) Having a log of server’s activities;
(8) Having the option to integrate and customize user’s data capture by
URA;
(9) Having the possibility to integrate our specific services with local PABS’
services.
3) Other necessities:
a) Support 24x7;
b) Integration with other tools, such as the customer service’s software;
c)
The service must have its own base (AD) of customers calls that can be configured and
expanded, in a way to identify our customers without the need for external integration.
3. PROPOSAL
The proposal must be presented in a PDF file, including a heading containing the supplier’s
logo and footnote with address and contact number.
3.1
PROPOSAL’S DELIVERY
The proposal must be delivered until 13/07/2016. The proposal must be sent to the following
e-mail: [email protected].
3.2
PROPOSAL’S ANALISYS
The delivered proposal will be analyzed until no longer than 15/07/2016.
3.3
PROPOSAL’S ADJUSTMENTS
At 18/07/2016 will be held a conference call between the available companies and the Stone
staff to proceed with questions, adjustments and rectifications over the delivered
propositions.
3.4
CLARIFICATION
Any further questions or clarifications must be sent to the following e-mail: [email protected].
The answers will be forwarded to all the suppliers taking part of this RFP to guarantee the
transparency and symmetry of information of the process.
3.5
PROPOSAL’S COST
The proposal’s cost cannot exceed R$ 40,00.
3.6
PROPOSAL’S CONTENT
The proposal that will be sent by the supplier must contain all the sections showed below on
the suggested order:
Seq.
1
Topic
About the company
Expected content
Brief description of the company;
2
Necessary
infrastructure
Detailing of all the infrastructure needed for the system
such as equipments, licensing and any other additional
resource required for the introduction and
implementation at Stone;
Scope
Any other relevant information about the scope;
Premisses
Premisses needed for the execution of this work;
Premissas que serão necessárias para a execução do
serviço;
Delivery’s strategy
Details of how the service will be delivered;
Schedule
Details on the project’s schedule with all the activities
and duration, preferably in MPP format; Detalhar o
cronograma do projeto com suas atividades e duração,
preferencialmente em formato MPP;
List of
resources/ Detailing of all the resources needed for the project;
hours of allocation
Budget
Details on the payment methods;
Additional information Any other relevant information that does not fit on the
previous topics;
3
4
5
6
7
8
9
3.7
PROPOSAL’S CONTENT
The budget must be hand in according to the following model:
Object’s budget: (place the object’s budget)
Budget elaborated by: (place the name of the professional service
providers)
Budget’s date: (place the date which the budget will be hand in to Stone
Pagamentos S.A)
Expiration date of the budget: (place the expiration date of the budget)
List of the provision of the service: (place the items that will be provided)
Conditions of payment: (place the proposal value and it’s conditions of
payment)
City and date
_________________________
Supervisor’s signature
3.8
Criterions of selection
The criterions of selection and classification will be defined by the hiring
company.
4. Responsibilities, terms and conditions
The criterions of selection and classification will be defined by the hiring company.
4.1
Criterions of selection
Confidentiality
For purpose of this Contract will be considered confidential information all and any
information written or verbal or by any other means provided for the parties that possess as
object any studies, projections, analyses, projects, materials, reports, as well as every
conclusion or proposal regarding this proposal. In case any Confidential Information being
incorporated or reflected in others documents, either separated or jointly generated for the
parties, these and other documents must be considered as Confidential Information subject
to the terms of this Agreement.
Employment bond
The parties won’t maintain any employment bond with employees, managers and/or
representative of the other or between them, nor even will be stablished between them any
form of corporate bond, competing, so, by each of them, particularly and with exclusivity, the
implementation of its respective social labor and welfare obligations, in the form of current
legislation.
São Paulo, 05 de julho de 2016.
Stone Pagamentos S.A.