Perguntas que você deve fazer antes de implementar um chatbotA moda dos chatbots realmente engrenou há cerca de um ano atrás, quando a plataforma de mensagens mais usada lançou sua nova grande aposta: chatbots no Facebook Messenger Bruno Dalla Fina (*) No entanto, sua origem pode ser rastreada até a década de 60, com o surgimento do primeiro chatbot chamado Eliza e, além disso, já faz tempo que eles são utilizados no atendimento a clientes. Mas foi a partir desta divulgação do Facebook que realmente começaram a proliferar “robôs” na web, tanto assim que, de acordo com um relatório produzido em 2016 pela Imperva, mais de 50% do tráfego da Internet vem de bots e quase metade deles são “bots do mau”.
Os assistentes virtuais, também chamados chatbots ou bots, estão se tornando cada vez mais a plataforma escolhida pelas empresas para interagir com seus clientes. Os benefícios desta solução são impressionantes, principalmente porque com o uso da Inteligência Artificial não exigem recursos humanos em tempo integral, o que possibilita que as empresas automatizem grande parte do seu SAC, atendendo em tempo real e a qualquer hora do dia.
Mas também devemos destacar as desvantagens que são o resultado de uma má aplicação dessas tecnologias. O entusiasmo que apresentam as empresas ao inovar e economizar, obscurece as frustrações que aparecem num prazo muito curto, se as precauções necessárias não sejam tomadas antes da sua implementação. Os usuários inicialmente compartilham deste mesmo entusiasmo e começam a usar o chatbot, mas quando eles começam a receber spams ou efetivamente não conseguem obter a informação esperada, a diversão desaparece e em poucos segundos julgam negativamente todo serviço prestado pela empresa deixando uma marca digital indeletável.
O potencial destas soluções é indiscutível, mas é necessário aplicá-lo corretamente, especialmente quando as empresas planejam usar essas soluções no atendimento ao cliente, o setor mais interessado na sua implementação. Um chatbot deve ser usado de forma útil e deve ser transacional, ou seja, deve ter um papel eficaz para o usuário. Se um bot não é capaz de resolver, pelo menos, as consultas mais frequentes dos clientes e resolver sua necessidade em tempo real, não deixa de ser mais um mero “bot de comando”, um robô que responde a um esquema muito bem estruturado e delimitado de perguntas e respostas. A principal diferença entre estes bots de comando e os transacionais é que eles não usam a Inteligência Artificial no atendimento ao cliente, e sim algo próximo a uma árvore de decisão.
Há uma série de qualidades que um bot deve ter para realmente compreender as intenções dos clientes, mas isto requer um esforço inicial por parte da empresa em dar-lhe conhecimento, capacitar o assistente e integrá-lo com os seus sistemas e CRM. Só assim poderá se desfrutar dos benefícios e visualizar os resultados em uma maior satisfação e melhor experiência do cliente, além de uma economia nos custos operacionais e aumento nas vendas.
Para conter a ansiedade e não cair em frustração posteriormente, pois não estava claro que não estavam te oferecendo uma solução inteligente, antes de implementar um chatbot na sua empresa, faça a si próprio as seguintes perguntas:
1. Esta tecnologia é a que a minha empresa precisa?
2. O chatbot deste fornecedor é especializado em atendimento ao cliente?
3. Este provedor tem experiência na minha indústria? Que clientes do meu segmento ele atende?
4. Consigo visualizar casos efetivos e ativos?
5. Ele consegue disponibilizar uma demonstração personalizada funcional para a minha empresa?
6. Este chatbot tem estado de memória para manter um diálogo fluido, entendendo do contexto?
7. O bot aprende com os usuário e consegue evoluir?
8. Quais serão os recursos necessários e qual tempo de implementação?
9. Que relatórios terei ao meu dispor?
10. Conseguirei integrar o bot à outras soluções, como meus sistemas legados e tecnologias de terceiros?
Se o seu provedor não conseguir responder a tudo isso … Continue procurando! (*) É country manager da Aivo, empresa que propõe uma nova experiência de relacionamento com os clientes nos canais digitais. Google oferece treinamento gratuito para profissionais de tecnologia no BrasilEstão abertas as inscrições para participar do Google Cloud OnBoard, um treinamento para desenvolvedores, programadores e especialistas em TI sobre fundamentos das tecnologias do Google Cloud Platform (GCP). Com inscrições gratuitas, o treinamento presencial acontecerá em 2 de junho, no Allianz Parque, em São Paulo, e no DevCamp, em Campinas, além de contar com transmissão ao vivo em salas de cinema de seis cidades no Brasil: Belo Horizonte, Rio de Janeiro, Curitiba, Porto Alegre, Recife e Salvador.
Com participação dos principais especialistas em Cloud do Google e demonstrações das ferramentas de GCP, o dia de treinamento será dividido em sete módulos focados nas tecnologias e soluções de nuvem do Google, como Google App Engine, Datastore, Storage, Container Engine, Compute Engine e Network, Big Data e Machine Learning.
O módulo de encerramento trará dicas de como os participantes poderão alavancar suas carreiras usando os conhecimentos adquiridos. Os participantes também terão a oportunidade de realizar networking com os Googlers e especialistas presentes e receberão certificado de participação do treinamento.
As vagas são limitadas e as inscrições podem ser feitas até um dia antes do evento em https://goo.gl/2blcTm. O OnBoard foi criado para desenvolvedores, gerentes de TI, analistas de sistemas, engenheiros de software e arquitetos de soluções que buscam explorar soluções de Cloud. Também podem participar executivos de tecnologia e de áreas de negócios que querem entender o potencial do Google Cloud Platform. Google Cloud OnBoard
Quando: 02 de junho, sexta-feira
Quanto: Gratuito
Inscrições e mais informações em: https://goo.gl/2blcTm
| Como construir networking quando se é muito introvertidoExistem infinitos ditados sobre como tudo é questão de ter os relacionamentos certos para alcançar o sucesso. Olha, realmente precisa dos contatos adequados, mas desenvolver relacionamentos é um jogo que você pode dominar e servirá para qualquer coisa que deseja fazer na vida. Mas daí muita gente questiona, “Mas Rafa, sou muito introvertido e tenho dificuldade de começar a montar um networking. O que eu faço?”.
Realmente vivemos em um mundo que está cada dia mais competitivo e no qual muitas vezes os introvertidos são engolidos por colegas com menos habilidade técnica, mas mais inteligência emocional. O carisma e a capacidade de engajar pessoas são até mais importantes que a sua formação técnica, então, se você é introvertido, precisa trabalhar a si mesmo.
Encontre soluções, formas de se relacionar, momentos do dia em que é mais fácil se aproximar das pessoas, e principalmente perca o medo de errar. Não tem problema se suas abordagens de início forem catastróficas, mas você precisa tentar. Busque terapia, coaching, pratique com membros da família, vá até para cursos de teatro, mas invista em você, em entender como pode superar a sua introversão e, simultaneamente, respeitar a si mesmo.
Para ajudar separei seis dicas que mostram como construir um networking quando se é muito introvertido, confira.
1. A única coisa que pode matar a sua capacidade de networking é a arrogância ou atitudes que fazem com que as pessoas se desconectem de você. Manter a humildade e o espírito de ajudar o próximo no final das contas ajuda a si mesmo.
2. Trabalhe suas habilidades interpessoais. É como trabalhar em uma tese, ou treinar para uma corrida: você precisa se dedicar a isso conscientemente, ler sobre o tema, praticar em momentos que não vale dinheiro ou promoção.
3. Faça as pazes com a sua necessidade de trabalhar sua habilidade de socialização admitindo, primeiro, que ela precisa ser trabalhada, e depois buscando especialistas, leituras e práticas que o ajudem. Fazer-se gostado é uma técnica que você aprende.
4. Se você for ignorado ou odiado, o mundo não acaba, é só sinal de falta de treino. E, em geral, se você tiver interesse genuíno pelas pessoas, vai conseguir aos poucos se soltar para conversar melhor com elas, para entende-las e marcar presença.
5. A nossa escuridão, os momentos difíceis, existem exatamente para conseguirmos enxergar as oportunidades. Instigue sua dificuldade ao máximo, trabalhe aquilo que dentro de você é mais difícil, porque dali saem grandes presentes.
6. Ao apresentar um negócio para um investidor ou um possível mentor o modo de falar e de se relacionar é mais interessante que a sua ideia em si. A motivação, a resiliência para insistir no negócio e integridade é muitas vezes um diferencial (Fonte: Rafa Prado é consultor e movimentou mais de R$ 20 milhões com a criação de produtos digitais, eventos e imersões no exterior com personalidades e alto empresariado. É autor do livro “100 Graus – O ponto de ebulição do sucesso”). Dispersão definida por softwarePatrick Hubbard (*) Não se iluda, a abstração é algo bom. E a abstração com APIs avançadas é excelente A abstração do software dá suporte à meta de toda mecanização de reduzir o trabalho humano e estimular a criatividade dos engenheiros. Mas esse mesmo recurso sempre traz consigo um aspecto negativo raramente aparente nos primeiros estágios da administração: a dispersão.
A virtualização eliminou em grande medida as barreiras à geração descontrolada de novos servidores e agora devemos desbastar periodicamente nossos clusters, a menos que queiramos enfrentar alertas de recursos não provisionáveis. Flash e armazenamento híbrido são excelentes ativos em nossa eterna busca por mais IOPS, mas um design de pool indisciplinado não contribui para a eficácia do data center. E por que esperaríamos que sistemas como redes definidas por software (SDN), virtualização de funções de rede (NFV), plataforma como serviço (PaaS) no local, sistemas hiperconvergentes etc. tivessem algum tipo de imunidade? Eles não têm, e dar conta da dispersão definida por software tornou-se mais uma das nossas tarefas.
A era das infinitas redes
Talvez você tenha monitorado os caminhos do tráfego pelas redes de um provedor de SaaS e notado que alterações na rota do tráfego acontecem a cada dia ou até a cada hora. E isso faz sentido. Essas operadoras têm recursos de desenvolvimento consideráveis e há muito tempo desenvolveram abordagens proprietárias ao SDN. Seus serviços são distribuídos geograficamente entre diferentes fusos horários e se adaptam dinamicamente à demanda usando uma combinação de abstração e atuação por software. Isso permite que elas façam alterações em configurações mais rapidamente e com maior precisão do que qualquer equipe humana poderia.
Mas agora com o SDN e o armazenamento definido por software (SDS), entre outros elementos em seu data center, o roteamento, as políticas de segurança, a otimização da entrega de aplicativos e a arquitetura de armazenamento podem ser igualmente dinâmicos. No passado, você mantinha sua rede racionalizada em função de alguns vínculos avançados que geralmente não apresentavam problemas. Se possível, você pode seguir o exemplo das grandes operadoras e gerenciar as redes intricadas de diversas bases com apenas um clique.
Só tem uma pegadinha. Como isso é algo fácil, é provável que os recursos acabem órfãos, duplicados, excessivamente provisionados ou simplesmente perdidos. Caso você tenha monitorado NetFlow, logs de fluxos VPC do AWS ou perfilagem de agentes OMS do Microsoft Azure no local, talvez já tenha notado uma pequena porcentagem do tráfego “vazando” além das rotas esperadas. No caso de redes configuradas manualmente, com frequência isso é rastreado até vínculos de internet/VPN locais de filiais, rotas de failover ativas quando deveriam ficar em espera, configurações indevidas de BGP CDIR ou políticas de firewall aleatórias.
Se o número de vínculos for relativamente estático e pequeno o suficiente para manter uma imagem mental completa, a correção poderá ser simples. Mas se sua estrutura de SDN está funcionando como deve, o VMware vRealize está invadindo os domínios do NSX ou o SCVMM está embaralhando os contratos de ACI. Os controladores modificam o acesso à rede, bem como permissões, endereços e rotas regularmente sem a sua supervisão. O que também significa que, em sua maior parte, as alterações estão acontecendo fora do alcance da visão.
O SDS costuma estar ainda mais sujeito à dispersão. Idealmente, políticas bem ajustadas remanejam cargas de trabalho de armazenamento para obter máximo desempenho ao mesmo tempo que minimizam a utilização de recursos. Controladores híbridos otimizam arquivos individuais de volumes, atribuindo-os a diferentes mídias físicas com base na análise de uso. Mas, diferentemente de uma interrupção, um pecado ocasionalmente perdoável das redes, uma falha de armazenamento (perda de dados) é algo grave. O resultado é uma tendência a criar políticas conservadoras que, quando em dúvida, optam por deixar os arquivos onde estão para serem limpos posteriormente. A dispersão do armazenamento é um subproduto mais seguro quando se deixa que as políticas sejam executadas de forma autônoma.
Dispersão como serviço
A dispersão da infraestrutura definida por software piora quando é composta. Na verdade, os orquestradores com controle de redes, armazenamento e outros recursos no local são o menor dos problemas. Um script de controlador de nível superior que, por sua vez, invoca APIs em sistemas de virtualização herdados pode gerar VMs, pools e vMACs sem se preocupar com o consumo de recursos. Pelo menos, os engenheiros no local ainda mantêm o total controle administrativo, ainda sendo possível monitorar manualmente a dispersão com as ferramentas existentes, embora isso seja uma tarefa tediosa.
A TI híbrida e a nuvem, por outro lado, costumam elevar a dispersão a um novo patamar. Qualquer gerente de TI que já tenha sido surpreendido por uma fatura de serviços que poderia potencialmente limitar sua carreira pode prestar testemunho do lado negro da dispersão definida por software. A criação de relatórios ou até mesmo a descoberta para determinar como eliminar instâncias ociosas ou órfãs pode ser uma tarefa difícil. “O processo analítico mensal da equipe de finanças é executado em i-5of78b0zg9vps9fro? Ou seria em i-09eomj1mnex8ex6yi? Ah, espere. Esse é do RH. Finanças está em i-299rjpen9ruwahzuo. Eu acho.”
O problema é quando os administradores se precipitam para aproveitar os incríveis recursos da infraestrutura definida por software, sem ter experiência com rastreamento distribuído/delegado de transações e registro em log de ações de configurações, entre outras habilidades. Se uma organização adota o DevOps com DEV maiúsculo, isso já traz algum alívio. Ferramentas de integração/compilação/entrega contínuas facilitam a garantia da rastreabilidade pelas camadas de abstração, mas o simples uso do Chef ou do Puppet não basta.
O que você pode fazer
• Documentar – Sim, a tarefa tão temida. Primeiro, admita que você não gosta de documentar, reconheça que ninguém gosta e, então, documente ainda assim. Os sistemas que gerenciam pontos de controle individuais realizam um excelente trabalho de organização dos elementos em seu campo de ação. No entanto, são péssimos para a visualização dos relacionamentos de ponta a ponta que passam por várias camadas do sistema. Passe algum tempo no Visio, faça diagramas de sua arquitetura integrada de sistemas SDx e, em seguida, imprima-os em pôsteres. As conversas sobre solução de problemas serão mais eficientes e a gerência sentirá que você tem tudo sob controle.
• Relatórios, não apenas alertas – O gerenciamento responsivo da TI demanda a definição de alertas inteligentes que acelerem a recuperação. O gerenciamento proativo da TI depende de relatórios úteis que mantém você à frente dos problemas. Leia os manuais de seus sistemas de monitoramento e gerenciamento e crie relatórios que identifiquem a exaustão da capacidade, destaquem áreas operacionais sujeitas a erros etc. Se puder incluir relatórios de custos detalhados regulares, especialmente para TI híbrida e nuvem, melhor ainda.
• Aplicar o DevOps a tudo – Se você não puder afirmar com algum grau de confiança que poderia, neste exato momento, recriar 75% de seus sistemas gerenciados por SDN de maneira programática, pare de ler agora mesmo e descubra como chegar lá. Confira os artefatos de configuração no controle de origem e verifique se todos sabem como gerenciá-los. Leia The Phoenix Project. Pelo menos experimente um pouco de Agile. A dificuldade é apenas no começo e você não precisa adotá-lo integralmente. Imagine quantas noites e finais de semana você poderia recuperar se fizesse a maior parte de suas alterações à produção, ou talvez até todas elas, durante o horário de expediente. Isso é realmente possível! E você ainda pode contar com uma estrutura de alterações mais precisa e resistente à dispersão.
Déjà-vu, tudo outra vez
Embora seja importuno quando a dispersão surge em outra área da TI, é possível mantê-la sob controle. Na verdade, podemos ajustar a infraestrutura definida por software utilizando quase a mesma abordagem usada para dispersão de aplicativos ou de virtualização, além de algumas novas ferramentas. Além disso, esse é um problema transicional, já que a TI sai da linha de comando pelo SDx de primeira geração para a infraestrutura PaaS. O PaaS inclui inteligência e uma forte integração que gerencia recursos com ferramentas avançadas a fim de minimizar a dispersão. Logicamente, talvez isso não ajude muito no caso da dispersão de contêineres e tecnologias sem servidores, mas esses são outros quinhentos. (*) É gerente técnico da SolarWinds |
