Last time I wrote about call center software from the switch provider's point of view. This time let's look at it from the application provider's point of view. Note that I'm making way too many simplifications and omitting many things as this is a complex architecture. Like many other things in life, a call center is conceptually simple but the devil is in the myriad of details that can bring a grown man to cash in his stock options and leave.

From the application provider's standpoint, a call center is really just an application that agents use to record information. For the most part the app doesn't care whether the agent is using a phone or email or can-and-strings, as long as the agent is hitting the right buttons on his keyboard and as long as the application is getting data from the call center hardware. The app, whether it's just a script engine that agents follow blindly (by script we mean scripted conversation, not a Perl script) or something more sophisticated like a real order entry application, records information in a database, both orders and statistics.

Many call center applications have grown up from the simple base stated above. There are a couple of places to grow into: upwards as the application does and more things, integrating better with back-end applications like human resources and warehouse management; or downwards as the application tries to integrate more with the switch, replacing the switch provider's software. But here's where the application provider gets into trouble. They're not big enough to make and promote their own back-end systems or database or switch software. So they instead try to integrate seamlessly into all of those environments. This is very hard.

A digression. A few years ago (and carrying on into today, though not as strongly) the new big thing in Information Technology was the best-of-breed philosophy. After getting locked into proprietary solutions which inevitably resulted in one good product and a bunch of bad products you had to buy so that everything worked together, businesses started to demand more and more on standards and standards compliance. Theoretically with standards different pieces of software from different providers will integrate easily. You're not going to have a team of consultants writing one-off glue programs to make all your applications work together. A brittle solution that breaks when any app is upgraded.

So businesses that they could then buy the best word processor, the best spreadsheet, the best database, the best fombleboozer and they would all work together and be interoperable. That never really came to pass. For one Microsoft refuses to play that game which makes the desktop applications hopelessly muddled. For the other in the back-end space the major players did the same thing as Microsoft: adhere to the standards but then improve upon them and intermix the improvements so that customers have to use the improvements unless they're very careful. At that point you have them locked in once again.

This is the situation that call center application providers find themselves in. There are no good standards that everyone follows without adding their own improvements (and to be fair, a lot of the improvements are really helpful additions to the standards). So a call center application will never be as tightly integrated to the back-end or switch as a separate offering from the back-end or switch providers. Luckily for the application providers, most back-end and switch providers can't write good application software (and some have resorted to buying small call center application providers to get that good software, but it does take time to ingest an acquisition).