sabren.net   rants   archive   bio   portfolio

sabren.net archives

back to sabren.net...
back to the archive...

entries for 2002/7/13

an automated business

That last post was about my business from a software point of view. But let me talk about software from a business point of view.
 
Why do I want to automate my business? Well, so I can take on more customers of course. But also because it benefits the customer.
 
I mean... Suppose you liked peanut butter and jelly sandwiches, so you go through the drive-up at PB-King, and order a PBJ. One day, it's the best PBJ you've ever had. So you go back. The next day, it's awful. The next day, it's great again. Then good, but with a different taste... No consistency whatsoever. You never know what you're going to get.
 
Would you keep showing up there for the adventure? Or would you start eating across the street to McJelly's?
 
I think most people would prefer consistency when it comes to a business. And of course, it's better to be consistenly good than consitently bad. Automation gives you consistency, even more than proper training and operation manuals.
 
Also, software is cheaper than labor. Maybe not for most business, but definitely for mine. Partly because I can use free software. Partly because I use very-high level languages. Mostly because I have the skills to shape software myself, so when I pay for it, I pay for it with my time instead of my money. (My time worth a lot more to me than what I'd pay for another support person, but I also really enjoy making software, so I don't consider it a cost to spend my time this way)
 
Actually, there is a cost to developing this software: my support suffers in the short term. I don't like that, but I know that if my business grows faster than my capacity, I'm going to completely ruin my ability to support customers. Better to have rocky support for a while when I'm still small than to not be able to cope with it at all when I'm big. Especially if I make up for the support lags by delivering useful tools.
 
In fact, that's the key. I need to make this the focusing thought of my day: How can I deliver more value to my customers now and in the future? And the answer is to streamline the communication process. The more I do that, the fewer support emails I'll have to deal with, and the more time I'll have to make things even better.

cornerhost 2.0

Some day, in the not too distant future: If these two things happen in this order, things should work out fine. But if they happen in the opposite order, Cornerhost could have trouble. Worst case, I could simply stop accepting new customers, and enough people would leave from frustration that things would balance out.
 
But that ain't how we play the game around here. Instead, I've got to figure out how I can make my business into a system that runs itself, with as little maintenance as possible. More importantly, I've got to figure it out before this transition takes place.
 
Since I have reason to believe that the rate of new signups will increase dramatically in the coming months, I can't put this off. I've got to improve my business systems. And in fact, I need to move from owning a support job to owning a system that provides value to customers on its own.
 
Which brings me back to an old idea: the idea of my business as a piece of software.
 
I've talked about this in abstract terms before. I once even toyed with the idea of modelling my business in actual code. But I could never see any real value in implementing code like this... Until now.
 
But let me back up a bit. Suppose I implemented a python class to represent my business: 
from strongbox import *
class Host(Strongbox):
    pass
What do I put in it? A Host has all sorts of things attached to it: And if the Host lives inside the Market, then there's all sorts of other Hosts out there, not to mention Prospects that could become Customers.
 
Customers of course have Websites which they want to put on their Accounts, and access through a Domain, which also powers their EmailAddresses, some of which are ForwardingAddresses and others map to PopMailboxes. Any other mail sent to their domain goes to a CatchAllAddress.
 
The Host communicates with the Customer in various ways: Emails, TroubleTickets, Statements, Charges, Payments... Often these communications have to do with Problems, which are usually new to the Customer but quickly become recurring themes for the Host, which soon develops a KnowledgeBase (even if it's only informally floating around in people's heads).
 
Since various Hosts have different internal structures, Customers jump between them, often based on the Host's ability and speed in resolving Problems. (Which is why I focus so much time on support.)
 
Better yet (or worse yet, depending on what kind of host you are), Customers have Friends who trust their Opinions. If a Customer with a lot of Friends expresses a high Opinion of a Host, that Host will soon have even more Customers.
 
And with these vocabulary words floating around, we start to see relationships. One problem can spawn TroubleTickets from many Customers. A SupportPerson can only deal with so many TroubleTickets. If the Knowledge isn't shared in a KnowledgeBase, or the SupportPerson doesn't use the KnowledgeBase, then the SupportPerson has to figure out the Solution all over again. On the other hand, if a Customer can find a Solution to her Problem in a public KnowledgeBase, she will never generate a TroubleTicket in the first place.
 
Some of these behaviours are explicitly coded into the system. Others emerge naturally. And so far, it's all just plain common sense. I can't see a benefit in actually implementing this stuff as code.
 
Except that I already have some of it as code. Duckbill has Customers and BillingAccounts and Charges and Payments. And more of it will need to go into the control panel: Customers having UnixAccounts and whatnot.
 
And if we start to think about how these objects talk to each other, we see that most of it already is software. People don't call me or walk into my office. They send an email or fill out a form. When there's a problem with their account, it's just software.
 
At any given time, there's a whole ton of things that need to be true about cornerhost. Users shouldn't take up more than their alloted filespace. Long running processess should be scruitinized. Certain files should not change unless a sysadmin (me) changes them. Loads on the servers should not be too high. Support requests should not sit for more than a few hours.
 
All of this is software. In fact, the only thing inside my business that isn't software is me. And I do many of the same things over and over again. Sometimes I make mistakes, so there should be software to check my work. Usually a couple lines of python will do the job - like the script that reconciles my merchant account with duckbill, to make sure I didn't lose someone's payment.
 
Can I totally automate cornerhost? Probably not. There will always be problems that need to be solved by a human brain. But can I make it far more automated and efficient? Absolutely! Heck, with the web-enabled advertising systems out there, I could even 100% automate my marketing... Every couple weeks, just pop another $100 into the ad systems...
 
Obviously, simple things that only occur once (like renewing an ad campaign) in a while don't need as much automation as hard or boring things I do all the time.... But how about a one line cron job that simply reminds me "HEY! It's time to renew the ads!"?
 
This is the direction I want to go in. And right now, the focus needs to be on the communication path between Customers and the Host. (Which is called "support", compared to the communication path between potential clients and the host - that's called "sales and marketing", or at the moment of conversion "the signup system")
 
Customers send messages to the cornerhost all the time. What I want is to channel those messages through a computer interface - the control panel. Now, instead of a bunch of words that I need my brain to interpret, the message is received as an unambiguous HTTP form post that a computer can handle. That's for the basic stuff. For questions, there should be a searchable knowledge base. It's not quite as automatic (the knowledge base can't fix people's problems, only inform them of possible solutions), but the burden of processing the noncomputable information falls on the customer. (Of course, that's okay, because it means they didn't have to wait around for me!) Messages should only come to me personally as a last resort, or as a broadcast from something like the users group.
 
The more I talk about this, the more I see that a business modelled in software isn't such a crazy idea. It's not even a particularly magical idea because my business already is almost 100% software. I just need to step back from doing things myself and let software do its job.