PK4 – OnDemand at its best

Recently, we lost a customer database. Yes, we lost it – multiple servers crashed, backups were corrupted and so on: net effect, one particular customer lost all their data. But that’s not the point of this story, because we recovered all their data, bringing them back to Production in 24 hours. The point of this story is about perspectives – how people behave in a given situation and what we can learn from that. After all, a good CRM is all about reflecting human behaviour!

So anyway, like I said, we lost the database late one night, after the customer’s users (a call center that truly tests our cluster performance) had knocked off for the day. Our engineers identified the issue right away, worked through the night and got things ship-shape. Along the way, our Engineering Manager was talking to a number of people who were affected by the outage – and some who were not. The first person we called early in the morning was the manager who runs the call center. You know what his reaction was? He said (in Tamil): “OK, so you think you’ll get all my data back. But how are you going to deal with your other customers?” Luckily for us, it was only his mega-tenant database that was affected, but the way he asked that question, it very obvious that he was truly concerned – for us. He was worried that we would be under the gun with lots of other people. And he was expressing his solidarity with us in the most direct way possible. That really got me thinking: after all, at the end of the day, we are vendors to him. His feeling worried about our future is a reflection of his trust of us as a vendor, so that’s heartening. But his feeling for us as individuals is much more important: it is a reflection of his bigness of heart. And that’s not just heartening, it is inspiring.

Another call that Partha (our Engg Mgr) made was to a relative – a relative whom I have never met, but to whom Partha has spoken about me in passing. His reaction was very different – and as interesting. He asked: “Did Kishore yell at you?” To him, coming from the more traditional work-environments that he has seen, the reaction of the “boss” was critical. Partha’s response to that question is as inspiring as our customer’s – he said “No, but that’s not the point; we should be worried about the customer, not about Kishore.” Now, don’t get me wrong: I’m sure I can be nearly as nasty as Hari Sadu if I try. And I’m sure Partha knows that. But his response showed true professional maturity: when such a crisis occurs, one must worry more about how the customer is affected than about how one’s own boss will react. Partha’s belief is that focusing on the customer is better for his career than focusing on his boss. And it’s better for his boss’ career, too!

Net effect, a lot of learning, not the least about the technology we work with. But that’s what’s fun about our SaaS CRM business: we learn interesting things even in the adversity of a server crash!

Nearly every time one of us presents Impel to larger prospects, one key question that comes up is “How about customization?” Impel is very configurable and provides many ways of doing things without paying for custom work, but there come times when customization is inevitable. Particularly for the medium- or large-sized business that has processes in place – the CRM solution needs to reflect at least some of that. And that needs customization. There’s the 64-lakh-Rupee question – Kaun banega programmer? We guys, who own the product? Or a partner whom we appoint? The way the market works, companies that own products don’t take on customization. They hand that off to partners who will make the product work exactly the way you, dear customer, want it to work. That’s the way VCs like product companies to execute, too – build the overall product and let partners work with customers. That way, you’ll build an “eco-system” around your product. Lots of programmers out there, working for lots of software companies, will be singing paeans to your technology, since their own livelihood is tied to your product. What could be better for a product company?

The question, IMHO, is not what is better for the product company but what is better for the customer. The partner has paid gobs of money to be “certified” on the product and his/her livelihood stems from the hours s/he puts on the work. So s/he has a built-in bias to raise rates and increase custom-work hours. The increase in hours may not happen intentionally, but let’s face it, the partner is a service provider and would like to take as little risk as possible in estimating a job. And, having already signed up for the product, there’s little risk that the customer refuses to work with that partner. So it’s not surprising that “implementation” takes twice the money that “license” or “subscription” does. Net effect, there’s a whole eco-system built – on the customer’s money and time.

Here at PK4, we take a different approach, something we call “Principal-driven Customization”. We take on complete responsibility, both for the Subscription and for the Customization. And we do that for the many years that the customer uses Impel. We do involve partners, but they either sell Impel or provide us contract resources – they do not estimate an implementation and then bill the customer. So we have a very strong bias to keep the customization work low, for the following reasons:

• We begin with the premise that, if Impel is not valuable as it is for at least half the work-force planning to use it, it is not a good fit for an SME. Being able to configure – not customize – Impel in a couple of days for half our prospect’s users is a critical barometer for the ultimate success of our implementation. Compared to their large-company colleagues, SME managers are typically more cost-conscious and less willing to wait for custom work to complete. So our ability to provide “immediate gratification” is very important.
• We are in the business of SaaS Subscriptions, not Custom Services. So our intent is always to reduce the amount of custom work we do for a specific customer and, instead, build generic solutions that we can use in various contexts. While this takes more thinking, it actually takes less work overall, since the people who do the thinking are the people who built the product in the first place.
• Because we think of each requirement as being applicable to multiple contexts, we also wind up charging for less hours in any piece of custom work we do. After all, we know that every piece of code we write for a customer will ultimately increase the value of our intellectual property.
• We recognize that the more we delay an implementation, the less we make on the subscription. And subscriptions are what we’re after as a company. So we work hard – and smart – to get our customers up and running as quickly as we can. And we do that by using a combination of configuration and customization.
• The traditional wisdom is that product companies must not “sully their hands” with services, but we believe that such an idea is irrelevant in the Indian context. Here, people have built huge, very successful, hugely valuable companies in the Services space. They’ve obviously done something right! Being worried about having a large workforce is typical in a Western context, where the cost-to-company of most employees runs to over $ 100,000. Even with the galloping salaries in India, we’re not yet there yet, recession-proof growth notwithstanding!
• Ultimately, regardless of all the theorizing, we believe that if it helps our customers grow, it is a good thing to do. And our taking on the onus of custom work is good for our customers, not only when they sign up but later, too, when their businesses grow and they want to do more with their CRM. Yes, it puts pressure on us to deliver not just a robust CRM solution but one that is customized, too. But that’s part of the deal – if it’s good for customers, we’ll do it.

Our approach to customization, then, is similar to our approach to our product: Make it work in the Indian context. So here’s what our engineers will say when someone asks about customization: Main hoon na.

Of late, we’ve seen a couple of interesting prospect responses comparing SaaS and In-premise software. One is the idea that SaaS and In-premise work out to about the same cost over the “long run”. The other is that in-premise vendors, too, include updates to their software, much like SaaS vendors do. We didn’t see these arguments earlier, since we largely sell on a “pull” model and not a “push” one – prospects will have worked out the benefits of SaaS over In-premise before they talk to us. But in the bigger deals, managers bring up these issues in conversations – to beat us down on price, if nothing else! In one case, a prospect told us that an in-premise competitor had quoted Rs. 30,000 per seat plus Maintenance. When questioned about TCO compared to SaaS, the other sales guy sagely (Oops! Freudian slip!) said that “over three years we’ll all wind up costing about the same – I can send you an Excel spreadsheet about it”. Now, I normally don’t react to this kind of crap, since it is so obviously untrue I’d be wasting your time talking about it. And there’s so much detail out there in the web, I’d be wasting electronic ink repeating it all. But this time, it kind of got to me, primarily because of the “update” issue. Here’s why.

Yes, with in-premise software, you do get updates if you buy the Annual Maintenance Contract. But you don’t get upGRADES – what you get are bug-fixes, not enhanced or new features. And that’s a big difference. In-premise software vendors deliver “minor upgrades”, including bug fixes, as part of their AMCs. A major upgrade, though, is priced separately and can run anywhere from 50% to 100% of the original price. So every couple of years, after having faithfully paid for the updates every year, you get socked for nearly your original price for the upgrade. And then you have to deal with the nightmares of installing that upgrade. So much so that companies choose to not upgrade at all till they absolutely have to – they’re that afraid of upgrades upending their business.

With SaaS, on the other hand, both updates and upgrades are incremental and part of the price. So you never wind up having to deal with upgrade nightmares – the vendor does that for you automatically. Hmm, maybe that’s the problem in the comparison – how do you put a value to sleepless nights in Excel?

I’m not done yet – I’m now going to argue that that the amount of additional functionality that you get in a given time-frame from a SaaS vendor is much higher than that from an in-premise vendor. This is not because the SaaS vendor is somehow more committed to his/her business than the in-premise vendor (although that is true of this particular SaaS vendor). It is because the SaaS vendor by design has to deal with lesser operational issues than does the in-premise vendor. With SaaS, we don’t worry about a DLL not registering on someone’s server or a stored procedure not installing on someone’s database. We don’t agonize about a database upgrade script failing because of permissions somewhere, or about needing to do the upgrades within a short-enough time-frame for business not to be affected. The in-premise vendor, poor soul, has to deal with all these issues and more. With all that, s/he has to build truly-useful functionality that customers will like and use. And software is much like pregnancy – putting more people on the job will not necessarily reduce delivery time-frames or increase effectiveness. So it’s not surprising that, in a given time-frame, a SaaS vendor delivers a lot more value than does an equivalent in-premise vendor, updates and upgrades included.

So here’s my suggestion to you if you’re considering your next business app purchase: the pivotal thing is to not be sage about the decision; look at the micro issues and don’t be soft about the questions!

For the last couple of weeks, there’s been a lot of debate in PK4 – about the lunchtime catering contractor (we discuss actual work-related things too, but maybe not with such strong opinions!). People have been getting tired of the predictability of the previous vendor’s menu, so we brought in another vendor today: a restaurant down the street. The food was different, good but inadequate. When he ran out of the fancy curd-rice-with-seasoning, the guy behind the counter mixed curd and rice and doled that out, much to the consternation of late-comers. When he ran out of the pulao, he just removed that serving vessel… you know the drill. So basically, the later you went in, the worse the food was. And that leads me to the comparison with SaaS – I do mean Software-as-a-Service, not Tulsi Virani messing up the food.

As a restaurateur, the new vendor is used to creating lots of dishes, but in small quantities all day. As a catering contractor, he’s got to churn out 500 meals every afternoon, but with at most ten items. To me, that’s the big difference between building a web-app and building a SaaS app: the focus on Variety and not Volume. Putting together a regular app that fits the needs of a specific group of users takes a particular set of skills. And once the app is built, you cut CDs or whatever and send it out, so people can install and use it. Every time you ship a release, you can go focus on the next function to build, since your users will deal with issues like the current one not installing, running slow, etc. With SaaS, though, the issues are all yours. With every new feature, user experience is important, but as important is the time it takes to execute, the resources it takes on the server, the impact it has on the database and so on. So instead of delivering a whole lot of functionality and not worrying about how it’s used, SaaS vendors typically build a base set of functions that’s very strong and scalable, then go on to adding more stuff. So while the non-SaaS vendor focuses on variety, the SaaS vendor builds for volume.

The new generation of SaaS vendors have broken through other barriers that in-premise vendors haven’t even begun to consider. Mass customization in the software context is one example, where a single app connected to a single database is made to look and work completely differently for different customers. With Impel, for example, we have small three-person companies logging in from Srinagar and Varanasi, while 200-person companies log in from all over the country. And they all see configurations of Impel that are specific to their own businesses. These configurations are not just field-name changes – they actually change the way some transactions operate. On our Call Center screen, for example, some customers want a change to data in a specific field to automatically kick off an email to a manager, while others want a pop-up screen that shows over a hundred data elements from multiple tables. Each function is critical to the company that uses it, but as far as we are concerned, both functions are delivered from the same Impel app cluster, with the same speed of delivery. So we are now able to very heavily customize for each customer an app is essentially built to be used by tens of thousands of users. That’s like saying that, while the catering vendor delivers 5000 lunches at one shot, s/he can also make sure that one diner gets food that’s less oily, say, than another. Now that would be a business that would eat everyone else’s lunch, so to speak!

Recently, for a call center in Chennai, we rolled out an interesting combination of technologies for what we’re calling the “Impel Call Center Edition”. We integrated Impel with Asterisk, an open-source IP PBX, and Vicidial, an open-source Predictive Dialer. With this combination, a whole lot of possibilities open up for our customers, both in marketing and in customer support.

Let me describe one example. A global consumer brand uses Impel for national marketing campaigns where, beginning with outbound SMS to prospects, the brand gets SMS responses, calls back respondents, sets up dealer appointments and then gets dealers to report an actual sale – all through Impel. With Impel CCE, the brand can more than double call-volume without adding agents. Moreover, they get all the benefits of call-center management with Asterisk+Vicidial, while being able to look at prospects and customers across interactions, with Impel.

In another case (at the Chennai call center), customer service agents connect with customers for a large insurance provider using Impel CCE. Here, the focus is not (yet) on being able to look at customer interactions over time. It is very clearly on high call-volume and traceability, both of which become immediately available with our new roll-out. And, since the insurance process involves so much of data (nearly 200 columns per customer, over 50,000 customers a month!), you need the heavy lifting that Impel can do.

From our perspective, what’s interesting is the manner in which we deployed this solution. We know our own strengths – and weaknesses. While we can build the best web solutions out there, we know next to nothing about VOIP and related technologies. So, instead of trying to build those skills in-house, we worked with a company that focuses on Asterisk-based solutions. We made the enhancements on the Impel side while they did all the work on the PBX and hardware side. That really worked out – we rolled out the first phase of the solution within three weeks of the customer writing the PO. And we were live and being used by thirty agents within hours of roll-out. Our customer tells us they doubled their call-volume the day after we rolled out Impel CCE – now that’s an achievement both vendor-companies can be proud of!

Technically, too, this roll-out breaks the stereotypical SaaS CRM model. Here we have Impel being accessed across the web, but it works behind the scenes with a server that’s sitting in the customer’s premises. And that in turn throws calls to specific agents’ desktops, for both outbound and inbound calls. On the Impel side, a call may need to be initiated due to an incoming SMS, a new campaign being uploaded, whatever – the users don’t see that complexity at all. So the solution now spans at least three physically-separate networks – the mobile network for SMS, the “cloud” for Impel and our customer’s internal network for the VOIP and call-routing. While all this is quite innovative (even if I say so myself!), it is actually just a good use of off-the-shelf technologies. And that’s what fascinates me – the fact that so much can be done with so little. And for so little! No wonder I’m a fan of open source!

Do you have a CRM-related challenge you want to find an innovative solution to? Come talk to us!

If you have time on your hands and are looking to get really frustrated, let me tell you something you can do: you can try using the online payment pages of our telecom service providers or the internet banking facilities of our major banks. This morning, I tried paying broadband charges for a connection. To log on, in addition to your user-ID and password, you need to know which “domain” you are on. You click on the drop-down and you get a humongous list starting from , to . Now, why should I, the customer, have to find a “domain”? Why can’t I just key in an email ID that I know and let the system figure it out? I chuckle at this, figure out my domain, click OK and move on. I choose to pay my bill by credit card, after a pop-up that rounds off my payment to the nearest Rupees, I’m  taken to a Bank payment gateway where I put in my credit card information. After a couple of screens that unnecessarily repeat the information that I keyed in, I finally click an OK button to process payment, hoping this is all done. My irritation wasn’t to end that quickly, though. To make the payment I used an ICICI credit card that is now “secured” via 3dsecure, an additional security measure that needs a couple of other screens. The provider’s mechanism, though, can’t deal with the additional redirection and freezes. Now I’m  back to the first screen where I have to log in (by selecting the domain ) again. This time, I use a different credit card that I’ve not enabled 3dsecure on and the gateway seems to work with that. I now get to the well-loved Citibank screen where I need to key in the associated debit card number and click through an HPIN using that weird image-based keyboard (another case of programmer-itis winning over customer ease of use, I think). But finally I make it. I’m happy to see the “Your payment has been made successfully” message.  But guess what? Because the payment was automatically rounded off to a lower number (and I couldn’t change that), my connection was left in an Unpaid state – for a sum of Rs. 0.35! You may not believe this, but actually logged in again and paid Re. 1.00, on my second card, to get this going.

As a product vendor in this market-place, I am both frustrated and happy. Frustrated that it takes so much effort and time to make a simple payment, but extremely happy that we don’t have problems like this in Impel. Don’t get me wrong, we do have the occasional bugs and performance does get affected when thousands of users are banging away on Impel . But for the most part, I am happy to say that we have looked at things completely from a customer perspective in Impel.

Do share your tales of happiness and woe with software – even if it is ours!

My regular barber of years moved to a farther location recently, so I’ve been forced to walk around the block to a different barber these last couple of months. The last time I got a haircut, I was asked to pay Rs. 25 – the same as my earlier barber’s rate. Today, though, the price was up – to Rs. 30. Why? Because, the barber said, “things are getting expensive”. Did this have anything to do with the fact that the only other barber in the area recently moved half a mile away? No, not at all, he said, with an of-course-you-moron smile. So, in less than 60 days, inflation and/or the lack of competition pushed prices up by 20%.

Compare that to the SaaS CRM business. Customers regularly ask us how they can be sure that we won’t raise prices on them in the near future. My answer is to suggest they look at history. Salesforce.com has maintained its $ 65/user/month price since 2002. Most others on this space have toed the line, sticking to anywhere from Free to $ 50 for the last seven years. So there’s empirical evidence that prices, even if they do go up, won’t change by 20% overnight.

On the other hand, SaaS CRM vendors do undertake some interesting sleight-of-hand with pricing. Salesforce’s recent shenanigans are fairly well documented (here is Zoli Erdos’ analysis of it; note: Zoli edits CloudAve, a marketing instrument for another SaaS CRM vendor, Zoho). Here in India, Salesforce partners and salespeople have been telling our prospects that their “SMB Edition” has everything they need to run a small business. Akin to, say, my barber saying that he’d cut hair only on the back of my head for Rs. 25 and that’d actually look good. I-don’t-think-so.

But, you’re probably thinking, prices do need to go up, right? So what’s so different about the SaaS business that it does not? Well, look at the price of mobile phones in India. Every few months, there’s a new device, with a whole new set of features, but at the same price-point of earlier models in that range. How’s that possible? It’s possible because of a number of factors offsetting each other – the increasing cost of marketing and distribution, the value of innovations in technology, the fall in hardware costs, the incremental impact of larger unit sales, etc. Unlike buying mobile phones, SaaS is a service purchase, but it has very similar characteristics in terms of factors affecting price. As an Impel user, you see new features every three months, without a change in price. As our user base grows, we throw more, newer hardware into our cluster. SaaS “distribution” mostly needs bandwidth – another component that falls in price over time. In order to grow and provide increasing value, long-term SaaS players focus on adding functionality on a regular basis. Because we “watch” the use of our systems by customers, we develop a fairly deep understanding of what’s missing, what’s difficult and what’s broken. And we use that information to design new features and functionality. Net effect, at a fairly steady price, our customers get increasing value over time.

Talking about haircuts, a month’s Impel subscription costs less than a haircut in the US. Now that’s value-pricing!

“Saab, main Bikas bol raha hoon.” That’s the way every call from Bikas starts. Bikas is a carpenter we’ve used a few times – too many times! – at home. Every few weeks, he’ll call just to say hello (he says) and, in the conversation, figures out if we have work for him. He does not push me, he does not demand things – he just says hello, asks about everyone at home (“Memsaab” is important) and then waits expectantly. The model works – he picks up every bit of carpentry work we may have at home. He’s done this for two years now, religiously and effectively. And because he’s worked with us so many times, our ability to negotiate has weakened to a point where we grudgingly agree to pretty much whatever numbers he throws at us. To be fair, too, we don’t argue because we know he’s around – that, if something fails, he’ll fix it the next time he comes around. So, by ensuring that he calls me regularly, he’s not only picked up a lot work, he’s also established a pricing pattern that includes a premium. That’s the power of regular customer contact – more work at better prices.

Bikas does this well because he’s identified a set of about 20 customers and he carries their contact info in a little black book. He also remembers the work that he did in the past – for the most part! How would you do this if you have 300 contacts in 150 companies to deal with? How can you keep track of what you said to whom and when, so you can sound knowledgeable and connected when you call someone you’ve not talked to in weeks? Impel gives you a number of ways to do that, including account and contact classification, periodic activity reminders and opportunity tracking with pricing. The Activity Plan mechanism, though, takes this issue from art to science. At the end of every month, you can plan your activities for the next month by choosing whom you will call on what day. You can plan travel around those days, making sure you visit accounts in a specific city or region when you’re there. And, using relevant activity results, you can plan the appropriate combination of calls to new prospects, to existing customers, for cold calls, to dealers, whatever. Once you plan those activities, they’ll pop up periodically with reminders, so you can make your own “Saab, main ” calls. When you’re talking to a prospect, you can click through your past activities to recall everything that you (or someone else) talked to him/her about. Most importantly, you can go back and update completed calls, as also add calls that you made that were not planned. Periodically, you can go back and review the effectiveness of your planning process, so there’s more predictability in your activities, leading to more predictability in your achievements. Whether you have a hundred accounts or thousands, you can use Activity Planning in Impel to work your contacts periodically, making sure you get the same advantages that Bikas does – more deals, better pricing. Except, you get it with hundreds of customers and prospects. And you get a mechanism that you can analyze, improve and expand.

As for me, I’m looking forward to Bikas’ business growing to a size where he needs Impel. Then, I can call him to say “Saab, main Kishore bol raha hoon…”

“But I can get Sugar for free!” he said. Before you think this is a new scam for the brown stuff, let me assure you: this was a prospect telling me he could download Sugar CRM, an Open Source CRM solution, for free. Instead, as you might have guessed, of paying for it with us. Now, how do you argue with “Free”? no matter what I say about our price being affordable, our price being the best in the market (of “proprietary” software), etc., there’s no way I can argue that paying for something is better than getting it for free. So what do I do? I do what I do best: lay out all the facts.

Don’t get me wrong: I LIKE Open Source. We use a lot of that in our software. We use FreeMarker and Java (of course!), our databases are DB2-C and PostgreSQL, our apps and databases run on Linux and so on. Even as recently as a month ago, we decided to use a dashboard control that’s available in the Public domain. But IMHO, prospective CRM buyers should worry about using Open Source for exactly this reason: that we use it. Let me explain: we use it because we are a software company and have the interest and skills to deal with its attendant issues. Do you?

Open Source software is usually very well-written – at least the better ones out there. As are some of the solutions that compete with us – they are, after all, written by very good programmers who are driven by a strong motive of giving back to community. Consequently, to begin with, you need to figure out what parts of a solution you need to download, where you’ll install them, how they will interact and so on. Yes, there are very good “distros” for most of these things, but to find the one that you need, you’ll need to spend a fair amount of time digging around on the ‘Net. If that’s what you want to do, instead of focusing on what functionality you need and which solution gives you that best, then you should consider Open Source.

Next, once you have the software all installed and running, there are the issues of user set-up, training, scaling, support and bug fixes. Analyses about life-time cost of software will tell you that the cost of running a system over 5 to 7 years is about 70% of the total cost of software. So, while you may have saved the 30% (Did you really?), you’re still going to be paying for all the things that make it usable over time and effective for your users. Factor that into your budget and see if an Open Source CRM still makes sense for your company.

Let me point out that the 70% assessment applies to software management, not the cost of the hardware and operating systems that you need to make it all happen. Most SaaS providers like us have a whole cluster of servers running multiple instances of the app and databases on different servers. Putting up that kind of infrastructure is not just a matter of the cost of the hardware – the real costs are in setting up and managing a cluster of servers, in terms of technical skills. Of course, you may not need that kind of access – you may be OK with losing a few days of access if your server fails. You may be OK to shut down the system every evening and over week-ends. You may be OK with a contractor, whom you’re paying by the hour, telling you he’ll come in “tomorrow” to take a look at your problems. If that’s the case, you should certainly consider Open Source CRM.

Then there’s the issue of feature growth. Open Source developers constantly roll out modules that can be integrated (by a good programmer) into a running app environment. In our case, though, we add features that make sense for our customers and their business environment. Specifically, we’re very proud of the fact that we have features and functions that apply in the Indian context. A CRM solution works well only if it fits the culture of the end-customer (not the CRM buyer) well. Open Source enhancements applying to the Indian context are few and far between right now. If your business, on the other hand, does not need to deal with Indian clients, you probably have a good chance making Open Source CRM work for you.

The point I am making is that buying into a SaaS solution is not about the cost of the software. In fact, the software itself has little to do with your using it effectively. It’s all about having a competent agency that truly partners with you for your success. Every quarter, you have the choice of walking away from our solution – that keeps us awake at nights, making sure Impel works for you and your users. That’s what you get at the click of a button on our website.

So here’s to Open Source, a significant contributor to our delivering great software at an affordable price.