Enterprise Voice Mashups
 Money and Business Case
Faster, cheaper and happier

 Would you like some Paprika soup?
Or, why we have it backwards.

 So, exactly what is a mashup?
A Vist from the Jargon Police

 Architectures and Solutions
What does it really look like?

 Real World Examples
My favorite health care examples


Money and Business Case
 My story…
My name is Thomas, and I’ve been a telephony

developer for 18 years.
 Nearly always, new telephony service offerings
fail in the marketplace
Customer education - don’t know it exists

Customer habituation - won’t change my habits

Expensive to deploy

Vanilla services == commoditization

 There’s little to no integration between the PBX
and the business process
Walled garden vendors make it hard

Our own view points make it hard


Let’s do a thought experiment
What happens when you could, at
no real cost, blend in real time
communications with the
business process.

Faster
 What happens if you integrate real time
communications in the enterprise?
 Businesses run faster
Find the right person

Eliminate delays in process

Push process outside the firewall

 Real Example
Remote worker automation…

How many forms do remote workers fill in?

Instant, on demand scheduling

What’s the universal interface? The phone

 The business case is intensely unique to the
business

Cheaper
 What happens if you integrate real time
communications in the enterprise?
 Businesses are less expensive to run
Eliminates wasted effort

Eliminates on-demand automated work

Increases location independence

 Real Example
United Parcel Service…

When you need a signature, they make a call

When you miss a delivery, you can reschedule

When they need to reroute in an emergency…

 The business case is intensely unique to the
business

Happier
 What happens if you integrate real time
communications in the enterprise?
 Customers are happier
Customers like control

Customers like visibility

Customers hate to learn

 Real Example
I’m flying JetBlue today…

My flight is cancelled - send me a text with options

When I call back, know who I am and tell me what I

need to know.
The customer needs no education whatsoever.

 The business case is intensely unique to the
business

Would you like some Paprika
Soup?
 We are a bunch of voice engineers, writing voice
applications, sitting in a voice show learning
about … voice
 Voice is obviously important to you…
I even married a speech pathologist.

 What if voice isn’t the most important thing to
your customers?
Guess what… I’ll take the bet that it’s not.

 My contention: voice is not the meat, it’s a spice.
 Due to natural evolutions in technology and
markets, voice became an end unto itself, and
that’s a mistake.

To the man with the
hammer…
 Every problem looks like a nail
 To date, we only owned hammers.
Walled gardens of technology

Vertical integrations by vendors and providers

Huge learning curves keep others out

 Other tools have now arrived
Comparatively, PBXs are now free

Comparatively, service providers are no longer

capital intensive
Comparatively, the walls are down not only

with telephones, but with the network

What happened? Why now?
 We have a radical lowering of barriers to entry to
telecom development
The investments made in 1997-2007 in telecom and

web technologies
The growth of Web 2.0 culture

 Smaller business cases become supportable
Because it’s so inexpensive to deploy them

 The Long Tail hits telephony
As it hit shopping, music, television, etc.

 Radical changes in strategy required
Small is the new big

Large vendors must strive to be platforms

VAR is no longer a joke. It’s real.

 The advantage is now closeness to customer.

The Simplest Example
 Would you like to work at Dunkin Donuts?
 Call them up
They have an automated pre-screen line

Designed by an industrial psychologist

If you can sit at a phone for 30 minutes and take the

quiz… it’s a good sign
 Business case?
High turnover == high overhead

Ten cents a minute < Manager hourly wage

Higher Quality Hires : DD tracks success

 Faster, cheaper, happier
Faster : more interviews, better hires

Cheaper : Less turnover, less manager involvement

Happier : Interviewees get nearly instant feedback


The Numbers
Total Mashups : 2312

Total APIs : 511

Mashups Written / Day : 3.5

Last M&A : WeatherBank, Weather.com

Major APIs:

GoogleMaps, Flickr, Amazon, YouTube,

VirtualEarth, YahooMaps, eBay, 411Sync,
del.ico.us, Yahoo

Exactly what is a mashup?
 Mashups are applications that:
Use Web Integration Technologies

Use more than one data or service providers

Serve a niche audience

 Mashups are a “light weight” model
 Mashups depend upon open standards
But even more so, open conventions

 They aren’t silver bullets.
Hard to see VoiceMail written as a mashup

But I sure could see VoiceMail as part of one


Web Integration Technologies
 By convention, mashups use Web Integration
Technologies
 Scripting Front Ends
VoiceXML, JavaScript, AJAX, HTML

 Web Platforms
Ruby on Rails, Python, Perl

 Web Services Component Integration
SOAP, REST for service invocation

XML and JSON for data representation

 Conventions
Mashup developers use common tools, approaches,

languages… clothing.
Nothing is good all the time, including flexibility


Independent Data Sources
 Mashups tend to use content from more than one
source
In fact, that’s where the name comes from

 Classic Mashups
Chicago Crime Map, slut-o-meter, wheel of lunch

 Many successful examples
Expedia, Hotwire, Amazon

 Sharing comes from many angles
Functionality, data source, hosting, termination

 Telephony examples?
Use YellowBook to get physical address from inbound

phone number to shop Amazon from phone.
Use a Where applet to drive Google maps display for

dispatcher

Niche Solutions
 Mashups have an audience, always
The developer knows the audience

 Very targeted, very personal
Mashup developers tend to be individuals or very small

groups
Solves small problems

Of which there are millions. More than that.

 Interestingly, technically mashup architectures
are insanely scalable
Much more scalable than any other available

More reliable as well

My gut tells me cheaper, too - no evidence yet


The Numbers
Developer Team Size : 1-3

Development Time Large : > 1 month

Development Time Small : 1 day

Costs of Web APIs : Free

Costs of Telephony APIs : 2-50 cents

Costs of Tools : Free


Architectures and Solutions
 Two Predominant Mashup Architectures
 Web Integrated Telephony Architecture
Three component Architectures

Where Web 2.0 meets Telephony

 Asterisk / Adhearsion
Asterisk based architecture

Where Enterprise 2.0 meets Telephony


Real World Examples
 Some real world examples
Focus on health care, could be any vertical

All examples are common to providers

Yet need customization

 Congestive Heart Failure
If you can catch the weight gain…

 Morisky Surveys
Four questions that predict the future

 After Hours Dr’s Office
Use any web service, including people

 Pharmaceutical Patient Diary
Quality of data == Quality of study


For more information…
 The Blogosphere
Thomashowe.com

Hinchcliff

O’Reilly Radar

 The Web
Programmableweb.com

Mashable.com

 The geeks
Mashups are as much about society as technology

Mashup Camps

 Your business
Where can you use spice?

Faster - cheaper - happier
