Do not allow the slight changes in nomenclature and an almost identical-looking Agent Desk to fool you into thinking this release (5.x) is an incremental upgrade. This is our most radical release, across a number of dimensions, for a number of reasons.
To see a breakdown of the new features see What is new with version 5 or read on to get an overview of what it all means.
With the release of version 5 the entire ethos of the product has shifted toward wrapping the visitor in the familiar. A new level of integration and persistence allows you to offer your visitors not just sophisticated and secure communications, via the unblu Secure Messenger, but to provide a place where memories of previous interactions can be stored and accessed.
In order to release the full power of the Secure Messenger you must install on either the Kubernetes or Openshift container orchestration platforms. While Openshift/Kubernetes are advanced, and radical, solutions that seem almost to threaten to make traditional server-client architecture obsolete, the fact is that while they may be a 'devops dream' (in that your technical admins can mould the system to accommodate 'future' internal business requests: How cool is that?) what they do is so much more powerful than simply 'orchestrating compute resources'. What this ability to 'orchestrate' means is that a continuum is created between business strategy and compute resources. It’s a bit like building 'slack' into the system but without the slack. Resources become 'responsive'. With the right architecture (Openshift/Kubernetes) in-place the system becomes almost infinitely, and instantly, expandable.
An unblu cluster can accommodate the pulse and flow of real business. Resources can be made available on demand; automatically growing or shrinking according to actual needs.
Using the full power of unblu clustering on Openshift/Kubernetes it is possible to ensure that business decisions, made later in the cycle, can be accommodated within the technical framework without fear of undue expensive and complex refactoring.
If you decide to adopt Kubernetes/Openshift for the sole purpose of accessing unblu functionality then you should look at the particular requirements of running a cluster (even if it is a single-node cluster).
Kubernetes is a 'project' and Openshift is a 'product'. Openshift uses Kubernetes. If you have no current installation of Kubernetes/Openshift then this article, by Tomasz Cholewa may go some way to outlining the differences and commonalities.
Previously, your visitors could co-browse Web pages and documents, and exchange communications using chat and audio and video. They can still do all of these things, much more easily and more comfortably but now, each and every time they engage with your agents, all of the information, documents, co-browsing actions, audio and video, all interactions, everything that represents a given session, is stored and added, contiguously, to all previous interactions. We call the sum of these interactions Conversations.
Conversations persist indefinitely.
Conversation — The sum of all sessions/chats within a single, persistent communication channel (all activity that has happened in the past, and may be happening now).
Memories - The individual artifacts of the entire Conversation (chats, messages, email, audio/video, etc.).
Presence — The visitor(s) and or/agent(s) in a session.
Place — The visitor interface where all Conversations are listed and can be accessed.
No matter how many agents/experts deal with a visitor that visitor will be able to see and access all of those interactions. The net effect is that memories are generated on the visitor side. This is not a technical issue of computer memory but memories of all previous interactions always available, always at hand. The feeling, for the visitor, is like having your representatives visit them, in their place, filled with their personal memories of all of their interactions with you.
The first time a visitor engages in a Conversation will be functionally identical to engagements in previous versions of unblu. But the next time, and the next n times a visitor engages with you, all artifacts (video, documents, photos, audio and chat, etc.) generated in each engagement are added to the visitor’s place. And the place is simply the interface the visitor sees. It requires no configuration on their part. The visitor’s place contains all of their Conversations. It may be that any given visitor needs one or many Conversations in order to service their needs. Either way, each time a registered user goes to their place they can select any of their ongoing Conversations.
This has many applications and advantages. Imagine a complex visitor. Someone who is as likely to ask how they can buy cryptocurrency as they are about US Treasuries or derivatives. High-maintenance visitors, who may need a number of specialized agents to visit their place during a session (or part of a Conversation) see the most benefits as the very complexity that their demands generate is captured during every session. Nothing is lost. The next agent can simply arrive in the Conversation and pick up where other agents left off. All of the documentation and artifacts previously generated will be right there, waiting.
While you can still exchange messages and documents while both the visitor and the agent are simultaneously online, you can now also send messages while the other party is offline.
This is powerful in that it allows 'step-time' communications within Conversations. This simplifies scheduling and makes Conversations more 'elastic', in that supplementary information can be pushed either way at any time. This, in turn, makes the underlying process of the relationship itself much more fluid and dynamic. The Conversation can be always available, always 'open', ready to be broadened, to deepen, to expand.
While a visitor can choose to open entirely new Conversations each time they engage with you, it is in their interest, and yours, to minimize the number of Conversations, as this allows rich memories to populate their place. By definition, all previous interactions define the relationship. When a new agent arrives in the runtime Conversation they have the benefit of having highly-targeted and relevant histories at hand. These histories (or, as far as the visitor is concerned: memories) persist in the form of previous exchanges that contain the DNA of that particular relationship.
On the visitor side, every time they engage they become more comfortable. Visitors, all of us, like to be known. Conversations solve the perennial problem of a visitor having to regurgitate the same information again and again to different agents who may have just arrived or have no knowledge of the visitor. This relationship dynamic also makes the visitor feel like their place is their own property. They can offer new (agent) entrants to the Conversation a welcome in much the same way they would in their own homes. While there would be no cups of tea and biscuits the visitor can point to their memories in order to get agents up-to-speed.
At a lower level in the engagement-complexity hierarchy, visitors with simpler needs become even easier to service. The massive gains garnered with complex clients may not be obvious when visitor needs stretch to a current account and a credit card but the ability of any agent to understand the needs of the visitor is seriously augmented when all of the documents and history of a particular Conversation is instantly available.