Conversationware

Paul Sweeney’s blog, “you’ve been noticed”, is a good resource for looking at what the UC technology industry calls “Communication enabled business processes” - or as Paul puts it more succinctly, customer interaction.

There is a great double win to be had

Through being proactive (and automated) interacting with customers, not only can you reduce direct costs by, for example, reducing inbound calls and removing duplication of effort. You also increase customer service levels at the same time - for increased sales.

The original article at Service Untitled is also a good read and argues for more multimedia and self service options.

My experience of friends and family is that they as customers really don’t want to be calling anyone help either! It’s not always easy asking for help, you can feel stupid.  Customers expect you to anticipate their need and deliver information before they know they need it. As competition gets tougher, then not doing anything won’t be an option.

Because maybe they just buy from someone who makes it easier next time.

I really think that an inbound telephone call is often your last chance to keep a customer, and if your people are overwhelmed with calls, that can be a really bad sign.

Shoot first and save lives.

Come on people - more sales for less costs, ….a no brainer.

So, delivery and service industries would benefit most from automation, and Paul links to the UPS desktop widget - really very cool. I wonder if RSS is at the heart of it.

I can personally think of a number of wasted days off that might have been saved if the industry norm were to text, email or phonecall confirmations the day before.

It’s not often I plug the company I work for, but Avanquest Text Message Server - has a SMS delivery receipt capability, that can update the host database, so you even know who didn’t get the message. My favourite feature of a great product - which is an end to end solution also available oem. OK, plug over. You can open your eyes again.

I still have mine closed, as I’ve upgraded and put some plugins on the site. I’m sure this will explode when I press the button.

The demise of any technology is probably inevitable, apart from the PC, which seems to be responsible for most of the carnage. The PBX is being lined up as the next ‘mainframe’ to disappear.

My own thoughts are that A single interface for whatever it is you may want to do is just too powerful to resist, starting with the typewriter, and who knows where it will end

Alasdair Ford writes an excellent piece plotting the rise, and predicting the ‘possible’ eventual fall of the PBX.

It started me thinking about whether there are good reasons the traditional PBX will survive OCS and Asterisk.

I know my telephony friends will probably look at me with scorn for putting it like that But when speaking to a technical chap yesterday, and he told me he was considering downloading and running Asterisk telephony on his ADSL router for a home PBX, it kind of stopped me in my tracks.If the only reason for PBX is survival were to be “you wouldn’t run a business on that, would you?” then I don’t think there’d be a decade left in it:

But surely that’s not the case?

1. Call Centre - this is a nailed on survival strategy as the ‘niche’ is completely arcane. It is also the one reason most companies will keep some sort of PBX imho. It may split buying decisions between callcentre and back office, but that’s always been ‘common’.

2. Call handling - related to the first point, routing calls through reception consoles, and all the little foibles that users in ad-hoc groups need. After 5 rings, can we ring the bell in the delivery bay, for example, and how about Manager Secretary working.

3. New Technology projects are not always about all the new facilities, it’s about the little stuff you took away. Replacement solutions have to be very extensive in functionality.

4. Unless it is a greenfield site, it will always be less expensive to just carry on with what you have and add a few bells. The business case for UC hasn’t been proven for example, but then, is there a business case for email….who has to make that these days? And it amazes me how much kit out there has gone well beyond the 7 year cycle. The long tail indeed.

Fax is still a growing technology for us, lets not forget the proven stuff will find a market for time to come, although suppliers will probably consolidate. Do you fancy buying a telephony from someone who will be merging with one of the dominant players?

Ok, I’m stuck for ideas now, 4 reasons isn’t that great is it - what else is there?

The age of ‘Presence’ is on us, with the requisite promises of unlimited contact potential.

A couple of Microsoft attributed quotes lately on the subject

For example, many of the features implemented in a PBX are intended to ensure that calls are not missed and/or do not end up in voicemail: so-called “find-me, follow-me” features. Unified communications uses a fundamentally different paradigm to address the underlying customer need

And another one

Presence based communications: you only attempt to communicate with someone who is advertising their willingness and ability to communicate with you at any given moment

OK, so, I can see the point. Instant messaging is a great overlay, and will give us the very important ability to know if someone is available at their desk.

So, wouldn’t it be neat if Unified Communications could tell me if you’re on the phone? (more…)

Are you at your desk, are you on the phone…these are the two key ingredients to make your Real Time Unified Communications cake rise.

Presence, I think they call it, and, exposing (all of) the PBX telephone handset status to software is what’s needed.

Did anyone say Busy Lamp Field?

However, whether you can have cost effective UC might come down to whether you run a Call Centre.

I’ll explain (more…)

I have often teased telephony types and asked them ‘what’s the point of VOIP, or IP Telephony systems? Well, I found a plausible answer.

My semi serious point was originally because companies spend money on infrastructure and skills to change to IPT, and to me, it wasn’t immediately evident what the benefits are, and, well frankly, how do you measure ROI?

Well, I found a reasonable answer regarding old telephone system replacement which I thought I’d share. Bear with me….what I’m getting at here, is that completely open Third Party CTI interfaces cost different amounts on different switches, and it is extremely important for Unified Communications (Unified Messaging is fine either way)

If you buy the wrong telephony platform, you may not not realise that the CTI interface costs a fortune (£40K), and that no clever developers are likely going to bother trying to sell to customers with that overhead (when they can sell to customers who don’t have those costs instead)

NB: FOR THOSE THINKING SIP - ITS NOT A THIRD PARTY CTI, SO YOU’RE NOT COVERED

The wrong switch then, will likely restrict you to telephone system manufacturer’s software, or possibly their selected partners’, which often won’t integrate to the things you want it to. 

Worse, when you try and justify UC in particular, the ROI is still in early stages, and adding a wodge of cash to the bill just ain’t going to help you deploy very useful tools for your information workers.

As I understand it, IPT companies Mitel and Cisco are delivering the the right subset of CTI connectivity out of the box. UC developers and customers are not far behind. My Mitel partner friends knew that I wasn’t anti, and now I proved it

According to Michael Arrington at Techcrunch, Google is to acquire GrandCentral shortly. Thanks for the point Alec, are you next ? Google acquisitions are at a frantic pace right now.

This is remarkably quick work, as I only asked them for Unified Communications in my post on Saturday.

I believe this is a great move for Google, and I’m sure they’ll be pleased I think so. Nevertheless, I’m pretty sure this puts them closer to Unified Communications than most any other provider.

Google have email, voice mail..sort of, instant messaging and video conferencing and now they ‘have’ telephony - the inbound flavour at any rate.

This may be considered a consumer move, but actually, not having to integrate with a company’s existing infrastructure to deliver functionality, and get users, is a key point. Integration is one of the harder aspects of on premises Unified Communications platform integration. It certainly confuses customers at any rate - the first question is usually “is it voip or not?”, and the answer is usually, “well, it could be”. Not a great start.

Inbound call handling is one of those items that is difficult to solve with on premise equipment because callers can choose to ring through different networks (mobile or landline) before the call even gets to the PBX, and if somehow manage to persuade callers to route all inbound calls through the company’s PBX first, there are extra call charges to consider when diverting off net, plus you don’t easily get telephony status, or ‘presence’ from the switch for trunk to trunk calls to mobiles - this is achievable, but in some (not all) cases can be extremely expensive.

Google (Grand Central) don’t need to bother with all that, and will appeal to individual consumers, but don’t forget that all consumers usually work for someone too! If this news is true, people could use Google Inbound services immediately without involving internal IT, by overlaying the service onto existing numbers.

It reminds me a little of when Rim and Blackberry started with marketing mobile email to high value individuals, and then steamrollered into the Comms room later on, once hearts and minds had been won.

One of my first posts on this blog was that Hosted Unified Communications was unlikely (ok, I said no chance), mainly because companies were unlikely to trust hosting companies. BUT, I hadn’t taken into account the Google factor. Google has so much invested in being trustworthy with companies’ and individual’s data already, that one might trust them - despite all of the rumblings from those technically savvy commentators.

Another post was about Google disrupting corporate email, because the reduction in costs could be colossal if only corporations would trust a hosting company with their email. The potential reduction in costs is massively increased if replacing Unified Communications as well.

Over on Aswath weblog, there is a useful suggestion on how Jajah could enable their dialing service without users having to be in front of their PC - Jajah are already promoting the ability to call without headphones - something that always put me off Skype.

I like the idea of a home phone being internet enabled, I guess everything will be before long. But if this is the case, perhaps the phonebook be online and automatically accessible by the phone display instead. 

A centralised phonebook accessible from any device, with click (press) to call would give the same experience as the PSTN, but improve it, because numbers are then also available from your desktop and from your browser enabled mobile.

The strength of Jajah, that calling is ubiquitous and doesn’t rely on any specific islands of connectivity, unlike some voip, is enhanced by giving contact information the same qualities.

Until then, phonebooks on mobile devices will continue to be a handy way of ‘encouraging’ call traffic through whichever network the devices are connected to - a lot of remote workers will still use their mobile because the numbers are on the phone….mainly because inbound callers’ details are so easy to add to the address book.

I always thought that connecting to someone (calling) should be done by clicking on a link, and that these links would ‘front’, or mask, the eventual device the call is delivered on. Abstracting contact details from the device you receive the call on would deliver us from yet another pain point - and deliver my personal holy grail, being a self updating phone book.

A phonebook that updates itself anytime a user changes device, which could be up to three or four times a day. That’s neat.

The way I look at it, the term ‘Mobile Presence’ seems to be a contradiciton in terms. 

I originally read this linked article and found myself thinking the issue was very complicated. And now, having mulled it over in terms of whether this technology was something I would actually ‘use’ or not, I’m skeptical.

Leaving aside the ability to see if someone is on the phone or not….till another time at any rate…

My first thought was;

Because I always have my mobile with me does that mean I’m now always present?

Trouble is - I don’t want to instant message via a mobile phone if I can help it - as I’m usually busy being mobile and away from my desk.

Looking back, ‘Presence’ was coined by the Instant Messaging PC client, and therefore, to say I am ‘present’ actually means that I am at my PC desktop and contactable. Not being present means I have wandered off and am not going to respond.

In my book, this concept can’t be extended to a mobile phone, so ‘mobile presence’ is a misnomer. OK, enough with the re-iteration already already.

The meaning of Presence, has started to morph into ‘availability and willingness to interact’, and to that end a lot of discussion is being put into handling contacts, grouping them, and puttings rules against VIP versus double glazing people. And the bottom line is, I’m not sure about this.

So, in the instance I am away from my desk, I would pitch my voicemail against ‘presence’ technology as being most useful. Give me a call, and I’ll decide on the spot whether I’ll answer you or not, and, unlike a rules engine, I won’t ever get it wrong.

So, if I really can’t talk to you now, then leave a message and I’ll get back to you as soon as it is convenient. Of course, leaving a voicemail should in itself move the conversation onwards, so this isn’t a waste of either your or mine time.

I think that’s a lot easier than maintaining a presence engine via some small mobile screen that you forget to check every ten minutes, don’t you?

So couldn’t the communications industry just define Presence to mean Whether I’m at my desktop, or not?

It’s not perfect, so perhaps we should think more about how conversations are initiated, a more formal process that simulates that so repetitive IM, “can we talk?” 

That permission element is going to be all important

Unified Communications as a concept has a number of interfaces around which technologies are consolidating

Interfaces are converging around Messaging, Real Time Conversations and incoming call handing - complemented by applications being ‘enabled’ for communications.

Speech Recognition (the user independent variety) is another method to access Unified Communications technologies, usually from a mobile telephone, but being new, it is difficult for companies to position different solutions and make buying decisions.

So, one of the first questions I would put forward is ‘how many speech interfaces does a user want?’

Do they want to call in and access and handle messages and contacts, call another system to set up their voice/emailbox and change their incoming call handling settings, and perhaps yet another number to access their Speech enabled application. Perhaps a different server could run the speech driven company directory transfers?

Perhaps not.

Each speech platform will have it’s own ‘logic’ in terms of users interfacing, so learning more than one will likely be more than users can stand. This should be a way of filtering out some one trick ponies!

This post is incomplete, but then so is the industry

I’ve mentioned before that the key to understanding Unified Communications (all of it) is the software interfaces presented to the user. (You may notice I don’t mention voip at all in the following, it’s about users).

Unless the user is going to adopt functionality, there is almost no point deploying it…..and by definition the more interfaces there are, the more difficult adoption will be (how many training course will users go on).

Once the required interfaces are defined, it’s so much easier to put the technologies in the right place, or in the right box, so to speak, and so I have been framing business requirements around the GUI.

The reason I’m bothering here is that I have met with customers who have in front of them very interesting new products - but they overlap so much, and so how does one decide?

It can be as tricky as hell, as current comms software technology on offer includes

Messaging

• Email
• Voicemail
• Fax
• Text Messaging

Real Time Conversation interface,

• Instant Messaging - are you at your desktop
• Telephony - are you on the phone
• Conferencing, Audio dial in, dial out, desktop sharing, webinars
• Video conferencing, are you at your desktop

You can see overlaps wherever you look with UC - but there will be ‘at least’ two interfaces for users - as the ‘button’ requirements are different for messaging, to that of real time.

Messaging buttons; - Address, Send, receive, store, mark as urgent, copy, forward, and so forth

Real Time buttons; - Receive contact, Make Contact, whether IM, call, or video, include someone else in the conversation, transfer, desktop share, present, record, and so forth

• Messaging interfaces are reasonably well defined
• Real Time Conversation interfaces are in their infancy
• Personal Contact Handling isn’t well defined

However, for framing Unified Communication discussions and decisions, each user will probably have at least the first two initial interfaces for personal productivity.

A third interface should exist, but doesn’t yet (?)

Personal contact handling

• This doesn’t yet exist as a recognised ‘desktop based user interface’ category - although network based Grand Central is a good start in showing what will be possible
• Call routing and handling, where should calls go, onto which device, at what time
• Planning - willingness to engage, calendar integration, - Iotum is interesting
• Call processing, what happens to the caller if you can’t take the call
• More loosely defined is a meta directory, routing and capture application such as that delivered by Corebridge - because contact information pervades around all communications solutions, (and existing applications).

It isn’t clear where functionality to control personal contact handling will be interfaced by the user, - most of the above is handled at premises based system admin level currently - but it makes sense if all features to determine the inbound call routing for today, all end up in one interface, (if not provided by a single backend system) to be controlled by the user instead of Admin.

This interface could yet still be provided by a hosted system provider, overlaying and complementing existing site number and mobile number implementations - instead of replacing them completely.

The final interface, enabling existing applications with (the same) communications

As well as providing the primary interface for specific channel technology (show me all my received faxes, calls, emails) All the technology channels above ‘may be’ suitable to ‘enable’ an existing user interface, by line of business - Email a Contact, Fax a contact, Call a contact, record a contact, Text a contact

By way of a small example, although fax is a single technology channel above and sounds simple enough - fax integration can get interesting when requirements appear on the horizon to integrate into Exchange Outlook, or Lotus Notes, then to the telephone system (TDM or IP), then to unified messaging (forward the fax to a local machine) then SAP or Oracle line of business applications, then back end integration to hard copy Multi Function Devices and onwards archiving to the industry flavour EDM.

Nobody said it was simple.

At this point, Microsoft Sharepoint usually comes up in the conversation as a replacement interface to all the existing applications, so UC takes on another interface….and so it goes on, much to the user’s consternation.

There’s a play on words about ‘users’ being addicted to existing interfaces, but that would be cheap.

How to choose

Enabling lots of interfaces with a technology flavour tends to point towards best of breed technologies instead of an all-in-one UC solution.

Generalising: wide ranging applications just don’t go very deep in my experience, and ultimately they don’t generate enough ROI, and therefore sales, to justify the development resource to integrate into every interface (converge) that may be required in every industry.

All in one solutions, may be fine in small organisations where the user requirements are very focussed and not wide ranging.

In larger organisations with wider ranges of activites, each messaging ,or real time conversation, ‘technology’ should support the most possible interfaces you can think of, (and multiple interfaces concurrently).

This almost defines a best of breed requirement for each technology - particularly when in a sector that is in acquistion mode - and if you are adopting UC, it won’t be long before you’re in a sector likely to be acquisition minded according to some sources -technology adopting sectors see most acqusition.

So when you acquire a major competitor next month and have to incorporate whatever they are doing into what you’re already doing, you want multi-interface communication products.

It’s plain that in these unforseen circumstances, functionality needs to be priced in a modular fashion, according to the interfaces required and the inherent value of doing so (each interface is it’s own individual case for each technology).

So, am I proposing that in order to have fewer user interfaces, there is a need for more technology boxes and management?

It’s debatable I suppose, but probably.

I’ve seen non specialist technology suppliers integrating essentially as ‘lip service’ to get the original deal, and then support evaporates over the period, especially when the next app needs enabling, and you have to start looking to replace again.

I’m lucky enough to see the best of breed technology I supply stick over a very much longer period.

If I’ve missed anything then it’s likely to be mobile - but that’s a longer conversation.

It’s been a long day, but is there anything else I haven’t thought about?