In the first part of this series I alluded to what we put together as an operating environment and before I flesh that out I want to go through the heart of our “IP”.  As I’d mentioned the major initial development item was a website for marketing, ordering, and perhaps some deployment tools.  You could have imagined such a system involving manual billing/payment, partial or completely manual provisioning, etc.  But as we gained experience handling these things for our two customers, and thought about how we would handle it for dozens (and later thousands) we realized we’d have to automate more processes before we started adding customers.  Our simple website plan now morphed into a system with the ability to fully order, pay by credit card, provision, and self-manage the users for a customer.  Monthly billing and credit card payment was completely automated, so we would never have to invoice, hold Accounts Receivables, etc.  If the Credit Card charge failed the customer would receive a three-day warning email and if it failed on the retry we would lock their users out of the system.  All automated (though obviously we got email as well so we could follow-up and prevent losing the customer).  We made provisions to add ACH support, and even talked our bank into giving us ACH access despite not meeting their usual criteria, but didn’t integrate this capability into our initial launch (had a customer come along who was too big for the Credit Card solution we would have added ACH rather quickly).   We thought it likely that either the business’ Principal or Accountant would be the one choosing the service (which was targeted at 5-25 employee companies) and designed the system for their use.

When a customer signed up for our service they designated an Administrator who would be responsible for adding and deleting users, choosing (and changing) which software package and optional software/storage/etc. each user had access to, manage passwords, etc.  Since the most likely user of this interface was the company’s “Office Manager”, that is the persona we targeted.

Automating Provisioning was clearly one of the big challenges as Microsoft had not yet provided tools to do this.  We had to create domain accounts, do weird things to Exchange (because of multi-tenant), set up storage, work around Roaming Profile limitations, etc.  Towards the time we were getting ready to go live Microsoft introduced hosting tools that addressed much of this, but it was too late for us to incorporate into Phase 1.  So we put in a lot of time and effort to figure it out, only to realize we’d be throwing it away for Phase 2.

We also invested a lot of energy into exporting all of our configuration and billing information into our accounting system automatically.  So at each monthly billing cycle we would dump the results directly into QuickBooks, and my partner could close the books with just a couple of hours of work.  I’d been a little dismissive of how pedantic my partner was about our accounting system and this automated process, but it turned out to be a lifesaver.  For example, each month we needed to create a report of exactly what software we were using under Microsoft’s Service Provider License Agreement and pay (through our Managed Service Provider) for it.  We also needed real data to keep our business plan updated.  And, of course, we needed to keep a close eye on every penny we spent since every few months we’d have to make a decision on injecting additional capital.  When an engineer sits down and says “I’m going to build this cool new X” they don’t think about General Ledgers, Accounts Receivable, Accounts Payable, Trouble Tickets, etc. and yet those are the real backbone of a business.  We thought of them from the beginning, and while the work involved delayed our launch it also meant we had the infrastructure to support customers and the business when we did launch!

Speaking of Trouble Ticket Systems this was another area of investment for us.  Our Managed Services Provider was using one of the leading commercial offerings and we hated it.  Not only did it suck, when we heard what they were paying for it we just about fell off our chairs.  My partner brought up the open source OTRS trouble ticket system with a few days of effort (mostly in customization).  Then he and our contractor put in several more days getting provisioning and single-system sign-on to work.  Why did we invest in single-system sign-on?  Well, our experience with small business users showed that expecting them to have and remember separate accounts and passwords for the trouble ticket system was just asking too much.  Our support costs for supporting the system were going to exceed the cost of implementing single-system sign on by orders of magnitude, and fast.  Why did we do trouble ticketing at all initially?  Well even with two customers we had trouble managing the requests.  Something would come in by phone or email.  One of us would work on it and then hand it off to the other.  Sometimes we’d hand it to the contractor.  He’d hand it back.  Since he billed us for his time we needed to track actual time spent.  If the customer request was for billable work, we had to track time spent so we could bill them.  Often requests had to be directed to other providers.  For example, if you needed a file restored that really was assigned to the Managed Service Provider.  So we paid a couple of man-week price to implement OTRS, but it paid for itself almost immediately.

We did take one change to our plans that almost sunk us.  Along with the decision to “go big” was my partner’s insistence that we build in a Special/Trial offer facility.  This was spec’d out as being rather general purpose.  We could give a customer a unique offer, we could run a radio or direct mail campaign with a shared code, and we could write all kinds of interesting rules for what an offer was.  But this wasn’t just an ordering feature, it had its tentacles into provisioning, the administration tools, the monthly billing process, etc.  We knew we’d stretched the website contractor to his limit, but when we went to add the Offer Code capability we learned just how far we’d stretched.  I’ll address this in Part III.

Overall we offered Hosted Exchange, Terminal Server with Microsoft Office and a number of other apps, and a way to run apps that didn’t work in a normal Terminal Server.  Again this turned out to be one of our biggest challenges.  Most third-party software was not designed to run correctly under Terminal Server.  Some even had licensing language that completely forbid it (e.g., Intuit had language for the multi-user version of QuickBooks that made any kind of hosting impossible).  So I created a VM environment in which a user would get a dedicated VM for running one of these difficult apps (at least where licensing wasn’t an issue, so for example we never offered multi-user QuickBooks).  We’d charge a lot for these apps since we could support relatively few per physical server, but fortunately they had limited user bases.  For example, only one or two people in a company typically used accounting software.  I also made provision for a shared VM so that we could support multi-user software, for example Microsoft Dynamics, with a single VM per company rather than one per user.  Whereas we used Microsoft SPLA (rent software through us) model for most of our offering, the software running inside the VMs followed a “Bring Your Own License” model much as with today’s IaaS Cloud offerings.  This solved the problem that most software companies did not yet offer a service provider licensing model.  Take note that Microsoft, despite some flaws I’ll talk about in Part III, was way  ahead of the competition in trying to meet the needs of what we now call “the Cloud”.

Another problem we faced was integration with third-party services.  We first faced that with Paychex, which was used by one of our initial two customers.  Paychex (at least at the time, I haven’t checked recently) downloads a few ActiveX controls when you go to use it from your browser.  We, of course, had locked down our systems so that users could not load arbitrary ActiveX controls.  Addressing this required manual intervention, and it was a doozy.  Paychex only made the ActiveX controls available to logged in users.  Our customer’s user couldn’t install ActiveX controls.  Catch-22.  Paychex technical support was not helpful at all.  The final solution?  The customer gave me their Paychex login information (SHUDDER) so I could figure out what was going on and download the appropriate controls.  After that experience I invested a few days in trying to automate the process of allowing us to pre-authorize specific ActiveX controls for download by users, but had to put the effort on the back burner when it proved a tougher nut to crack than it first appeared.  We decided that for the time being we’d handle these as one-off situations and that I’d get back to solving the problem in an automated fashion after launch.

The next one to come up was salesforce.com.  This one proved far more satisfying for two reasons.  One, because we couldn’t make money running other Contact Management/CRM software in their own VMs, and no one ran under Terminal Server, salesforce.com actually made our overall profitability better.  Second, because salesforce.com was supportive of our efforts.  Their sales rep got us technical support to help, and when we had problems with one part of their integration offering they arranged a teleconference with the developer of the integration code.   (I wasn’t impressed with some of their early integration attempts as I didn’t think they made the best use of Microsoft’s facilities, but I was very impressed with their desire to support and make the integration better.)

On the day we went live a user could come to our website, learn all about the offering, sign up (with or without an Offer Code, though the website itself listed a code for a 30 day free trial), be automatically provisioned and using the system within minutes, add/delete/manage additional users, find KB articles on how to turn their PCs into thin clients, migrate data, setup their phones to Exchange ActiveSync, migrate their domain, submit trouble tickets, automatically re-bill credit cards on a monthly basis, and all the other things needed to run our service as a business.  Our original two consulting customers were cut over to the volume production system and using it the way we’d intended (actually we’d cut them over early as a short beta).   We were off and running.

Or crawling.  If “build it and they will come” worked PredictableIT would now be part of some large company and my partner and I would have pocketed many millions of dollars.  So in Part III I’ll explore the business proposition, what we did right and wrong, and why we eventually decided to shutter PredictableIT.

Before I go I wanted to address one last thing.  Readers of the story so far may think we overreached and could have cut back and gotten to market earlier.  They are right to an extent, but in the next installment I’ll explain why the customer value proposition forced us to be more complete at launch than would otherwise have been prudent.  But what I really wanted to add here is that I covered what we did, not what we didn’t do.  For example, we knew fairly early that what we were building was not scalable but decided time to market was more important.  If we succeeded it would hold us long enough to create a second generation that was fully scalable and cost optimized.  So many of the things we did sound big, but were actually scoped to avoid superfluous effort.