Proven Database Solutions Are Not So Common

August 11, 2008

I was traveling this past week (on vacation actually) & while waiting in the Dallas/Fort-Worth airport to catch a connecting flight I overheard a pretty sad telephone conversation between two engineers that really made me appreciate what our teams have designed & developed over the past 10-years. The conversation between the two software engineers went something like this…

“We are getting a number of customer complaints that the application keeps crashing their systems. Have you looked at the database queries that are running? You know the database is our Achilles’ heel man. We can’t support all that many simultaneous queries. Maybe we should trying queuing up the queries so they don’t overload the system? Yes, I know if we do that it will take longer for things to run, but better they run then crash all the time, right? You know table joins may be a problem too. The database just can’t handle queries that require table joins. Maybe the queries we are running are just too big… I don’t know man; we’ve got to do something soon to fix this. OK, try some stuff & get back with me. I’ve got to tell our customers something.”

I can’t tell you all how relieved I was that I wasn’t in this company’s position. My jaw about hit the floor when I heard the guy refer to their database as their Achilles’ heel. If there is one thing that our customers don’t need to worry about it is our database solution. Handling large volume database transactions is one of our core competencies to say the least. Our database solution handles millions of transactions daily without skipping a beat. These transactions aren’t from a single source either. We handle database requests coming from over 250 API methods, customer service web sites, reporting traffic, & obviously from systems applications handling call processing.

Transaction processing is just another one of the many solutions & services we offer & stand behind. We aren’t trying something new or untested either. We have a proven solution that continues to provide our customers with the reliability & scalability that enterprise solutions demand.

To conclude, I did consult with this gentleman about Jaduka’s Transaction Services API. He seemed overjoyed to hear that we had made our solutions available via simple Web APIs. His company obviously doesn’t have the time, money, or resources to develop a high volume database solution on their own & we’ve got a call later today to discuss this opportunity in more detail.

Advertisements

Plugging Starbucks in to Telephony

August 5, 2008

Every time I walk into Starbucks I’m hit in the face with a new sales promotion. Howard Shultz & crew are doing all that they can to turn Starbucks around. If successful, their current promotion will have consumers visiting a Starbucks twice a day. The approach with this promotion is that if the consumer returns with their morning receipt after 2:00 PM, they will be offered any grande (that is a ‘medium’ for you folks that have yet to pick up on the Starbucks lingo) iced drink for $2.00 instead of the usual $3.50 & above price tag.

I can’t help but look at a promotion like this & imagine the benefits that Starbucks could achieve if they would simply use communication & transaction based technologies to market & manage this promotion. The problem is that too many companies perceive such an integration to either be impossible, or if possible then too expensive.

My morning coffee was paid for using my Starbucks credit card. Talk about a loyal Starbucks’ customer… I earn Starbucks points with all of my purchases instead of miles or cash back. Since Starbucks has already “signed me up” why not alert me of this promotion via text message or better yet with a phone call rather than catching me only after I’ve walked through their doors? It wasn’t until I purchased my coffee & then asked for my receipt that the clerk even notified me about the promotion. What if I wouldn’t have asked for my receipt? Would the clerk even have told me about the promotion?

Even if I do decide to return later today it is now my responsibility to remember the promotion & I’m also forced to keep track of my receipt for the rest of the day. With the use of communication & transaction based technologies I wouldn’t have to do either. Since I’m already a loyal customer & I’m using a Starbucks card I shouldn’t need to hang on to my receipt. My purchases could be tracked on-line & when I return later in the day my Starbucks card could be scanned to validate that I made a purchase earlier that morning. As for forcing me to remember the promotion, since Starbucks already has my mobile phone number I could be sent a text message or recieve a voice call around 1PM to remind me about the promotion. Both of these solutions could easily be enabled through the use of Jaduka’s Voice & Transaction Services APIs.

Again, it’s obvious that too many companies do not realize how easy & inexpensive it is to add these types of technologies to their applications & promotions. This is especially true for companies wishing to add voice.

The Public Switch Telephone Network (PSTN) for too long now has been inaccessible to companies that do not have huge telephony equipment or deep pockets. With Jaduka’s Voice API we have removed these barriers & we have made it easy & inexpensive to plug in to that telephony network. With our APIs you can make your applications & promotions heard.