By Trevor Baca, VP Software Engineering


Security best practices demand two-part identification. Credit card plus signature. Banking card plus PIN. Or, if we're in the UK, chip plus PIN. The principle is clear enough -- identity theft of a single piece of information happens too easily but theft of two loosely coupled pieces of personal information should be much more difficult.

Welcome to text messaging as one piece of the two-part security paradigm.

The people at Chase bank have been leaders in innovative uses of communications-enabled business processes (or CEBPs). Deposit more than a user-configurable number of dollars and Chase's automated prompting system can dial your cellphone and let you know. Withdraw more than a user-configurable number of dollars and Chase's automated IVR systems can dial your cellphone and leave a different message. Automated alerts are a cost effective customer experience extra with no additional overhead in call center costs.

So how are Chase working in text messaging as one part of the two-part security paradigm?

Log in to any Chase account online and click the link that says that you forgot your username or password. Nothing too exciting about username retrieval. But in Chase's new implementation, you can click a radio button to have an "activation code" sent to your phone by text message. The incoming message reads something like "Text from 242-733. Fr: Chase Online. Activation Code is XXXXXXXX. Enter is now online when prompted or in password field when logging on. Text Stop to STOP, Help for support."

It's a small detail and a great idea. We know that people look at text as the communications medium of intimacy and one-to-one contact. So it's a reasonable extension of the feelings most of us have about text to use the medium to convey small bits of personal information. And allowing "STOP" and "HELP" escape routes demonstrate extra concern for customer service in the process.

By Trevor Baca, VP Software Engineering


In parts I and II of this series we looked at couple of ways to make business go faster. Part I explored CSC (critical support conferencing) which is a Jaduka prerelease that we use to get our support team on the phone fast. And in part II we looked briefly at an install of Jaduka WARNS (weather alerts & realtime notification system) and saw how to make school and jobsite closures due to bad weather take only seconds. Both CSC and WARNS are communications-enable business processes. Both CSC and WARNS use voice to reduce human latency (the time it takes to get your team together and ready to work). Both CSC and WARNS make business go faster.

This is the third and final part of our series on enterprise collaboration. And in this post we look at Jaduka buyer verification services (BVS). BVS is the muscle behind our credit card fraud protection solution, which you can read more about here.

Fraud protection can be a pain. My mother's joked for years that all she has to do to get credit cards blocked in December is get her Christmas shopping done faster than other folks. Nothing more irking than restrictions on your credit cards that you didn't ask for and that you don't need.

But the other side is equally bad. Identity theft is a serious problem. And, despite massive attention from the press, the problem seems to be getting worse rather than better.

So what to do? How to help banks ensure the purchasing freedom of moms everywhere while offering solid customer protection at the same time?

Later this year we're working to trial a new opt-in buyer verification service with a banking partner. The service is scheduled to be available to individual cardholders on a strictly opt-in basis. Cardholders get the option to add themselves to a safety and security list maintained by the bank. Once on the list, cardholders get a call to their cellphone every time a purchase on their card exceeds a fixed dollar amount. The call prompts the card holder to enter "1" to verify the purchase or "2" to reject the purchase. A "1" signals that all is well. A "2" hooks into the bank's existing fraud control services. Unanswered calls trigger the system to try back in a configurable number of minutes.

Leveraging Jaduka BVS in this particular context makes good sense to me. We're working out integration details for the trial now and there are a surprising number of variations on the basic premise. Should the customer's PIN enter the verification callflow? How many times should the system dial for confirmation before giving up? And, of course, what are the smartest ways to integrate with the client's existing call center fraud protection resources?

But the work is looking great. And I'm a huge fan of the opt-in approach of the trial. Mom doesn't ever have to sign up for the service if she doesn't want to. But if she ever does decide she wants the added security, it's there.

And there's our third and final example of reducing human latency in a plain old business process. Fraud protection has gotten better -- and faster -- since the 1.0 Web. Automating major portions of the fraud protection workflow with Jaduka BVS should make it even faster.

By Trevor Baca, VP Software Engineering Remember snow days? Watching the 6:30 am news January mornings for school closings at the age of 12 was captivating. Plant and jobsite closings later in life are just a pain. Corporate phone trees grow large and become difficult to maintain. Delivering anything other than a "site's closed" message can be tricky -- how do you make sure everyone in the phone tree delivers the right message the right way? Message consistency is that last thing you want to worry about at 5:30 am on a bad weather day. And auditing is tricky. How do you know for sure that everyone was supposed to call actually made the right calls? Managers shouldn't have to ask these questions. Phone trees to shut down a jobsite (think construction and utilities here) are, on the one hand, the most basic thing in the world and, on the other hand, a completely unnecessary source of risk. Scripting can fix this. I've been blogging about the different Jaduka APIs recently. And the Weather Alerts & Realtime Notification System or WARNS -- which you can read more about here -- is another good example of how we've been able to communications-enable a plain old business process. How's it work? You're the decision-maker at utility company. Uou've got jobsites in New Mexico and Arizona. Bad weather rolls around and you've gotta make three site closings. You dial into the 800 number that we've set up ahead of time and the system prompts you to record your message. "Sites at ..., ... and ... are all closed for Friday the 29th of February ..." You listen and rerecord a couple of times until you've got the message exactly right. The system prompts you to press nine when you're ready to send. You press nine. WARNS dips into database tables, pulls out home telephone numbers, and dials all on-site personnel at home. "Does the system call everyone at once?" People always want to know. We do it in blocks of about 92 employees at a time. It's very fast. And there's a bit of coolness on the receiving end of WARNS, too. Employees hear their phone ring, pick up, and hear a prompt. "Incoming jobsite closure message from the ... Weather Alerts & Realtime Notification System. To accept, press 1. To reject, press 2." Employees press one and hear your message: "Sites at ..., ... and ... are all closed for Friday the 29th of February." You configure your own repeat counts and so your message probably plays two or three times. And all keypad presses -- all those 1s and 2s your employees press when they answer the phone -- report back to the WARNS administrative webpages in realtime. Which means you always know who got your messages ... and when. The name of the game with WARNS and our other CEBP solutions is reduction of human latency. Human latency is a cover term for the amount of time it takes to bring your team members up to speed and able to help out. WARNS reduces the human latency in traditional I've-called-you-now-you-call-the-next-guy phone trees enormously. The result is that everybody finds out about site closures at pretty much the same time. And you completely eliminate the wait-period where parts of the team know what's going on while other parts of the team are still in the dark. The fact that tracking reports tell you who answered the phone and who didn't is definitely useful. But the real draw is the enormous reduction in human latency. Reducing humany latency helps make sure everyone knows where they fit. And fast.

By Trevor Baca, VP Software Engineering


It's Tuesday night after the Wisconsin primaries last week. After hours. My cellphone rings. I answer and I hear a welcome chime and then a prompt. "Jaduka after-hours support. Press one to join a critical support conference. Press two to reject." I press one. And the Jaduka after-hours support system bridges me into an a conference call. The conference call started automatically just seconds ago.

I wait for a minute and the different members of our on-call support staff join the conference call one after the other. What triggered the conference call? Turns out traffic peaked on the network at exactly 8:12 pm. On a Tuesday? Tuesday night's an unusual time for a spike in traffic on any phone network. But then one of the on-call engineers speaks up. "They just announced that Wisconsin went to Obama. By double-digits."

Real-world events -- like New Year's Eve, American Idol, and, apparently, the Wisconsin primary process -- can generate lots of phone calls. If you run part of the phone network this is something you need to watch out for. A sudden spike in traffic can mean sudden strain on your network when you're talking about thousands of calls. Which is what we saw last week on Tuesday night. Traffic dropped off a minute later and we finished the conference call and went back to our evenings.

Critical Support Conferencing (or CSC) dialed us all automatically and we were able to meet in seconds. It's a neat system. It helps us manage our network. And it's fast.

So how does CSC work?

---

The answer lies in the Jaduka APIs. We have a bunch of APIs (or application programming interfaces) at Jaduka. You can check out the public API at the Devzone. And we have an even higher-octane API for our enterprise partners. And then we have dozens of other APIs that we use for all sorts of stuff internally. Our internal APIs aren't quite ready for public release. But we use them all the time. To do stuff like start conference calls.

The Jaduka Conference API -- which is internal only right now -- lets our own developers start and stop conference calls. With a single line of code. It's got room for several dozen people per call. And it's perfect for getting a bunch of people on the phone at one time automatically.

On Tuesday night our database monitoring system noticed unusually high levels of activity for that time of week and triggered one of our maintenance scripts. The maintenance script looked up cellphone numbers for all six members of the support team and then dialed all of us. Everyone pressed "1" to join and within seconds we were all working together. Working together in one "place". One very virtual place.

---

Critical support conferencing helps explain what we mean when we talk about communications-enabled business processes or CEBPs. CEBPs are just plain old business processes where it makes sense to automate communication. Getting staff on the phone to look at a potential problem is a good example. Plain old business process where we can automate communication.

CSC isn't yet a Jaduka enterprise service ... at least not yet. But interest is building. And it looks like we may do a test flight of enterprise CSC deployments soon. Stay tuned soon for more enterprise collaboration ...