Using CEA Services - Inventory Management example

We have spent a lot of time talking about how to use our CEA Web 2.0 widget features in WebSphere to communications enable your website but there certainly are several other use cases we have provided for. Overall, we are providing three main access points to help communications enable your applications. We provide the Web 2.0 widgets, REST like services, and web services. I wanted to blog in more depth about the CEA services that are available in WebSphere.

First, we have a REST like service. I say REST like because while we tried to follow the REST semantics as much as possible, it definitely made more sense to build some level of affinity logic into the service to tie a HTTP request to a specific server which is participating in the telephony side of the conversation. To build a similar system stateless would have been much more challenging and not perform as well. The service however does use the REST semantics. The verbs are still HTTP methods, PUT, POST, GET, and DELETE and at the root of the URLs are nouns. The REST services use either encoded URLs or Cookies for affinity. These services either send back data in JSON or XML formats depending on which is easiest for the consumer to handle. Here is a great in depth article on the REST services in the Communications Enabled Applications Feature Pack.

Second we have web services. As I stated above, we have challenges with having affinity for these services and needing a call back mechanism in order to get updates about the call state. We used WS-Adressing to deal with the affinity issues by having specially encoded end point references which tie the web services to a backend SIP session talking to your telephony infrastructure. We also use WS-Notification as a way to send updates about a particular call state.
Here is a good reference usage of using the web services to make a phone call.

So, how can these be used? Well, one example as briefly talked about in the video above is in an inventory management system. When the inventory begins to run low, a call could be made between the buyer and supplier using web services so that more stock could be ordered. This could be in addition to sending the appropriate message to the buyer letting them know what is low, what needs ordered, and the account information for the supplier. Now, this scenario could also be handled through REST integration or even using the widgets, it really just depends where the right place in your existing application is to plug in communications.

Retailers need WebSphere CEA

There have been so many times lately that I have been realizing that websites need the WebSphere CEA features and functions. Recently my wife was shopping online and trying to send me links and describe over instant messaging what she was seeing. It was painful and we finally decided we would hold off until later that evening. We forgot that night and looked again at it a day later. That was a sale that was almost lost. Actually, to be honest, the sale was lost...but had we had peer to peer cobrowsing on that site we may have purchased it that first day.

I have also had the experience many times when buying gifts where I knew nothing about the subject matter and had to call a company or visit their store. Whether it was custom jewelry I bought my wife for mother's day or shopping for something for my own mother, there are times I just need more information than I can find online.

After talking to a major US retail company the past couple of days it became evident that our CEA functions when shown were much more amazing. This is why I made the video above, to show this typical experience I have when shopping for something and I need help. But the ability to shop with a friend brings a whole new experience to online shopping and could help drive another boost to online commerce sites. Below I have shown a video describing how that interaction might work.

There are other major areas when seeing something online would be useful when on the phone. For example, last year it was apparent our credit card info was stolen and had to call into Chase and describe the transactions that were invalid. We could have saved time if I could have shown them which transactions through a couple of clicks rather than describing them. But security is a constraint...can you show your customer information without security? How about without a plugin? The CEA FEP does this with security, using the application's current security model. There is no plugin, its all Javascript. It requires some new thinking - but not necessarily new code. :-) We'll talk more about secure cobrowsing soon...

Web communications enhancing interactions

One of the common questions as people are learning about our WebSphere Communications Enabled Applications (CEA) function is if we are trying to replace interactions with "real people" when they see features such as the cobrowsing. The real idea behind CEA is using an interactions via the web to enhance real time communications which could be phone calls or instant messaging. There are several scenarios that we try to show in the demo video below, but here are some of the common issues that a web based interaction could solve in a contact center:

Click to Call:

• Increase efficiency by removing the need for people to type in phone numbers they see on a web site.
  
• Help a user connect to the most relevant help based on what page they are on without having to traverse a voice based menu system.
  
• Provide the backend contact center with relevant user information from their web session.
  

Contact Center Cobrowsing

• Help explain complex data to customers which may be too difficult to describe. Some examples include mortgage closing costs, insurance policy details, order information, financial transaction details, or product information. Customers could print or save the information which could result in them not having to transcribe what the contact center representative is saying.
  
• Teach a customer how to use a specific site rather than just telling them an answer so that they may not need to call again for a similar issue.
  

Two way forms

• Allows a customer to visually verify information rather than waiting for the contact center representative to repeat it. For example, a misspelled last name can take time, cause problems looking up information in the future, and decrease customer satisfaction. Two way forms allows the customer to visually verify what the contact center representative has entered.
  
• Either party in the session could fill out some fields which, if it makes more sense for the customer to do it, can increase efficiency.
  
• Some vital data like Social Security Numbers or Account/Credit Card numbers could be entered by the customer and obfuscated to the contact center representative reducing the risk of critical information being misused.
  

All of these scenarios are in the context of a real time communications session like a phone call. Here is a demo we have shown in the past showing these features in a contact center scenario. Download the beta now from the link on the right hand column and try the application shown below yourself.

Peer to Peer cobrowsing in retail makes for a real coshopping experience?

A couple of days ago, Savio wrote more about utilizing our peer to peer cobrowsing functionality. Today at Impact 2009, we demonstrated WebSphere Commerce utilizing the peer to peer cobrowsing widget to allow for a coshopping environment. In this, Daisy Tan extended the cobrowsing functionality to add instant messaging into a Commerce deployment so that users of that could cobrowse and instant message with one another in the cobrowsing modal window. Perhaps I will get a demo of that integration up later, but for now here is a homemade video of the peer to peer cobrowsing with the sample provided in the feature pack. This shows a simple scenario for coshopping within the application. Our demonstration could have been just as easily a travel planning application, insurance benefits application, or any number of applications allowing two people to view a similar page and use the web as another communication modality. Check it out and let us know what you think! (aside from the fact that I am obviously not a professional voiceover guy or video editor ;-) )

Your applications need a dose of CEA - Peer to Peer Scenario

In my previous post I mentioned that the WAS V7 Feature Pack for CEA Beta can help you create some pretty awesome user experiences for multi-modal online interactions. Well, what does that really mean? I've already covered the Contact Center scenario. Now, let's discuss a Peer to Peer scenario.

Your loyal customers, Savio and Hilary, always use your travel planning website to decide on itineraries and book travel.

Savio is away at IMPACT for a week. This leaves Hilary alone with their two month old. Erik, Savio's wise friend suggests Savio take Hilary on a vacation as a "thanks for putting up with me and rearing our child while I travel". Hilary loves to be involved in vacation planning. But Savio's in Vegas and Hilary's in Toronto (See P.S. below). Savio IM's Hilary and proposes the vacation idea. She's in. Now the tough part. Deciding where, which flight, hotel and car. It's made tougher by the fact that their multi-modal interaction is not linked in any way.

If Savio and Hilary continue the interaction over IM, they're forced to send URLs back and forth to keep track of the itinerary item that the other person is looking at. But then, they'd also have to type "flight #348 will get us in on time" and similar information into the IM application. But switching over from IM to the phone is no better because they still have to describe which page each person is on, (spelling out a URL over the phone...FUN!?!?), and which flight they are looking at etc. Savio and Hilary are in for a poor user interaction no matter how you slice it.

We designed the WAS V7 Feature Pack for CEA Beta to address a scenario of two users trying to jointly make a decision through a multi-modal interaction.

Peer to Peer Cobrowsing
Let's start the same scenario off with a Peer to Peer Cobrowsing Web Widget that is delivered in the WAS V7 Feature Pack for CEA Beta. Savio would click on the "Invitation Link" button on your website and IM it to Hilary. Once Hilary clicks the link, Savio and Hilary would be in a shared session together. There's not software for Savio or Hilary to install to enable this shared session. In fact, Savio and Hilary have individual sessions with WebSphere Application Server, so there's an added layer of security. Calling this feature Peer to WebSphere Application Server to Peer, while perfectly okay with the IBM Naming Police, seemed cumbersome. Ease of use and security? Check.

With this shared session both Savio & Hilary can take control and direct what is shown on the other person's browser window. Both can highlight elements on the page for the other person to see. Vastly improved user experience? Check.

And of course, if either needs more information before deciding, they could use the Click to Call feature enabled by the WAS V7 Feature Pack for CEA and enter into a joint session with one of your customer service representatives. I described this scenario before.

Want to learn more?
Get the WAS V7 Feature Pack for CEA Beta here and the Getting Started guide, part of the Library materials, here. Also, here's a good description of the widgets from Erik. Finally, if you need a copy of WAS V7, you can get a trial here.

Let us know what you think!

P.S.: Hilary and I planned our last trip sitting beside each other, with our individual laptops scouring Expedia for info. It was painful to keep track of the itinerary item that the other person was suggesting. So, while the scenario above describes two geographically separated users, I'm certain it'll apply to two users sitting beside each other on a couch! What that says for our society is a different story ;-)

Your applications need a dose of CEA - Contact Center Scenario

In my previous post I mentioned that the WAS V7 Feature Pack for CEA Beta can help you create some pretty awesome user experiences for multi-modal online interactions. Well, what does that really mean? Let's start with a common scenario.

While searching for a life insurance policy online a user might want to call a customer service representative (CSR) about discounts since her mortgage is held by the bank. More often than naught, the CSR wants to point the user to more information on the bank's website. But here's the dilemma. The user and CSR are involved in a multi-modal interaction, but there's no synchronization between the two modes of communication. If the CSR wants to direct the user to a specific page on the site, he must tell the user "okay, go to the homepage, on the left navigation bar, click Other Offers and then scroll half way down the page, look for a link that says...." Agreed, that's an ugly interaction.

When the user decides to purchase life insurance, the interaction is no prettier. While the user and CSR are speaking on the phone and both have browser windows open, there is no linkage between the two modes of communication. The user still has to speak certain information which the CSR must transcribe into the application form. There's no visual way for the user to verify that the CSR has transcribed the spoken information properly. Try saying "Savio Rodrigues" and the person on the other end of the phone not transcribe "Fabio Rodriguez" or "Flavio Rodriguez" or "Sabio Rodriguez". Not cool.

We designed the WAS V7 Feature Pack for CEA Beta to address a scenario in which a user and CSR are involved in a multi-modal interaction prior to the user making a decision.

Click to Call
Let's consider the same scenario with a Click to Call Web Widget that you can embed in existing and new web applications.

Unlike third party hosted Click to Call offerings, the Click to Call feature in the WAS V7 Feature Pack for CEA Beta can be completely integrated into your application. No need to spawn another browser window or advertise your hosted provider's service. Integrated and consistent user experience? Check.

Next, our Web Widget is integrated with your telephony infrastructure (so far, Cisco & Nortel). Why pay a third party Click to Call hosted provider per minute fees for calls when you can leverage your existing telephony infrastructure? Lower costs and driving higher utilization of existing resources? Check.

Finally, any information that you want to share between the user and the CSR through the Click to Call session, such as login information or account numbers, does not have to go through a third party. Increased privacy & security? Check.

Contact Center Cobrowsing
Okay, you added a Click to Call widget to your application, now what? Well, your customer enters her phone number and clicks on "Connect". The result is a shared session between the user and the CSR (through WebSphere Application Server). Oh, and there is no software for the user or CSR to install. Security and ease of use? Check.

With this shared session both the CSR and the user can take control and direct what is shown on the other person's browser window. Both can highlight elements on the page for the other person to see. No more having to say "scroll half way down the page and look for the link to the right of the picture of a monkey". Improved user experience? Check.

Two Way Forms
Next up, the dreaded filling out of forms over the phone. But have no fear. Since you have a shared session between the user and CSR, there's no reason that the form can't be displayed to both parties. But why stop there? The Two Way Forms feature of the WAS V7 Feature Pack for CEA Beta lets both parties enter data into various elements of the form. You can even restrict the data shown in a form field between the CSR and user. For example, the user could type in and see their full credit card or social security number, while the CSR would only see the last 3 digits. The user can even click to confirm that individual form field data was transcribed correctly by the CSR. Fewer frustrated users? Check.

Want to learn more?
Get the WAS V7 Feature Pack for CEA Beta here and the Getting Started guide, part of the Library materials, here. Also, here's a good description of the widgets from Erik. Finally, if you need a copy of WAS V7, you can get a trial here.

Let us know what you think!

Your applications need a dose of CEA

As Erik posted on Friday, the IBM WebSphere Application Server V7.0 Feature Pack for Communications Enabled Applications Beta (WAS V7 Feature Pack for CEA Beta) is now live.

Why should developers care?

Skills Reuse, Improved User Experiences & Lower Costs:
Well, with your existing Java skills, the WAS V7 Feature Pack for CEA Beta can help you create some pretty awesome user experiences that improve the effectiveness of multi-modal online interactions and reduce costs. The WAS V7 Feature Pack for CEA Beta targets scenarios where users are interacting with each other through multiple modes of communications.

We've all been on a website, or for that matter, any web-based application, trying to find the right information before making a (purchase) decision. Often, multiple modes of communications (i.e. phone & website; instant messaging & website, etc.) are needed to obtain the information and make the decision.

Over the next two posts (here & here) I'll discuss two key scenarios where the WAS V7 Feature Pack for CEA Beta shines. Saddle up...