Best small business IT strategy: Smashup

[Update 3/1/2006: First, there were mashups.  Now, there are smashups (not to be taken literally).  By virtue of API access to so many services on the Web (particularly ones that small businesses are likely to use),  perhaps smashups (small business mashups) are the new way to go for small businesses in search of a strategic IT plan.]

Now that the behemoth effort of organizing Mashup Camp is behind us (us= me, Doug Gold, Mary Hodder, Kaliya Hamlin, Doc Searls, and the many other people who made it possible), Businesses can probably find all the componentry they need on the Internet. I've been racking my brain about how inefficient the task load was and thinking about ways to reorganize so that we're far more efficient at organizing Mashup Camp 2 (we already have more than 300 people signed up for the second event).  Since so much of the effort was orchestrated around the Web site which was (and still is) 100 percent wiki, most of my thinking has to do with what we could have done better for Mashup Camp's online presence.  While the wiki served us quite well (thanks go to Ross Mayfield and crew over at Socialtext for hosting it), there were some tasks to which it was perfectly suited, and others to which it was not.  Using the wiki to handle registration for example, worked great until some newbies to wikis made some syntactical errors while entering their names onto the signup page.  The results were not catastrophic.  But many man hours (probably between 30 and 50) went into correcting the signup page as well as other pages on the wiki.  Although it only happened a few times, one of those other pages was the home page -- the page that most people were greeted with when first arriving at mashupcamp.com and the last page that anybody who runs an online presence likes to see get screwed up. 

On relatively short order, it became quite clear that we needed a slightly different blend of technology for running the Web site.  We needed the wiki for some pages.  But for others -- the registration page for example -- we needed software that was better suited to the task of event registration.  For example, something where we could specify which basic fields of information were required in order to register (ie: first name, last name and email address).  Many of Mashup Camp's registrants weren't too keen on leaving their email addresses on a Web page where everyone including spammers can see and/or harvest them.  But most of them wanted other attendees to know they were attending as well.  As a result, they posted their name and other pieces of data that didn't put their online identities at risk. 

Without their e-mail addresses however, we had a new challenge: how to stay in touch with them about the event.  Eventually, we got smart about it and posted big bold text that asked registrants to confirm with us via e-mail (too bad we didn't think of that at the beginning). Then, as the email started to pour in, we quickly discovered the limitations of GMail (Google's free email service).  Virtually everyone wrote to us with the same subject line: "Mashup Camp."  In its attempt to help keep your inbox organized, GMail uses the text in the subject field to group or "thread" emails.  With everyone using the same subject text, both Doug and I ended up with a few monster threads that proved challenging to navigate.  We also had a tough time spotting new mail.  But even if Gmail was better at handling hundreds of emails, using any email system for managing relationships with over 400 people was probably a bad idea.  For that, a real Customer Relationship Management (CRM) system that integrates with email would probably have been a much better choice.

The technology shopping list was growing.  We still needed wiki technology.  We needed some sort of event registration componentry.  We needed a CRM system. In the course of organizing Mashup Camp, it felt more like we were running a small business than an event. Small businesses aren't that different from enterprises.  Why bother insourcing any of the technological components when insourcing can't make a difference in whether the business succeeds or not.  Almost immediately, I realized that the best approach was  to outsource as much of the "stack" as possible and to use the Web site as the foundation for the stack (the container for bringing them together).  For CRM, we can outsource to any one of the application service provider (ASP) CRM offerings.  For wiki, there are already a bunch of outfits (Socialtext included) that are hosting wikis.  Try Googling "event registration systems."  The list of providers is a mile long and many of them let you private-label their pages so that when people register themselves for an event, they can't even tell (without looking closely) that they're not on your site. 

At one point, a decision was made to try and get the registrants to help the Computer History Museum (where the event was held) get better WiFi gear for its WiFi network.  This donation-in-kind would require the equivalent of passing around an electronic donations hat.  We had no way of taking credit cards (the choice of most people for doing online transactions). But, since I was familiar with PayPal because of the buying and selling I've done on eBay, I was able to activate full blown online credit card capability within two days.  Through a page that was set up for donations, PayPal handled the verification, the transaction, electronic funds transfer, and even refunds.  The more I think about it, the more I realize that small and even medium size businesses can probably find all the componentry they need on the Internet. Then, it's just a matter of how that componentry is mashed together.  So, when small businesses go the mashup route to run their online presence, that's what I call a smashup.  In my next installment of this smashup series, I'll write about the choices I'm facing in terms of figuring out who should host the host (in other words, to the extent that the Web server is the container for all the business componentry, where that Web hosting will be done).