So what’s going on outside the Core Contact Center

I happened to be watching a few documentaries on how Einstein and other Key Scientists discovered their contributions for which they are now known for… I looked back at my work and see a plethora or technologies, buzzwords and jargons thrown around everywhere and I started thinking if it was possible to bring all of them under one logical roof. What I noticed was that the core contact center gets a lot of attention but the surrounding soft processes and technologies outside the core has been ignored. Let me first explain what I mean by the core:

It has three primary components:

  1. The Connect Services – Focus is on Expanding the ways by which the Customer is able to connect with the Contact center. Nowadays this extends to finding ways how agents also can perform their service from multiple channels other than the rather traditional phone + pc method.
  2. Self Service Services – These Focus on Diverting the Interaction from Human to Machine. The Motivations can be many but bottom-line it’s a machine doing the human’s job. Again the rant of IVR Hell is the most popular slogan in every CC Sales person’s narration and continues to the Rise of the Bots in service of Humanity and the best bots being from their garages.
  3. Automation Services – These Focus on Ensuring that the Customer gets serviced by the right agent or bot based on information collected during the interaction or history.

All of these are fundamental to any contact center solution for longer than the past 2 decades and hence I never got myself to blog on the various transformations happening here. What could happen outside the core is however never discussed and hence the key subject of this blog.

Let’s visualize this Core Thingy

So the Experience Gained by Customer when Interacting with the Connect services, we call “Customer Experience” aka “CX”. Similarly, the Experience the Core Gives to Agents becomes the “Agent Experience” aka “AX” … Right?

Wrong… Let’s see why…

Let’s focus on the Customer and see what actually is driving their CX… I hear your mind voice…you just thought about the new term “Omni-Channel” …. And Something Else is coming up… “Customer Engagement” …. Ah now I hear something else … Ok Stop… I’m here to tell my opinion …not Yours!

In my opinion Customer Experience is governed by three key activities

  1. Engineering – This is where the Engineers tirelessly build the core and associated solutions block by block. After crossing the mindless desert of bureaucracy, the storm of politics and whirlpools of bugs, the Engineers brings solutions to production. This used to consist of lifelong projects in the SDLC era but now has been cut short using DevOps so engineers have to cross smaller obstacles than larger ones before…
  2. Experience – Once the Solutions are brought to production the customer happens to use the solution and hence you get “Customer Experience”. Thankfully there are tools which are able to Quantitatively measure these customer experiences using DataOps. This used to be a laborious manual task in the past but nowadays has become automatic to a large extent letting the Data Engineers to focus on Insights
  3. Insight – The Insights is the activity performed typically by Supervisors but now slowly business managers and marketing managers are also getting into these tools to gain insights to better their side of business. These Insights result in Stories which in turn fuels the next round of Engineering.

Now let’s visualize what I’m talking about …

Now in Traditional Environments, this whole cycle would happen every month at max but the way things are moving in the Digital Economy, it actually moved on to Events based model thanks to AI ….

On a similar note the same cycle goes on in the Agent Side as well contributing and improving the “Agent Experience” and “Agent Engagement”

So What else could be happening here… All the Engineering activity happen mostly on the CC Platform and the Data about Customer and Agent Experiences and Interaction Histories are stored in Data Stores

So Let’s bring them all together:

So Let’s look at this new box called Platform we just added… It’s basically the core of the contact center exposed to Developers and Infrastructure Engineers.

The AppOps Team would use Observability Tools to understand the Services’ performance and bottlenecks.

The AIOps on the other hand use Experience Monitoring Solutions and Uptime Monitoring Solutions with Automated Remediation Solutions.

For the Developer there is the DevOps Stack with the Code Repository to store their configurations and code. Continuous Integration Ensures that the ready to release software/configuration gets Tested functionally and for Security Vulnerabilities as well, before landing on the platform.

So this is how all this would look like:

So the Platform has a lot of real-time and historical data in the Data Store… Let’s see what the Data Folks do with it…

So If you have a real Data Engineering Minded Org then the Data Engineers and Scientists would like to have their own layer of lakes to handle the processed data in their useable form.

Most Orgs would use prebuilt Analytics solutions to serve business metrics to Business Managers and Contact Metrics to Supervisors…

There could and should be more outside the core that typically gets ignored in most orgs… If you know anything I missed please do let me know

Spectrum of Machine Learning Skills

I’ve been always wondering what roles are there in Machine Learning space. I just thought I should summarize and here goes… Below is my view of how the ML Skillset is spread out with differing levels of math and machine knowledge

Let me know if you disagree in the comments…

Network for Humans

I’ve been thinking for a long time about how the whole concept of electronic networking could be made better or at least different. This post on twitter [https://twitter.com/etherealmind/status/1110280603675566081] by @etherealmind made me regather everything going on in my head and put them in this blog… So here goes…

Why Change?

To be Frank, I’m a bit lazy and tired of the nerd-ism surrounding CIDR. I was irritated by the whole static planning that needs to be done when working in Infrastructure as code to isolate and control traffic between different application groups by using CIDR. I liked the way Docker Swarm enforces Network segmentation/isolation in a human understandable manner. The VMware NSX micro segmentation using Security Groups is also nice from an Infra-as-code workflow. But both are virtual network only constructs and not applicable for the physical networking layer… I was not able to see any way out except change the way we represent the networking endpoints which in current situation is either IPv4/IPv6 or MAC. Both of which from a human reader perspective is an 8-bit number range (IPv4) or Hexadecimal (IPv6/MAC) … Neither of which I like…. So, what could be the way out… Well I got this idea and am jotting it down as is … so expect changes later

The change in Endpoint naming convention

To start with I wanted to look at a naming convention that we humans use for objects. My first iteration was to use English alphabets from A to Z which is 24 in count, numerals 0 to 9 and a few regularly used symbols found popularly on all keyboards.

Alphabets    ->    a-z    ->    24

Numerals    ->    0-9    ->    10

The nearest bit count needed to accommodate this would be 6 => 2^6=64 slots. The alphabets and numerals eat up 34 leaving us with 30 additional space for other characters. In my second iteration, I make the naming “case restricted”, then I need to reserve 48 spaced for alphabets: 24 for small caps [a-z] and 24 for Capitals [A-Z].

This would then occupy 24+24+1=58 slots leaving 6 slots for other characters… I propose we use

+

*

/

.

\

If I overlay these 6 bits per character plan on a 128-bit address space (as is used currently by IPv6), I can accommodate 21 (128//6=21) and leaving 2 bits (128%6=2). I propose to use these for type indicators that I’ll describe later…. IMO 21 slots are a reasonable count for human readable endpoint name.

Structure of the Endpoint Name

IPv4 & IPv6 are fairly unbiased and allow the network admin to structure the allotment as per their whims and fancy. This is great for static infrastructures but not great if the Endpoints are going to be dynamic and vary in both rate of change but also change in count. I propose to used a biased naming structure here so that the name can be predictable within a certain boundary and leave enough space for dynamic naming. My first iteration is to use this structure

tier

name

Slots

example

NA

endpoint type

2 bits

0

0 – public fixed

1 – public mobile

2 – private fixed

3 – private mobile

0

Celestial location

1

E (earth)

1

Latitudinal Slot

1

N

With North Pole as reference, divide latitude into 64 slices and give each slice a char code (0-61)

2

Longitudinal Slot

1

G

With GMT as reference, divide longitude into 64 slices and give each slice a char code (0-61)

3

Country

3

IND

IND for India, USA for the US, … you get the drift right…

4

zone

2

TN

The definition for this could vary by country or could just default to 00 for globally mobile endpoints

5

service provider

3

YBB

Legal owner of this endpoint responsible for this endpoint

6

user defined

10

JF-PC.home

Name that I understand and the network too

Errr! Isn’t this too complicated!

Yup… It is going to be too complicated if we use the full naming convention always. But what if I make the addressing a bit IPv6-ish and move the whole tier 0 to 5 into a `::` . The :: can be filled by the network device and user only specifies if the target is public/private and the human understandable name…. Now Users will be dealing with only names like “2::dbserver1” for private servers, “0::google.com” for public servers.

I must admit I haven’t thought this through but I guess that’s enough for this weekend. More on this later if I get any more idea…

The Next Frontier for Collaboration

So why did I start on this?

After a long time, last weekend, I came across a pitch I used to take on our POV for Communications way back in 2007…I had predicted that something called “Air PBX” would replace all the then known Predominantly On-Premise Solutions by 2020…

Well I’m now in the start of 2019 and to me it looks like the concept of Air PBX is now prevalent as Cloud PBX from various vendors and is now the default start point of voice architecture. Only Laggards and some customers with genuine “Consistent” quality requirements remain on Legacy On-premise solutions. So much has changed in the Industry and I too have broadened my portfolio now covering the entire Collaboration Technologies. My outlook also has now changed and spearheaded by the frontline collaboration products…ahem…ahem… I’m referring to the Teams duo (WebEx Teams and Microsoft Teams) …

This weekend I was thinking what the scenario in collaboration in the next decade would be…and this followed…

Architecture Highlights for Collaboration in 2033, IMHO

Plenty of Architectures reviewed and Possibilities got analyzed in my head, and I settled on a few highlights that could define the Collaboration Architecture of 2033…

  1. All functionality of Collaboration Services would be available and consumed from Public Clouds.
  2. On-Premise solutions would exist but not as “Production” Equipment. On-Premise Solutions would be built and maintained to handle DR/BCP aka “Cloud Fall” situations
  3. PBX, Voicemail, SMS and ACD may be terms that will be found only in dictionary
  4. The Current Complexity of Multiple Products for Multiple Services will disappear, and Significant Convergence will happen on the Admin Front-End. Please do note that while “Services Endpoints” Collapse/unify, the “Consumption” Mechanisms will explode.
  5. The Diversity of “Communication and Collaboration” Management Teams will disappear and will be replaced by teams aligned to the prevalent vendors at that time. To Illustrate, the SME of vendor 1 will cover all technologies from voice, video, documents collaboration, messaging and the various modalities of consumption that will be normal by then…But this SME may not have any idea of how to get things done on vendor 2’s platform.
  6. Very few Enterprise SMEs will understand the backend complexity of the respective platforms and these too will be focused on managing the DR/BCP setups only.
  7. Identity, Privacy Policies and Data Protection used for communications and collaboration will be external to the vendor platforms unlike how it is tightly integrated currently.
  8. AI/ML based technologies will become utility and serve well understood services with full access to the user’s live and historical interactions. The Universal Policy Managers will ensure that Privacy is managed.

So how would the Collaboration Architecture of the Future look like?

Its Feb 2019 and things could change significantly both towards or away from what I believe will happen. I took a similar approach in 2007 when even Hosted PBX was not a normal practice. At that time UCaaS and Air PBX were terms with very few practical technologies available to make them a reality. But the market has moved in exactly the direction I predicted… I’m going to use a similar extrapolation this time… so here goes…

I believe the entire Architecture will be broadly clustered on four key Solution Units:

  1. Contact Service Providers
  2. Content Service Providers
  3. Security Policy Managers
  4. Consumption Technologies

Of these IT SMEs will have deep knowledge of only the Consumption Technologies. The rest will be of “Talkonology” grade and will be well versed only on the GUI/API based management. Only a few curious and ardent nerds will have knowledge of the inner workings, and their knowledge would be utilized in customer’s DR/BCP Build and management purposes.

Contact Service Providers

In the Current ecosystem this is led by the likes of Skype for Business Server Editions, Cisco UC Servers and similar IP PBX/UC Servers from multiple UC Vendors. IMO these functionalities will move to cloud-based platforms like Skype for Business Online, Microsoft Teams, Cisco WebEx Teams and similar platforms…. Slowly and steadily these will build tight integration with Content Infrastructures in the backend.

The Contact Services themselves will become simplified with Unified Interfaces providing access to all Channels of Communications for the Users. The back-end however would be significantly more powerful and feature heavy than current UCaaS solutions.

Content Service Providers

In current ecosystem this is led by Microsoft SharePoint, Exchange and the various Knowledge Management products in the market like Salesforce.

As mentioned above these would merge from being separate products to a unified product in the admin front-end. Please do note that in the back end they will continue to be different with each service doing what it does best. This Product will also be handling all the data used by the ML Engines deployed in both back-end and Consumption devices. Governance will be handled by Universal Privacy Policy Managers

Security Policy Managers

To be candid our current ecosystem does have several wannabes in this product group, but none may be ready to take the overall nine yards.

The products in this group will be universal in the sense that they will work independent from to the contact and content platforms. This group may not be covered completely by any single platform as well unlike the contact and content products…

Consumption Technologies

This will be the most interesting group which will flourish widely and be the target of time spent by the Architects and Administrators of the Future

If you’ve been in this side of business, then these shouldn’t be too new. The only major difference will be that by 2033 these will be normal and significantly less complex… Also, the Legacy pieces may remain in some Laggards’ IT Portfolio….

Finally

I wanted to write a lot, but time is short and hence kept to a minimum… maybe I’ll write a follow-up in future…

To get an idea of how I was doing the extrapolation… You can check out my earlier blogs https://julianfrank.wordpress.com/2014/09/26/the-ucc-infrastructure/ and https://julianfrank.wordpress.com/2014/09/19/thoughts-on-ucc-first-a-recap-of-what-has-been-happening-so-far/ .

Happy Reading -.