Vivocha Tech Blog

We are happy to announce the new version of the Vivocha BOT SDK, v3.0

The BOT SDK allows to quickly write chatbots that integrates directly with the Vivocha platform, providing a rich set of messages, including quick replies, templates, and multimedia.

The Vivocha platform provides an out-of-the-box native support for chatbots developed using Google Dialogflow, IBM Watson Assistant, Microsoft Bot Framework v3 and v4 platforms, and the SDK contains classes and facilities to really speed up the development of bots using Wit.ai NLP.

Through the BOT SDK it is possible to integrate virtually any existing Bot Platform out there with Vivocha.  

Among some other improvements, the BOT SDK version 3.0 sports the following new features:

- Asynchronous messages: in some cases involving time-consuming, long responses from a bot, it is needed to send back a message to the chat users as soon as they’re available, following an asynchronous model; now it is very easy to do that.

- Attachments: starting from this version of the SDK, chatbots developed with it can receive and send attachments and files from/to chat users with easy, both sending public available URLs or optionally serving them from the Vivocha secure storage.

The BOT SDK v.3.0 and its complete documentation are available from here.

We are really proud and happy to announce the new Vivocha 6!

It's been a long year of study, research, and development. A lot of work has been done by our team: among a lot of new features, we would like to highlight the brand new Campaign Builder which is the results of the experience gained over the years in the business and our customers' suggestions.

Moreover, our codebase has been substantially rewritten and optimized, and we’ve re-designed the Vivocha product into a microservice architecture model, introducing a new server architecture based on containers.

In terms of advantages this new architecture grants an higher scalability and, at the same time, it allows us to be more independent from the cloud provider.

Through a bird’s-eye view, here is a list of the main features of the Vivocha 6 release:

the shiny Campaign Builder (a.k.a. the new foundry): a brand new tool that allows administrators to define in a simple way a set of strategies and rules whose ultimate purpose is to let a group of agents provide support by a variety of different channels;

multi-channel, multi-language and multi-media campaigns: web, mobile, Facebook, SMS, telephony;

new web widgets;

new mobile SDK for themeable mobile native apps;

recontact options;

New proactive engine, now also including rules based on variables;

library component: to define, collect and reuse custom variables, data collections, and surveys;

new developer tools, including offline Widget development, import/export of custom Widgets and management of translation strings;

new Engagement Widgets and Interaction App;

chatbots integration: seamless bots integration as virtual agents, with out-of-the-box support for IBM Watson Assistant, Dialogflow and a Bot SDK to create Wit.ai NLP based bots or to write new platform-agnostic bots from scratch;

new messages format, now including quick replies and generic, rich templates, with images, carousels and custom buttons.

And many other features!

For a complete list of new features please read the Vivocha 6.0 Release Notes.

Thank you! 🤩

Nowadays, building conversational chatbots involves composing software applications able to understand natural-language inputs, and following a pre-defined decisional “script” in order to properly interact with customers and chat users simulating a real human conversation. AI and Machine Learning algorithms are used, under the hood, to instruct and train chatbot systems and to improve their ability to understand what humans are saying or asking for in several application domains.

Among a myriad of existing platforms with the aim to simplify building new chatbots, we focused our tests on two well-known general purpose systems: API.ai, backed by Google and IBM Watson Conversation services.

This document provides a brief comparison between the two platforms, highlighting the main features and aspects we think matters to effectively build and maintain conversational chatbots.

Main Concepts

Web platforms like API.ai and Watson Conversation work around the concepts of Intents and Entities.

Intents represent chat users’ intents and basically are a mapping between what humans are saying and which actions the system should take to properly respond to them. Example of intents can be: “order a pizza”, “Assistance required”, “book a flight”.

Fig.1: Intents definition in API.ai (top) and Watson Conversation (bottom).

Entities are a representation of domain-related classes, data-types and objects and are used to take specific actions by recognizing them in users’ chat inputs.

Fig. 2: Entities definition in API.ai (top) and Watson Conversation (bottom).

Examples of entities are Pizza-type, Issue-Types, Hardware components, numbers, phone numbers, etc…

Usually, chatbots systems are instructed and trained by example, providing common conversational statements to associate to defined intents and entities. Some systems provide also an embedded sentences annotator to disambiguate concepts inside users’ inputs in order to refine the chatbot understanding capabilities.

Thanks to Intents, it is possible to create Dialogs, which are conversation workflows related to the application domain and that model all the possible human-bot conversational interactions.

Fig. 3: Dialog editor in API.ai (top, with slot filling) and Watson Conversation (bottom).

API.ai vs IBM Watson Conversation

This section provides a brief comparison between the two explored and tested chatbot systems, including some notes.

Conclusions

Chatbots and related technology are becoming more and more relevant to build automatic interactive support systems. Several existing platforms provide a set of powerful tools to model human-bot conversational interactions without writing (a lot of) code. Two of them are becoming quite interesting: API.ai, backed by Google and IBM Watson Conversation. This short report shapes a brief comparison between the two. In our opinion, where API.ai shines for the impressive set of tools (like the embedded annotation system, integration hooks, and so on…), Watson Conversation has impressed us for the under the hood automatic process of understanding user inputs and training and for dialogs flow editor.

Programming goes beyond the super-nerd concept of “writing code for a machine”.

Yes, it’s the hard truth but, today, writing code is also a social display of respect.

Respect for you as developer, respect for your team.

Quoting this interesting post:

“Write code for your later self and for your co-workers in the first place - not for the machine”  - @RisingStack

Writing one-line, chained statements full of language (and unreadable) tricks quickly becomes no more than a vain practice, when reiterated.

Thus, in case of medium and large codebases, adopting a shared code styling actually becomes mandatory. Enabling all the developers in your team to be able to read the code each other developer writes is another safe practice (referring to the Modern Agile’s “Make Safety a Prerequisite” concept).

Using in your development workflow a linter plus a shared code style (enforced by automatic rules) helps in making your code more safe, less error-prone and more readable by developers.

Some examples of what a linter + code styling can enforce are: avoiding variables usage before their declarations, avoiding not used variables, avoiding suspicious or not guarded for loops, avoiding to long lines, avoiding missing semicolons, and so on…

Talking about JavaScript, ESLint is a very nice pluggable linting utility for that programming language.

Configuring and using ESLint allows developers to check their code before execution, at writing-time. ESLint, thanks to its extendible set of common rules, makes the work for you. It can be used as a command-line tool and becomes really useful when plugged in your preferred IDE, which visually remarks all the issues related to linting your code.

For example, in the following picture we can see Visual Studio Code IDE showing some issues about our code, in particular: suggesting to use const instead of var and rising a code style exception in using spaces inside parens.

The other aspect is Code Styling. Code styling refers to code conventions and how to write it. For example: using semicolons or not, naming conventions for variables and functions (camel-case or Pascal-case?), named function expressions instead of function declarations, code lines length, how many spaces in tabs and so on…

A nice (and very used) code styling is the one adopted and published by AirBnB team, have fun exploring it!

The cool thing is that they provide a set of plugins for ESLint in order to use them in your code, simply configuring the latter.

In a very pragmatic way, starting using ESLint + AirBnB Code Style in a Node.js project means:

1.  Installing ESLint and AirBnB plugins as dev dependencies:

"devDependencies": { ... "eslint": "^3.19.0", "eslint-config-airbnb-base": "^11.1.3", "eslint-plugin-import": "^2.2.0", "eslint-plugin-mocha": "^4.9.0", ... },

2.  creating the .eslintrc.json ESLint configuration file in your project root directory (your IDE will use it)

A possible configuration (we are using) can be the following:

{ "extends": "airbnb-base", "plugins": [ "import", "mocha"], "rules": { "no-console": "off", "no-restricted-syntax": "off", "no-shadow": ["error", { "allow": ["done", "resolve", "reject", "done", "cb", "callback", "err", "req", "res"] }], "mocha/no-exclusive-tests": "error" } }

As depicted in the previous snippet, we overrode some rules. For example there we are telling ESLint to allow the JS console usage, to allow variables shadowing only for done, resolve, reject, cb, etc…

We’re also using the mocha plugin in order to instruct ESLint about allowing particular functions like describe(), it(), and so on...

Among other issues, using the linter we quickly:

discovered a lot of language tricks (i.e. !!, Boolean(), …);

discovered a lot of not-required statements and conditional checking;

discovered a lot of undeclared variables;

improved code readability;

Avoided verbose syntactic sugar;

Discovered a lot of missing or unnecessary semicolons;

...and lot of other things!

In this post we remarked the power of a code style adoption:  to catch bugs at writing time and to converge on a shared code styling in the development team, allowing people to write more readable code, simplifying collaboration and codebase maintenance. 

In the previous posts we wrote about Testing the APIs, E2E Testing and Code Coverage. We wrote about why they are relevant and why they plays a central role in a serious software development cycle, helping developers to discover bugs early and to deliver high quality code.

In this post we briefly explain how to complete and to automate the development cycle adopting a Continuous Integration flow, and we provide a brief list of tools we are using to do that.

Thus, about Continuous Integration... from Wikipedia:

In software engineering, continuous integration (CI) is the practice of merging all developer working copies to a shared mainline several times a day.

[…]

Continuous integration involves integrating early and often, so as to avoid the pitfalls of "integration hell". The practice aims to reduce rework and thus reduce cost and time. A complementary practice to CI is that before submitting work, each programmer must do a complete build and run (and pass) all unit tests. Integration tests are usually run automatically on a CI server when it detects a new commit.

From our point-of-view, a feasible software development cycle, which includes the Continuous Integration practice, can be represented as in the next figure.

Briefly:

during Fast Development Cycle (FDC), each developer works on his/her copy of the code base in fast iterations: writes code and tests, runs tests locally and checks Code Coverage, then iterates.

At the end of each significative reached result in FDC, developers Commit changes and push code to the shared repository.

The latter event triggers the Continuous Integration (CI) tool, which: checkouts the updated code from repository, builds it and runs all the tests; if all tests passed and Code Coverage thresholds are fulfilled then it increases the version of the code using Semantic Versioning. Finally, depending on the adopted company’s software delivery strategy, the CI tool can also make a new release, publish or deploy it to production servers.

In this way, the code is always updated, built, tested and merged in a consistent way, all the written integration tests are run over and over again at the end of each Fast Development Cycle.

Tools

Some tools we are using in Node.js-based flows at Vivocha Labs, include:

Istanbul/nyc: code coverage tool;

husky: git hooks, prevent bad commits and pushes. Executes pre-commit and pre-push tasks;

commitizen: commiting with commitizen, prompts you to fill out any required commit info fields at commit time, like commit type (new feature, bug fix, refactoring, etc…), description of the commit and so on...

semantic-release: automates node packages publishing to NPM, setting a version related to the git commit type and strictly following the SemVer specification. After every successful Continuous Integration build of your branch, it publish the new version for you to the repos.

Travis CI: continuous integration service, free for opensource projects. Triggered by a git push in a repository, it executes builds/testing retrieving code from a git repository and running tasks configured in your .travis.yml configuration file. You configure Travis with GitHub and NPM access tokens to allow it to publish and release new versions of your code to the repositories, through semantic-release tool.

Coveralls: Code coverage reporting service; it shows which parts of your code aren’t covered by your test suite. Also, it produces reports like nyc does, but they can be read online through Coveralls website in a nice layout.

Configuring the project

For a Node.js project, in addition to (obviously) installing all the dev dependencies for the modules mentioned above, the package.json scripts section could be configured as follows:

"scripts": { "test": "./node_modules/.bin/mocha -t 20000", "cover": "./node_modules/.bin/nyc --reporter=lcov --reporter=text npm test", "check-coverage": "./node_modules/.bin/nyc check-coverage --statements 100 --branches 100 --functions 100 --lines 100", "precommit": "npm run cover && npm run check-coverage", "commit": "./node_modules/.bin/git-cz", "semantic-release": "semantic-release pre && npm publish && semantic-release post", "report-coverage": "cat ./coverage/lcov.info | ./node_modules/coveralls/bin/coveralls.js" }

This configuration enables performing Fast Development Cycles + Commit activities, through the following steps:

Write Code & Tests;

npm run precommit;

If OK, git add files;

npm run commit;

git push.

The git push command triggers a build event on the configured Travis CI repository, which runs our tasks as configured in the project .travis.yml file. A .travis.yml configuration can be written as follows:

language: node_js cache: directories: - node_modules branches: only: - master notifications: email: false node_js: - '7' before_script: - npm prune script: - npm run cover - npm run check-coverage after_success: - npm run report-coverage - npm run semantic-release

This configuration drives the following , automatic, CI process:

Run all Tests and do Code Coverage; 

Check Code Coverage against the defined thresholds

If successful: 

Send Code Coverage results to Coveralls

Publish the new version of the software in the NPM registry

Create a new release in the git repository.

End-to-End (E2E) testing is another relevant Black-Box testing strategy, where an automatic test is used to drive a browser in order to test your Web app, emulating real users interactions throughout your web pages / application.

Simplifying… E2E testing can be used to discover bugs using your Web front-end like a real person is actually using it. This type of E2E testing allows to write tests like the following (expressed in natural language):

Open Chrome browser and navigate to https://mysuperwebapp.example.com

Click login

Fill username and password fields

Submit the form

Assert that the user is logged in and that its personal workspace page loads and content is shown

Assert that the page header includes and shows a clickable logout button.

Or simulate and test the typical chat application, like:

Open Firefox and login as Bob

Open Chrome and login as Alice

Bob clicks the button to start a chat with Alice, he writes “hello” and clicks “send” button

Assert that Chrome browser is showing a “New Message” notification popup to Alice

Alice clicks on the notification, writes “hey!” and pushes the “send” button

Assert that Firefox is showing the “hey!” Message on the Bob’s chat page element.

Several tools can be used to automate your browsers, among them Selenium is one of the most used.

In particular, Selenium 2 is a server app that implements and exposes the W3C Webdriver specification API , which provides a uniform API to remotely instruct the behaviour of web browsers. Selenium is able to receive Webdriver commands to automate browser activities using their specific drivers.

Then, if you are writing tests in Node.js, you can use frameworks like Webdriver.io, Nightwatch.js or WebdriverJs to write your E2E tests using Selenium under the hood.

The following picture shows how this workflow looks like:

Currently we are using Webdriver.io framework as Node.js bindings for Selenium, and it is amazing. Webdriver.io exposes a rich set of APIs, including starting multiple browser instances and a seamless integration with W3C Webdriver API, Selenium, Mocha, Chai and Should. Moreover, Webdriver.io provides CSS and XPath Selectors to select and check DOM elements in an easy way.

Some basic steps are required to start E2E testing with Node.js: download and install Selenium standalone server (it requires Java RE), download the drivers for each browser we need to use, install Webdriver.io, write tests, launch Selenium server, run your Node.js tests…

But, here is how to simplify this flow ;)

1) Install Webdriver.io

npm i webdriverio

2) Install this cool Node.js package: selenium-standalone

npm i selenium-standalone

This latter package allows to download, install, configure and programmatically run (but not only) the Selenium Server and all the required browser drivers. Well done!

3) Write tests and run them, with Mocha (for example)

The following code snippet shows how to configure and run Selenium before each test suite suing Mocha:

const driversConf = { chrome: { version: '2.28', arch: process.arch, baseURL: 'https://chromedriver.storage.googleapis.com' }, firefox: { version: '0.15.0', arch: process.arch, baseURL: 'https://github.com/mozilla/geckodriver/releases/download' } }; before(function (done) { selenium.install({ version: '3.3.1', baseURL: 'https://selenium-release.storage.googleapis.com', drivers: driversConf }, function (err) { err ? console.log('Error installing: ', err) : console.log('Installation OK.'); selenium.start({ version: "3.3.1" , drivers: driversConf}, (err, child) => { if (err) console.log('Error in start: ', err); console.log('Starting Selenium Server...'); serverProcess = child; console.log('Selenium running, pid: ', child.pid); done(); }); }); });

While, here is a test case, written using Webdriver.io API.

The test case initialises two browsers (Chrome and Firefox) and opens them at two app URLs, do a login and tests a basic chat interaction.

Please note that thanks to the latest Node.js version (v. 7.8.0, at time of writing) we can benefit of the new cool async/await JavaScript feature.

describe('Launching two browsers to start a chat', function () { it('should init the chat...', async function () { browser = webdriverio.multiremote({ agentBrowser: { desiredCapabilities: { browserName: 'chrome' } }, customerBrowser: { desiredCapabilities: { browserName: 'firefox' } } }); const agentBrowser = browser.select('agentBrowser').init(); const customerBrowser = browser.select('customerBrowser').init(); await Promise.all([ agentBrowser .url('https://mysuperwebapp.amazingchat.co/login') .setValue('#userid', 'antonio') .setValue('#passwd', 'aNiceSecret') .submitForm('form[name="login"]'), customerBrowser.url('https://anotherwebappchat.amazingchat.co/start) .waitForExist('.chat_widget', 20000) ]); await customerBrowser.click('.chat_label') .waitForVisible('.chat_button', 5000) .click('.chat_button') .pause(2000); await agentBrowser .waitForExist('.newChat', 20000) .click('.newChat') .waitForExist('textarea.chat', 20000) .element('textarea.chat').setValue('Hi, I\'m Antonio, how are you?') .keys('Enter') .pause(1000); await customerBrowser .waitForVisible('#chatTextarea', 20000) .element('#chatTextarea') .setValue('Hello, thanks for asking, it\'s ok.') .keys('Enter') .pause(7000); return; }) });

Launching the test like a generic Mocha suite, we can actually see two browsers opening, navigating and doing click/write/chat actions. Then, using an assert or BDD-style testing framework (like Chai / Should) it is possible to write all the required checks on application / page status and elements.

In a recent post we wrote about how we are testing our APIs in Vivocha.

API Black-Box testing is only one of the strategies we are using in our developing cycle to ensure software quality and robustness in our products.

This post explores how we go deeply in (White-Box) testing our code and how much we cover it with tests: Code Coverage is a measure of that.

From Wikipedia: 

“Code Coverage is a measure used to describe the degree to which the source code of a program is executed when a particular test suite”

Moreover, Code Coverage it’s very useful in order to have a measure of how lines, statements, functions and branches in our code are executed while the automated tests are running.

We use Code Coverage to constantly know how we are testing the components of our products, libraries and single modules.

Adopting Code Coverage, a basic development iterative workflow can be summarised by the following cycle:

Write small pieces of code, or start writing tests, first ;)

Write tests for every single piece of the written code

Run a Code Coverage tool to measure testing effectiveness and to have a report about it

Improve code & testing

Repeat the loop, striving to reach 100% coverage.

When using Node.js we’ve chosen the following tools for Code Covering tasks:

Mocha and Chai / Should to write test suites and cases;

Istanbul / nyc to instrument our code base with line counters, to have a measure about how tests cover and “exercise” our code;

nyc natively supports several popular testing frameworks for JavaScript, among them: Mocha.

To start with Code Coverage, read here how to install and include nyc in your Node.js project.

Then, the scripts section of the package.json file can be configured as follows:

"test": "mocha", "cover": "nyc --reporter=lcov --reporter=text npm test"

As you can see, nyc here is configured to run all the tests (using Mocha) and to build a text report in LCOV format. In a future post we will see how to use this format in order to include Code Coverage in a complete Continuous Integration flow.

Just as an example, the following report is generated by nyc, running the npm run cover command in one of the development cycles of API-Piki, a simple API tests generator tool we developed:

This report tells us that we 100% covered with tests all the source code statements in the library but some code branches are not.

Istanbul / nyc also generates an html report, very useful to navigate through the source code to see how this code base is covered by tests and what’s missing.

The following picture shows the html report for a 100% covered code snippet of API-Piki:

While the following picture shows portions of code with a not covered statement and not covered branch (marked in red and yellow).

Designing a good API for your service/product is a love affair. It’s the beginning of a love story with the developers that are going to use your service endpoints.

Designing a good API for happy developers should follow a set of well-known best practices, but there is also a “dark side of the moon” aspect: that invisible, hidden, mysterious iterative art of testing. Writing good and exhaustive tests, covering all the available API endpoints it’s a love affair, too.

While developing the Vivocha API v2, we started to write a growing set of tests. Not only unit tests but also doing black-box and integration testing, in order to ensure quality, robustness and predictable behaviours of the exposed endpoints. Last but not least, building a trusted and always-updated set of tests allows to face new developments and changes in the API codebase with less risk and… headaches.

To write black-box, integration, and consequently regression tests, we’ve chosen Node.js and a bunch of JavaScript testing frameworks. This post briefly summarise them.

As general testing framework we are using Mocha.

Thanks to its intuitive (and pleasant) syntax,  Mocha allows us to write asynchronous and synchronous test suites and single test cases for each API endpoint, independently of the chosen assertion-language/style (read more below…).

As convention, usually we collect all tests related to a particular endpoint in a single file, under a test directory.

Thus, for example, a Mocha test suite for our Application API endpoint is contained in a test/testApplicationAPI.js file, structured as follows:

… before(function(done){ … }); //run common auth tests common.testAuthentication(URL, 'get', '/applications', username, userpasswd); common.testNotValidIds(URL, 'get', '/applications', {}, username, userpasswd); describe('GET /applications', function(){ it('with valid auth, should be OK and respond with a JSON', function(done){ … }); }); describe('GET /applications', function(){ it(’the returned application must be valid according to its JSON Schema', function(done){ }); common.testAuthentication(URL, ‘POST’, '/applications', username, userpasswd); … describe(‘POST /applications', function(){ it(’with a valid must be valid according to its JSON Schema', function(done){ }); … //other test cases …

Functions like common.testAuthentication(), common.testNotValidIds() and others are our general, common test cases (written using Mocha, too) run for each endpoint. They test API and HTTP recurrent methods authentication issues, check calls with wrong or malformed resources’ IDs, perform data validation using JSON Schema and so on… 

To write each test case we’ve chosen a BDD-style approach, in particular using Chai.js assertion library with the should flavour. Chai and Should allow to write chainable assertion constructs using natural language, resulting in funny-to-write, simple and easy to understand code for our tests. 

 For example, using Chai & Should we can write assertions like:

should.not.exist(err); should.exist(res.body); res.body.should.be.an('array'); … errorBody.should.have.property('error'); errorBody.error.should.equal(404); errorBody.should.have.property('message') errorBody.message.should.equal(‘Not Found’); …

Finally… just remember that we are testing APIs, so we are testing their exposed interfaces through HTTP calls to available endpoints. ;) 

To do all the API calls we are using Supertest package. Supertest provides a high-level abstraction library for testing HTTP calls and it is based on the “low-level” Superagent client request library. 

So, a complete test case for an API endpoint call, written combining the chosen frameworks, can be expressed as follows (just an example):

… describe('GET /applications', function(){ it('an application must be valid according to its JSON Schema', function(done){ request .get('/applications') .auth(username, userpasswd) .set('Accept', 'application/json') .expect(200) .expect('Content-Type', /json/) .end(function(err, res){ if (err) return done(err); else { should.not.exist(err); should.exist(res.body); res.body.should.be.an('array'); res.body.should.be.ok; if(res.body.length>0){ let app = res.body[0]; try { applicationSchema.validate(app); done(); } catch (error) { console.log(error.name, error.path); done(error); } }else{ done(); } } }); }); }); …

where request variable is a supertest instance.

Simple, funny, classy, priceless.

Moreover, using Mocha it’s possible to run a single test suite or to run all the tests in our project using one command, for example through a configured npm test script in project package.json file.

Finally, we get a report about all tests executed using a configurable reporter, like the one shown in the following picture (where the reporter used is Spec, included in Mocha dist):

That’s all. 

Dear Vivocha Customer,

We have to perform some essential maintenance to our Vivocha servers which will cause a downtime on our services.

All the Vivocha services will be down for maintenance from 10pm (UTC) Mon 12th October to 3am (UTC) Tue 13th October.

In the unlikely event you see any issues following the maintenance window, please let us know sending a e-mail to [email protected].

Regards,

 Hi everybody,

We are really happy to announce a new Vivocha release: The Waiting Cat.

Vivocha 4.6 comes with a set of new features that will improve the contact distribution and the management of the users availability in the Agent Console.

Media Switches

Media switches replace the old media menu on the top bar to allow the agent to quickly set the media for which they are available to accept contacts.

When an Agent cannot be available for a certain time, pause state may be triggered for all media at once with a click on the “pause / start” button. This will pause the console that, by default, will not accept new contacts.

The switches are paired with a status notifier to clearly display whether the agent is ready to accept contacts, is paused or, in the worst case, is disconnected from Vivocha.

See more on our documentation.

Agent Menu

Agents can now set up their own account thanks to the introduction of the Agent Menu.

The menu is displayed with a click on the avatar, in the right corner of the top bar. It contains agent info, log out and help buttons. The most important section is that of Personal Settings that allow to enable or disable some functionalities with a single click:

Accept contact while in pause (to see new waiting contacts even when the console is in pause)

Auto-spell check (grammar correction tool for chat contacts)

Audio notifications (to enable Vivocha sounds)

Console notifications (to enable desktop notification for Vivocha on supported browsers)

Discover more about this tool here.

Agent media limits

Another great feature of this version is the possibility to set the maximum number of simultaneous contacts per agent and not only per service as it was in the previous versions.

Enterprise routing

Enterprise customers can now control how contacts are distributed to agents selecting from five predefined algorithms:

Broadcast

Skill based

Round robin

Least loaded

Dynamic

Additional custom algorithms can be easily be created and many advanced settings are available through the routing configuration tool. More information on routing settings can be found here, a detailed description on how routing works can be found here.

Hi everybody! We are very happy to announce you a new Vivocha release: 招き猫 (The Maneki Neko).

New file transfer functionality for enterprise accounts

The new release comes with the capability for both agents and visitors to upload and send files to one another. There is no limitation to the types of files that can be sent: images (jpg, png, svg etc), pdf, word, txt and more.

The maximum file size is 10mb per attachment.

Let’s see in details how this new feature works.

The agent can now attach a file to the chat conversation using the file transfer icon, located on the media toolbar.

Click on the icon and it’s possibile to pick a file from your system. You can even add a description, but that’s optional.

When ready, the agent simply clicks on the OK button and the file is uploaded and displayed within the chat transcript.

For the customer this action is as easy as it is for the agent: a small paperclip icon is located within the textarea input. By clicking it, the customer can pick a file to send.

On the agent side, if the file is an image, it is possible to preview it directly in the Agent Console by clicking on the thumbnail displayed in the chat transcript.

The mobile Vivocha SDK’s has been equipped with the file transfer feature as well:

Hi everybody,

We are pleased to announce a new Vivocha release: The Nyan Cat.

Vivocha 4.4 comes with a bunch of brand new features to create real-time multimedia interactions with your customers. Interactions have been made more powerful thanks to a new media engine that incorporates video, voice and chat in one place.

New multimedia engine

The new multimedia engine simplifies the way you interact with your customers: your contact could begin as a simple chat to become a video call and maybe end up as a phone call if you need to!

Let’s see how it works

Starting from a simple chat from your website, you can now see the media toolbar that allows you to add media to the current contact.

You can start a video call with your customer (or your customer can request it to you), using the WebRTC technology built-in in Google Chrome and Mozilla Firefox browsers (both you and the customer must be running one of those in order to use this technology).

et voila! 

Another possibility you have to talk with your customers, even if they don't use a modern browser, is to call them on the phone.

This feature is based on the Twilio technology, the same we use to manage inbound calls and callbacks (see how to link your twilio account to Vivocha here). 

In this way you can keep talking with your customer using the phone, even if he has to close the browser and leave the chat (e.g. the customer has to reboot after having been supported by the agent).

iOS and Android SDKs 2.0

With this new version we are taking the Vivocha experience on your mobile apps to the next level! You can now engage with your customers using audio and video.

The communication is secured by an end-to-end encryption so only your Agent desktop and your customer's device will be able to decrypt the multimedia streams. This new feature is enabled by default on all your native mobile services and all you have to do is to update your app with the new SDKs bundles.

The contact acts as a traditional chat but, if your agent is available on the audio or video media and his/her computer is capable of doing audio/video calls, instead of the agent name in the top bar you will see, depending on the agent’s media availability, a microphone and/or a camera button.

A video call can be started both on agent and customer side. When the request come from the agent, a popup will appear in the mobile app.

When the customer accepts, the call will start immediately.

When there is an active video call and the customer minimizes the chat, a draggable widget with the agent's video appears instead of the side tab.

If you don't want this feature to be enabled for your mobile apps, there's an API for that :) Checkout the documentation.

You can download the new SDKs from the Mobile service Foundry.

Automatic cross-domain persistence

We also added the ability to have persistent contacts between sites that reside on different domains, so, a contact that starts from www.mysite.com can be now persistent on www.myothersite.com.

Hi everybody, We’re really happy to announce a new Vivocha release: The Hipster Cat.

Telephony

We simplified the Telephony integration with Twilio. Along with the Outbound and Callback Services, you can now handle inbound voice calls, too!

Now you can easily manage your phone numbers and buy new ones inside Vivocha.

See Telephony 4.3 for more.

Inbound calls

Once you have connected your Twilio account to Vivocha, you can create Inbound services and receive phone calls using the Vivocha Agent Console!

See Inbound Telephony Service for more.

Outbound calls

Once you have connected your Twilio account with Vivocha, you can also place calls inside the Vivocha Console on the spot!

See How To Handle An Outbound Call for more.

Mobile HTML services

Improve your mobile experience! Vivocha 4.3 introduces the mobile html widgets for mobile browsers. The new responsive widgets are designed to fit in all the most popular mobile devices. If you don't have an app to integrate our SDK or you just want to extend your services to your mobile web site, this is the right feature for you.

See how to configure a mobile html service here.

iOS and Android SDKs 1.2

In this new release the mobile SDKs comes with a new and improved chat UI and theme, better stability and a richer set of APIs.

New native Chat UI

New APIs

With the new APIs you can:

create new types of contact such as WebLeads and CallBack Now

track your custom engagement button directly from the Vivocha Console Realtime and Reports 

customize the top logo (the default is the Vivocha's one) in the chat view.

change all the Vivocha UI strings and override the default language (e.g. your app lets the user choose a different language over the system one)

Documentation

We reorganized the Mobile Services' Documentation Portal and we added an How-To section where you will find the code for the most frequent requests about the SDKs. 

Check it out at https://vivocha.atlassian.net/wiki/display/VVCJ/Mobile+Services

We also created two example projects on Github that integrate Vivocha.

Here are the links:

iOS: https://github.com/vivocha/ios-sdk-example

Android: https://github.com/vivocha/android-sdk-example

New billing and invoice interface

Vivocha 4.3 introduced a renewed interface for plans management.

The new interface is designed to simplify the monitoring of the credits and the management of the invoices and billing information.

We also have significantly simplified the plan subscription procedure and the extra credits purchase: upgrade the plan has never been so easy.

Hi everybody, we are proud to announce the latest Vivocha release.

New Reports

We've added even more power and precision to our Reports, enriching the tool set provided: detailed agent's performance stats, and bar/area chart switches to let you decide how to display your trends.

A new and boosted filter engine gives you more control than ever, making it super easy to compare between periods of time, services, tags and media performances.

Overview

We've added enhanced our Overview panel, designing a new, customizable and zoomable chart, and near-realtime value comparison boxes to let you know your overall performance at a glance. In the Overview panel you now have also an agent performance report.

(See more at Reports Overview)

Services

The new Services panel has been enriched with customizable charts, performance boxes and a new "details" list where you can monitor your service stats individually.

(See more at Service Reports)

Agents and Contacts

Both Agents and Contacts panels have been equipped with a powerful filtering module, that allows you to create your own aggregations of metrics by choosing which ones to include, like media, tags and services in each aggregation.

(See more at Agent Reports and Contact Reports)

Reports Export

Receive downloadable exports directly in your inbox thanks to the new Email exports feature:

Please take a look at our documentation to discover all the new reporting features.

Android SDK

We did it again! We are proud to announce that we've replicated the magic we did with iOS on Android! :) The integration is still super easy... just follow the steps in our documentation.

With the Vivocha Android SDK you will be able to add the Vivocha experience to your native Android apps.

The Side Tab will automatically appear if you have available agents and it's fully customizable using the Android Foundry, just like you did with the iOS SDK!

The Android SDK comes with a built-in Chat activity that appears when a user taps on the Side Tab. You can customize that too!

We created a full set of Java APIs to allow you to customize all the behaviours and the look and feel of both the Side Tab and the Chat activity or to recreate them from scratch.

If you are used to deploy a test app to a group of testers before the actual submission to the Google Play, you will love this new feature:  if you set the developer mode in the Android SDK you will be able to change the look and feel of the Vivocha widgets right from the Development tab in the Android Foundry without affecting the Production configuration!

Citrix GoToAssist Remote Support and Service Desk Integration

Are you already a GoToAssist customer? No? So it's the right time to be one!

Vivocha now is fully integrated with the Citrix GoToAssist modules:

Remote Support, to have remote access and control of unattended computers.

Service Desk, to easily manage incidents to quickly resolve customer issues in our Console while interacting with them.

So now you can easily use Vivocha to manage your customers incidents and give them live support using the combination of the Vivocha media and GoToAssists tools.

If you're already a Citrix customer please have a look at our documentation and at the Citrix support site to see how to link your Citrix account to Vivocha.

If not what are you waiting for? Subscribe to GoToAssist and try it free for 30 days.

Customer Survey

A popular feature request by our customers has been added in the new version of Vivocha: the customer survey. Now your customers can rate the support they received and you can also collect data after the contact is closed: the survey works just like a data collection widget.

Security options

Other two popular feature requests are now available in the Security panel:

Password policies options, to configure the password's requirements for the new users, like length and letter case.

Privacy option, to disable/enable the contact geolocalization feature.

See more details on our documentation

Hybris Integration

We've introduced a new design and improved the features for the hybris platform integration, now compatible with the versions 4.6+, 5.1.x and 5.2.x.

The integration allows you to set custom rules based hybris segments, and have a proactive engagement based on:

Cart status (cart value or number of items in the cart)

Hot products & special offers

Purchase & navigation history

Customer total value

Customer profiles, gold customers

VIP profiles, etc

We redesigned the application that shows the customer details and the contents of the cart.

And, if that's is not enough, we improved the Customer Service Cockpit integration inside the Vivocha Agent Console.

To see how it works request a demo, or take a look at our documentation to see how to configure it by yourself.

Performance Improvements

This is the first time we explicitly announce a performance improvement of our product: Vivocha is a continuously improving service and it's natural that also the performances increase with the evolution of the product.

But this time is different, our performance has been increased so much that we just couldn't refrain from telling you: the loading of the Agent Console is now up to 5 times faster than before and accepting an incoming contact now takes less than a second.

This was made possible by doing a deep review of how static assets are generated, compressed, cached and delivered and by using a high-performance CDN, Amazon CloudFront.

Hi everybody, We’re really happy to announce the new Vivocha release: The Texting Cat.

Image from imgfave.com

iOS SDK

This version introduces a new major feature to our platform: The iOS SDK. With the Vivocha iOS SDK you will be able to integrate the Vivocha experience inside your native iOS App so your customers can reach you without a computer!

The integration is super easy as you can see in our documentation.

What does the Vivocha iOS SDK add to your app?

A Side Tab that is fully customizable to match the look and feel of your app and it's even proactive (it appears only if you have available agents)

A Chat View that will be presented to your customers once they tap once the Side Tab. The view is designed to resemble familiar applications like iMessage, WhatsApp, etc.

All the widgets inside the chat view are fully customizable both via our rich Objective-C APIs and using the Agent Console Settings.

You can even rewrite the Engagement and the Interaction views to be fully integrated with your app workflow and looks, using the API hooks the Vivocha iOS SDK provides.

On the Agent side we have two cool new features:

Geo Location: Your agent can request the exact location of the customer (who will be prompted with a confirmation popup, because we care about the privacy of your customers!) and with the Auto Geo Location feature you can even follow them while they walk about.

Screenshot: When the Agent Desktop recognizes that a contact has been requested from an iOS device, the Co-Browsing application displays an iPhone screen where the Agent can see what's on the customer's screen.

Facebook integration

Your can allow your customers to fill out data collection forms using our Facebook button.

First, create your Facebook application to retrieve the customer's data by following the tutorial.

Then link your Facebook account with Vivocha

Add a Facebook data collection field in which you select your account

This is the result on the Customer Side

And this is what the agent will see

Customer History

Many of you asked us and it's finally here: The Customer History application is an interaction tool which can be used during a contact.

It will show you more detailed information than the Customer Info page, like the number of past contacts and visits along with when the first and most recent were, but above all it gives you the possibility to see the details of the previous interactions.

See more in our documentation.

Reports Overhaul

The Reports Interface has been revamped with a new layout and graphs.

The Overview section has all of the basic data collected from your Vivocha account (Media Usage, Engagement, Average Metrics). The data will change based on the values that you have selected in the dropdown bars at the top.

In the Services Report you can see all of the different data collected from your account's services. For each service you are able to see information related to the contacts of the service such as successful contacts, abandoned, dissuaded, canceled etc.

In the Agents Report you can find all of the data collected on your account's agents. You can compare the performance of two agents or of a single agent and the total of the selected report.

In the Contacts Report you can see the data collected on the various contacts for your account, you can also see a chat history after clicking on a specific contact.

And the enterprise accounts can easily download the Reports Data as xls file.

For further information about the new Vivocha reports please take a look at our documentation.

Improved analytics tools

The Vivocha analytics tools family is growing, we added the Webtrends integration (see: Webtrends Docs) and we improved the Google Analytics integration (see: Google Analytics Docs).

The family will continue to grow with the next releases, but if you want you can build your own integration using the Vivocha events for your analytics tool.

New E-commerce Integrations

Good news for the Vivocha e-commerce customers. Vivocha added a deep integration with two of the most used e-commerce platforms: Magento and Prestashop.

If your online store is built with one of these platforms, you can easily enhance it by adding live support, and start immediately increasing customer satisfaction and boosting sales using Vivocha.

Thanks to the integration, CSAs (e.g. personal shoppers) can access the information needed to understand customers’ needs and deliver highly customized customer service.

What are you waiting for? Follow the tutorial and link your application to immediately improve the interaction with your customers:

Magento Integration Tutorial

PrestaShop Integration Tutorial

Salesforce.com Integration

If your customer relationship management (CRM) is Salesforce.com, you can easily use our integration to manage your customers contact information.

Just link your SFDC account, and start creating or editing contacts as they arrive in Vivocha, they will appear automatically in the Saleforce.com interface.