Kalzumeus Software

Appointment Reminder has launched.  I will continue blogging about the development process (and post-launch stuff) later, but at the moment I am up to my eyeballs.

Along with some other users from Hacker News, I’m doing my darndest to get Appointment Reminder into the hands of customers by the end of November.  It looks like it is going to happen, too.  (There was an early blog post about this here.)

Rails Deployment Options

Somebody asked me to talk about this subject, so I will cover it briefly.  Rails deployment has historically been very painful.  These days it is a little better.  The big options are:

• Run a Rails stack on a server or VPS under your control
• Use Heroku
• Run a Rails stack on Amazon EC2

I have used Heroku for a client project before.  It is a wonderful service, don’t get me wrong, but I have almost five years of managing production Rails applications on a VPS and less than five weeks of managing production Rails applications on Heroku.  I know from experience that I will try to do things during development where Heroku’s limitations (like the read only filesystem) will trip me up, and tripping myself up doesn’t get things in the hands of my customers any quicker.

Additionally, my anticipated traffic for Appointment Reminder is way, waaaaay within the capacity of single largish Slicehost slice to handle.  If I manage to bring my Slice to its knees, it will be because my revenue has hit several million dollars a month.  That will give me many attractive scalability options, such as hiring someone to care about scalability while I sip chilled juices on the beach of a tropical island.

I built a staging server, from scratch, and obsessively documented the process.  (I strongly recommend that you do this for building servers, since you will have a burning need for that documentation if something ever goes wrong.)  It relied heavily on the Deprec gem, which is far and away the easiest way to get a Rails stack running on a bare Ubuntu install.   I still spent almost 4 hours filing down sharp edges, though.  (Sample: I wanted to run Rails 2.3.10 rather than upgrade to Rails 3, there were issues with compiling Mongrel on Ubuntu that had to be resolved via manually grabbing packages, etc etc.) I only really recommend this if you know what you’re doing with Rails system administration.

In terms of software choices for my deployment stack:

• Ruby 1.8.7 via the Matz Ruby interpreter.  It isn’t the fastest, but speed is hardly of the essence to this application and it is the least likely to die horribly when using a gem or library, since everybody tests against it.
• Rails 2.3.10.  I don’t want to learn Rails 3 at the moment.  Maybe next year
• Mongrel cluster: I have experience managing it.
• Nginx: The best web server I’ve ever had the pleasure of working with.  Also plays well with PHP, which I need on the box to handle the marketing portion of the website outside of the application.  (The marketing site is in WordPress.)
• God process monitoring: I have experience using it.
• DelayedJob job queuing: I have experience using it.

I will probably eventually put WordPress on a physically separate server (hey, it’s WordPress), but that doesn’t strike me as the biggest priority at launch.  I did go to a wee bit of trouble to secure it:

• Access to the admin directory is denied at the server level for requests not from my private network.
• WordPress has its own database and database user, and can’t touch anything elsewhere.
• The WordPress directories are only writable by root, not by the web server user.  If I want to install plugins, I get to SCP them to my account on the server then SSH in and start sudoing to actually copy them in.  Ditto for uploading files.  Facilities to upload and immediately execute PHP code are, ahem, a persistent source of vulnerabilities.

Code Is About 70% Complete

I have sustained pretty close to my lifetime peak productivity at programming (say that five times fast) for the last two weeks, averaging 4 to 6 hours per weekday.  Appointment Reminder has most core functionality implemented on the staging server, for a single single-user account.  Twilio has been an absolute joy to work with — I really can’t express how much of the pain they take out of running a telephony company.

What’s done:

• Client creation/management: 100%
• Appointment creation/management: 90% (still need to associate scripts with appointments)
• SMS reminder loop: 100% implemented.  (web app -> Twilio -> user’s phone -> web app)
• Phone reminder loop: 100% implemented (web app -> Twilio -> user’s phone -> web app)
• Dashboard: 90% implemented.  (Needs to be a wee bit more configurable, particularly for multi-user environments.)

Things are looking fairly slick thanks to jQuery UI and a lot of AJAX, but it has been a bit of a handful to test.  If you have suggestions for doing so, I’d love to hear about them in the comments.  Mostly I have been doing unit testing for models which are likely to have failures, and then doing manual testing to verify that the UI works how I expect it to.

I am currently using an absolute riot of colors on the dashboard to convey status information.  That probably should get reduced.  SASS has been very, very helpful in keeping me from having to handwrite CSS to manage all of these.

What still needs work:

• Email reminder loop: 0%, should take ~4 hours for simplest thing that will work
• Script creation/management: 0%, should take 1~2 days (this requires hooking up another phone system)
• User/account management: 0%, should take ~2 days
• Reports: 0%, should take ~1 day for simplest thing that will work
• Feedback to user on appointment status changing: 0%, 2~4 hours depending on how full-featured I want to launch with
• Charging people money (using Spreedly — shouldn’t take more than a day)

Outsourcing Up A Storm

I have had a lot of luck using Fiverr for getting recordings done cheaply.  Try the Appointment Reminder demo to hear one of the voiceover artists in action.  My plan is to launch with about four different sets of voices to give customers some variety: I expect that most will actually record their own reminder scripts, but anything which decreases the amount of work it takes before they get a phone call from the system is a win for me.

I also plan on eventually using reminder scripts as a cheap way of marketing.  There are virtually infinite marketing angles once you have the ability to make a phone ring, since it is so ridiculously compelling.  (I mean, people paid how many billions of dollars for ringtones?)  For example, I have an absolutely unhealthy interest in the Old Spice Man.  Getting a script inspired by the character is easy, remarkable, and is both a win for my customers (“That phone call you gave me earlier was hilarious!  Thanks!”) and lets my customers market AR inside their organizations (“Cindy, you have to hear this.  Quick, what is your phone number?”)

There are virtually infinite variations on that: you could imagine getting a phone call from a Humphrey Bogart impersonator, etc etc.

Speaking of outsourcing, I recently started using a Virtual Assistant, something I have been meaning to try since reading about them in Rob Walling’s book.  I found mine through an agency called Pepper (that name is a bit of an easter egg for comic book geeks in the audience).  For about $300 a month, I get twenty hours of time from one particular lady who works at their office.  She does, within reason, anything I tell her to do.  This has been a huge win for me in cleaning boring, time-sucking tasks off my plate so that I can concentrate on development and marketing.

For example, up until quite recently I was ten months behind on bookkeeping.  That’s a long story: I do expenses bookkeeping via a home grown application so that I can display nice graphs on my website, and that application got broken by an unrelated update back in February.  (Bookkeeping of revenue is totally automated, and didn’t break.)  Since customers don’t pay me to do bookkeeping, fixing it went on the back burner.  I eventually got it working again sometime in summer… and then had six months of credit card statements to process.  Well, that sure sounds like work, so I procrastinated… until there were ten months of statements to process.  Crikey.  It kept getting worse, it kept weighing on me that it wasn’t done, and I didn’t want to spend a day or two just going through 20 PDF files and typing some 300 transactions into the computer.

Enter my Virtual Assistant.  I spent ten minutes typing up my decision tree for classifying transactions (the credit card statements have mixed business and personal charges — whoops, got to fix that one next year), instructions for operating the bookkeeping interface, and the like.  Then I created an account for her in the system, zipped up the 20 statements, sent them over, and answered an email or two from her over the course of the next week.  Managing her and reviewing her output took perhaps 30 minutes in total, instead of somewhere on the order of three to six hours to do the data entry myself — plus, it didn’t totally wreck me for other productive work that day.

I’m now almost caught up with bookkeeping (got another statement delivered by my bank in the interim), and now that there is a process in place for it keeping caught up is simplicity itself: download statement, shoot it to my VA, go on to do things that actually matter.

This was astoundingly beneficial for me.  I have a nagging worry taken off my plate and a process to make sure it never comes up again.  I got to invest several extra hours in things which matter to the business, instead of doing data entry.  That covers the first week of the month: if I never got another stitch of work done, I’d consider my $300 well spent, but I’m guessing that I can almost certainly find other stuff for her to do.

When I get some time to breathe this month, I’m going to figure out other tasks I can assign to her: perhaps drawing up lists of keywords or blog post topics.  I mean, I could spend a day coming up with every possible permutation of a professional service plus every possible synonym for “scheduling software”, but that doesn’t require my personal attention.  (Why I would want a list of hundreds of keywords about my software is fairly straightforward if you’ve followed my bingo card creation endeavors: implement system to create content at scale, farm out content creation to freelancers, cover the organic search longtail for the topic, sell thousands of accounts to organic searchers).

Speaking To Customers

Dharmesh Shah, I think, said that there are phone people and email people, and that most engineers are email people.  I am definitely an email person.  I hated speaking on the phone even before I started using the Internet.  But I’ve been chitchatting with prospects (at Ungodly O’Clock AM) for the last couple of weeks to hear about their needs, and have both learned stuff I didn’t know about my market, confirmed some stuff I did know, and — importantly — gotten some promises to pay me money immediately when the software is ready.

Here is my mental model of the typical customer for Appointment Reminder: Martha owns a massage therapy practice.  If Cindy, her client, doesn’t make her 4:00 PM massage, then Martha loses $60 of revenue immediately and will likely be unable to rebook the slot, since she’ll find out about the gap at about 4:05 PM.  Appointment Reminder either gets Cindy in on time or gets Martha 24 hours of notice, so she can book the slot.  Martha happily buys the service.

Note the embedded assumption there: Appointments are something you go to.  I never even realized I was assuming that.  It turns out that I was, and that there is a broader market than I expected, for appointments where the service provider comes to you.

Why does this distinction matter?  Because Martha is greatly annoyed when her customers don’t come in, but she has not literally lost money out of her pocket.

Consider Earnest the Exterminator.  He has a team of three guys and a van filled with lots of dangerous chemicals.  When Earnest makes an appointment, he finds out that you’ve forgotten after he drives 25 miles to your house.  Not only did Earnest just lose out on the revenue from killing your bugs, he just burned up three hours of salary at skilled labor rates because you forgot that today was, indeed, Tuesday.  Martha is greatly inconvenienced by her no-show problem.  Earnest is sputtering with rage about his now-show problem.  I now know this because I’ve gotten on the phone with three different Earnests now and just shut up while they talked about their problems.

I’m going to make changes to my marketing posture to reflect this (the Marthas of the world are overwhelmingly female, but there are an awful lot of guys in the Earnest category along with some ladies), and I’ve also started to create some features for supporting Earnest and his team.  Some of my Earnests have been surprisingly tech savvy (“Oh, my programming team wants to know about your API.”  “You have a programming team?!?”  “Bleep yes I do, you think I’m going to run the systems myself?”), and the knowledge that the user of the software could very possibly be mobile rather than at her place of business really rejiggers my development priorities for e.g. checking your schedule via a phone call.

Plus, as you can probably guess, somebody who has a programming team and a very good idea for how many tens of thousands of dollars they lost last year to no-shows is, shall we say, quite willing and able to pay any price I want to charge.

Next Steps

More of the same, really.  I just got confirmation from one of my freelancers that she is working on the MP3 files for phone calls.  Tomorrow I build out the script interface to allow people to pick or record the telephone/SMS/email scripts that they use.  After that is done, I think I’ll do the email integration, which is the last bit of actual functionality for the site.  After that, user management (if worse comes to worse, all I really need is to have users have separate settings, and I can do all creation of secondary users by waiting for emails from customers and then doing it via the Rails console rather than with a slick UI on top of it).

If you have anything in particular you’d like me to cover in the next installment, say the word.

There was overwhelming enthusiasm from people when I offered to blog about the development of Appointment Reminder, so I will be doing it during the month of November, prior to my planned release.  (Tentatively planned for the end of the month, if it is ready in time.)

Achieving Activation Energy

Appointment Reminder has, theoretically speaking, been on my plate since April 1st, which was my first day of self-improvement.  I released the MVP — basically, a functioning demo of the core interaction between service provider and customers — halfway through May.  And then I sat on my hands for about six months.

Oh, stuff happened, don’t get me wrong.  I went travelling internationally, twice.  I kicked butt and took names for some consulting clients, got (and turned down) about a dozen job offers, won an award for best presentation at the Business of Software conference, started writing an article for the ACM, met a young lady, and broke my old bingo card sales record.  But while my life is firing on all cylinders, happiness does not write jQuery or Rails code.

My last client project wrapped up in mid-October, I told clients I would be mostly unavailable for the next few months, and I picked the end of November as an arbitrary deadline to finally get Appointment Reminder out the door.  Deadlines tend to coerce me into doing my best work.  Specifically, deadlines with subgoals that have small units of measurable accomplishment work best for me.  It must be the WoW player in me, I swear.  So I broke the month or so of work up into a series of mini-quests which take about half a day to accomplish, and then logged the first dozen or so in EpicWin (productivity management for recovering WoW players — my other quests include going to the gym, doing the dishes, and calling each of my younger brothers).  I have been polishing them off more or less according to plan.

Technology Choices

When I start a greenfield project (and AR is still new enough to be mostly greenfield), one of the first things I write down in the project notebook is what technology stacks I’m good with and which make a fit for the product.  Given that my options for web development are Big Freaking Enterprise Java and Rails, Rails was the clear winner.  I am literally an order of magnitude more productive in Rails than I am with Java, and I lack the experience with Java architecture astronomy to build an application from the ground up (which I have done successfully in Rails before).

I sometimes also use the opportunity of new projects as an excuse to broaden my horizons.  For example, I’ve wanted to get into jQuery for a while since the world seems to be moving that way (away from Prototype, my old Javascript framework of choice), so I decided to take the minor productivity hit with starting a new framework and moved to jQuery.

My other professional growth goal with AR was to get a little more serious about interface design.  Thomas Ptacek has been raving to me about how much better SASS/Compass made the experience of getting CSS to work right, so I decided to move to SASS/HAML from my previous CSS/ERB standbys.  This delivered huge, huge wins within two days of starting exploratory coding with the project.  I can’t recommend SASS enough.  This also led to a bonus: the lack of markup going into my views means that I can develop against a cheapo CSS template and then swap to a professional design later, without having to have the design be on the critical path for November.

Design on Paper

I generally keep all notes for a project in a $1 notebook.  However, my first Appointment Reminder notebook is nowhere to be found.  Drats.  I probably left it in a hotel room in America.  So I bought a new notebook and started sketching out database tables, screens, features I would like to include, etc etc.  Then I started cutting, ruthlessly.

For example: Users need to be able to manage clients.  OK.  Hypothetically, they may have hundreds or thousands of them, so they’ll need a search interface… but will they have hundreds or thousands on launch day?  No?  Search is out of scope.  Next!

Users need to be able to give custom reminders to clients.  This requires recording their voice.  Uploading files is a pain in the keister — out of scope!  I’ll make do by having them just narrate the reminder over the phone to Twilio, which would obviate the need for me to do any file encoding or management myself.

And so it continued.  By the end of my first working lunch, the feature list that was in scope ended up looking something like this (broken down roughly along controller/model lines):

Accounts

Account creation

User management

User permissions (Enterprise-y feature, enterprises aren’t going to adopt in first two weeks: out of scope.)

User preferences

Login / Logout / Forgot Password

Clients

CRUD app for users to add clients

Track phone numbers and email

Communication preferences

Opt out of reminders in case of abuse (Barely avoided being out of scope: it is important but doesn’t sell software.)

Schedules (one schedule manages one resource — a room, service provider, etc)

Default schedule (most users will have only one)

CRUD app for schedules

Change hours of business day, days of business week.  Eventually that might change on week-to-week basis, for now, simplest thing that works.

Appointments

Appointment calendar — starred several times because this is going to be the hardest part of the app

CRUD for appointments, based on calendar

Status tracking for appointments

Reports for number of appointments missed, etc Can’t be used on day one, out of scope.

cron job to send reminders about appointments

Reminders

Spawned automatically from appointments

State machine (see below)

Twilio integration

Twilio

Inbound calls

“Who the heck are you and why did you call me?” auto-response

Reset trial (already implemented)

Record custom reminder

Get schedule for day dictated over phone great feature, out of scope for now

Voice-assisted tour only in scope if I have two days left over

Outbound calls

Reminders

If answered live, capture user input and update Appointment state accordingly (coming, canceled, needs call, etc)

If answered by machine, leave message, update Appointment state as notified.

Reminders with custom recordings

Text messages

Email

Thank you for signing up, blah blah blah

Password reset

Appointment reminders

User notifications on appointment confirmation, cancellation, etc out of scope

Billing

Get paid (oh heck yes, in scope)

Assorted Stuff

Account deletion out of scope

Admin interface God gave us console for a reason

Custom analytics Nobody to track on first day

A/B tests (would be out of scope, but hey, free since I have A/Bingo)

Whitelabel version

HIPPA compliant version

Change tracking (e.g. audit trail for deletion, etc)

Exploratory Coding Begins

After playing around with the signup screen for a little while, mostly to get a feel for SASS/Haml, I started working on the first feature of the app that would provide user value and be mostly self-contained.  Ideally, I would start with the first thing I want them to do (schedule an appointment), but that requires adding a first client anyhow, so I started with the client administration screens first.

I don’t use Rails scaffolding, although since I got publicly told off invited to try improvements by DHH for having insufficiently RESTful routes I thought I’d give that a try.  (Turns out it actually does save enough pain to matter, although I still think publicly visible RESTful routes are a mistake.  For internal features of a CRUD app, though, they make a lot of sense.)

What I generally do is start with the index action, verify that I can display records added to the database directly (via the console or a seed script), then start on the show action.  This results in me getting frequent incremental visual progress that the program is, in fact, getting better.  Anything which can’t be used yet gets stubbed out with lorem ipsum.  When I feel myself reaching the stopping point for a day, I go to the next action on my list and get the view working, even if it is as simple as displaying a screen which says “This action does not really exist yet but if it did it would show #{@client.name}”.  That gives me a place to pick up again in the morning (or, ahem, afternoon, given my frequent work/sleep habits).

Anyhow, after getting show done, I work on the edit/save loop, which requires building out the model a bit, adding validations, and writing some less trivial controller logic.  Here I frequently discover something like “Hmm, it would be handy to have a way to display messages out of the flash” and start working up a helper to do it in a minimalistic way.  You can see it behind the example of me operating the new (error-enabled) edit window.

Working with jQuery slowed me down a bit when creating some of these screens.  I used jRails to ease the transition (it lets you use all the old Rails-esque Javascript helpers like link_to_remote), but it does not play well with jQuery 1.4 out of the box.  It turns out that the issue I was having was mostly that jQuery executes any Javascript it grabs from the server prior to updating the DOM with the rest of the data it got back, which borks the Prototype-esque habit of sending back both HTML and then Javascript which relies on that HTML being in the DOM to function.  I got around this by simply returning only Javascript — e.g. for the “pop a window to put in a new client” action I return:

:javascript
  $('#client_dialog').html("#{escape_javascript(render :partial => 'edit_form')}");
  $('#client_dialog').dialog({
    //blah blah
  });
  $('#client_dialog').dialog('open');
  $('#client_dialog').find('input').focus();

This is hacky as heck, and obviates some of the reason of using jRails in the first place, but it works. I can always DRY up the helpers a little more later.

After getting the validations and whatnot working for Clients, and doing some light testing to make sure things worked to my satisfaction, I did similar work for Schedules. I got the basic CRUD functions working in record time, mostly by copy/pasting everything I had done for clients and then just changing the parts of the model and view that were different. The controllers are mostly identical, at least until I actually create the ability to render a schedule.

I’ve finished the CRUD logic for my first two parts of the problem domain, and am impressively ahead of schedule. To celebrate, I spent a day upgrading jQuery to the latest stable version (not quite so fun), upgraded the jQuery week calendar widget I was using to a fork that is being actively maintained, and wrote code to render the minimum calendar possible without actually having any appointment data available.

And that is about it for today. Tomorrow: hooking up the ability to add appointments to the schedule, then CRUD logic for them, then the ability to create an appointment and client at the same time. That will complete the first take on the core interface logic for the application, leaving me next week to tackle integration with Twilio.  (I had originally planned on that taking at least two weeks, but I remember it being much easier than I expected back when doing the MVP, and I seem to be progressing faster on this project than I typically do.)

Plans after that are roughly:

• Turn on user account creation, log in/log out, etc
• Create staging server, taking care to document my setup process on a computer this time (darn missing notebook)
• Add integration with Spreedly/Paypal for billing
• Polish as much as possible.
• Test as much as possible.
• Ship at or near end of November.

After Shipping

After shipping, of course, comes the 90% of the remaining work needed to turn an application into a business.  (Of course, I have been doing some of it all along: speaking with customers, gathering requirements, thinking about marketing angles, etc.)  In particular, I’m starting to devote my free cycles at lunch into thinking about scalable content generation strategies for organic SEO, which is the form of marketing that I’ve had the best results with in the past.

But it is highly likely that, immediately after launch, I’ll have a bare handful of customers and a fairly relaxing December with answering customer support queries (and pre-sales inquiries), mapping out future development, starting the marketing engine, and enjoying Christmas with my family.  Then, on to January.

Earlier this week, I went to a small massage parlor which is located at the mall next to my house.  There are three attendants on duty at any given time.  I was a “walk-in” (no appointment) and ordinarily would not have been able to see someone quickly, but luckily for me two clients had failed to make their appointments.  That was rather unlucky for the firm, though: two clients not at their appointments means two massage therapists not seeing anyone, and that costs them $2 a minute in direct economic losses.

What that business needs is some way to reduce the number of no-shows and get earlier warning when no-shows happen, so that they can rearrange the schedul, actively solicit walk-in customers, or invite one of their regular customers to have her weekly massage early.  That would minimize the lost revenue from missed appointments.  For example, they could call every client the day before their appointment.

But calling customers is an expensive proposition, when you think of it: three staff members times an average of 10 clients each per day means they’d need to make 30 phone calls a day.  That is thirty opportunities to hit the answering machine, thirty voicemails to leave, thirty “We’re sorry, our customer is not in the service area” messages to hear.  And, since there is no dedicated receptionist at the store, that is time that has to come from an expensive therapist — and when their hands are on a receiver, they aren’t working the knots out of someone’s shoulders for $1 a minute.

There are many, many businesses like my local massage parlor: massage therapists, hair salons, auto mechanics, private tutors, and large segments of the healthcare industry.  They all have an appointment problem…  and it is about to get a bit better.

Introducing Appointment Reminder

For the last several weeks, since quitting my day job, I’ve been hard at work on Appointment Reminder.  (You can tell that I haven’t lost the same panache for inspiring, creative names that bought you Bingo Card Creator.)  It is a web application that handles scheduling and automated appointment reminders via phone, SMS, email, and post cards.  The phone and SMS reminders are through the magic of Twilio, which lets you make and receive phone calls and SMSes using simple web technology.

My value proposition to my customers is simple:

1. Schedule your appointments in the easy-to-use web interface.  That’s all you have to do.
2. Prior to the appointment, we’ll automatically remind your customer of the date and time of their appointment.
3. The customer will be asked whether they’re coming or not.  If not, we’ll notify you of that immediately, so that you can reschedule them and rescue the emptied slot.
4. This makes you money.  Plus, it is another opportunity to touch your customers, hopefully improving your commercial relationship.

How This Is A Lot Like Bingo Cards

My assumption, which has been borne out a bit in talking to potential customers, is that the market for this sort of thing is overwhelmingly female.  The personal services industry is mostly female, and dedicated receptionists (who I am replacing making more efficient in one facet of their jobs) are almost universally female.  That is one point in common with the market for Bingo Card Creator.

In addition, the competition is similar to the competition for educational bingo cards in 2006:  they’re structurally incapable of addressing huge segments of the market and I am going to go after those segments with a vengeance.  For example, if you look for appointment reminder services online, you’ll find that most of them go after the healthcare market — that is, after all, where the money is.  (My dentist got $770 for 15 minutes of his time and 30 minutes from the dental hygienist — he’s losing a car payment every hour he doesn’t have his hands in a mouth.)

This is mostly sold as enterprise software, with the long sales cycle, non-transparent pricing, and general cruftiness to match.  It almost has to be, because the software has to plug into patient records systems (the typical enterprise morass of dead languages, horrible interfaces, and software which would have fallen to pieces years ago if it hadn’t sold its soul to the devil).  Additionally, healthcare is a very regulated industry, and compliance with HIPPA and other regulatory requirements inevitably drives costs up.

From my research, the cheapest options available cost about $300 a month as a service (often involving a contract with an actual call center) or ~$1,000 as installable software and hardware.  Those do not strike me as viable options for a hair salon, piano teacher, or small massage parlor.  However, thanks to Twilio incurring the capital expenditures on my behalf, I can afford to offer a superior service for a fraction of that price.

And because my cost structure is absurdly better than my competitors, I don’t need to have a sales force to close the deals.  Instead, I can use the skills I’ve built up over the last several years of selling B2C software, and consummate transactions online on the strength of passive sales techniques like a demo, free trial, and website.  My guess is that the low-friction nature of this is going to help me with the less enterprise-y segment of the market, as they’re least in the mood for “Give us your phone number, address, and financial particulars so we can have a salesman set up a meeting to talk to your office manager about how much this is going to cost you.”

Demo / Minimum Viable Product

Appointment Reminder is not actually ready yet.  Having been on something of a Lean Startup kick recently, I thought that getting the software ready prior to showing it around to customers would put the cart in front of the horse: why spend 2-3 months getting v1.0 of the software ready if it turns out that users are cool on the entire concept.  Instead, I took a bit of inspiration from Dropbox’s minimum viable product, which was just a video showing how awesome your routine tasks would be if the product actually worked.  (They had a working prototype at the time but not one which would 100% reliably keep people’s data, which is sort of a key consideration if you’re making a backup product.)

The way I figure it, since the demo of my software is what ultimately makes the sale, everything that happens after the demo is essentially irrelevant to getting someone’s credit card number.  So everything that happens after the demo is out of scope for the MVP: I can demonstrate the sizzle without actually cooking the steak.  The sizzle for Bingo Card Creator was cards coming off your printer.  The sizzle for Appointment Reminder is demonstrating that I can make a phone ring on command if you type a number into your computer.

I’ve been programming for more than a decade now and very, very rarely get the “kid in a candy store” feel these days from it, but the first time I made my phone ring with an API call, I got all kinds of giddy.  I’m figuring that my customers will likely be the same: this is new and magical territory for them.  And unlike a certain technology company which specializes in new and magical telephone equipment, this will credibly promise to make people money.

You can try the demo of Appointment Reminder yourself.  Get your cellphone out, you’ll need it.  The flow goes something like:

1. Open the demo page.  (I may eventually capture email addresses here, but folks visiting in the first few weeks are mostly going to be my tech buddies, so I’ll hold off for now rather than collecting a lot of mailinator.com addresses.)
2. Take a look at the simple calendar interface.
3. Type in your phone number and hit Schedule Fake Appointment.
4. Your phone rings and you get a combination sales pitch and product demo in the guise of informing you of your fake appointment.  At the end of the call, you’ll be given an option to confirm or cancel the appointment.
5. As soon as you confirm or cancel the appointment, that is reflected on your computer screen.
6. You’ll be asked for a conversion here.  At the moment, it just asks for your email address.  Once the site is live, I’ll be pushing for the sale right there.

In real life I’d be using a more immediate way to contact the customer than updating their web interface, since they won’t be on Appointment Reminder when their customer gets the phone call, but that didn’t make sense for the demo — I’ve already credibly demonstrated my ability to make the phone ring.  Now I just need to credibly demonstrate that I can get information from the phone calls to the computer.

Pricing

I have some tentative thoughts on pricing for the service.  This was mostly a marketing decision — I want to be able to say something similar to “Appointment Reminder will pay for itself the first time it prevents a no-show.”  There is also quite a bit of daylight between the value of an appointment among my various customer groups — for a low-end salon that might only be $10, for a massage therapist $50, and for a lawyer or dentist “quite a bit indeed.”

My plan breakdown is mostly to do price discrimination among those user groups:

• Personal ($9 / month): This is for folks who either want to send reminders to themselves/family or folks who have a part-time business like piano tutoring on the side.  Candidly, I think the value of these customers is going to be minimal, but I wanted to have this plan available for marketing reasons.  (It gives me a shot at appealing to the web worker/productivity/etc blogging folks, for example.)
• Professional ($29 / month): The bread and butter plan.  This is intentionally sized to be decent for a low-intensity full-time business, such as a hair salon or single massage therapist.  Of note, putting the ability to record custom reminders here rather than in the personal plan provides a strong incentive for folks to upgrade.
• Small business ($79 / month): This is where I expect to get the majority of my revenues and profits from (notice how I recommend it?).  It should be sufficient to cover most businesses smaller than a busy dentistry practice.  Speaking of dentistry practices…
• Enterprise ($669 / month): So here’s a trick I’ve learned in Japan: there are a million ways to tell people “no”.  One way to tell people “No, I don’t want your business if you’re in health care” is to make them check a box certifying they are not in healthcare at signup.  That increases friction and demonstrates contempt for potential customers.  Instead, I’ll say yes, I do want their business eventually (after I get the kinks out of my system and have hardened the security and legal representation enough to feel comfortable with soliciting their business), but it won’t be today and it won’t be cheap.

Common among all plans: the first month will be free (capture credit card on day 1, bill on day 30 for month #2, etc etc), and I’ll have my usual 30 day money-back guarantee.  I’d like to offer discounts for multi-month signups, but I think that Paypal may not be too keen about that until I have some history with this business, so I’ll be avoiding it.  (Oh, trivia note: Paypal Website Payments Pro + Spreedly for subscription billing.)

At these price points, the cost of providing the service (Twilio calls) would cap out at about 30% if customers routinely rode their plans to the limit.  On experience and knowledge of the industry, I think that is highly unlikely, and expect to pay something much closer to 5 ~ 10%.  Obviously, I’m never going to characterize this as a 20x markup on Twilio services to my customers, as my customers don’t care beans about Twilio: they care about making sure their expensive professionals don’t idle for lack of work.

Early Reception From Potential Customers

Sadly, I’m not in a position to get this localized into Japanese at the moment (Twilio doesn’t quite have first-class Japanese support, and I have severe doubts about my ability to market effectively domestically).  This means that I can’t exactly walk over to the massage parlors around town and ask them to try it out.  However, I’ve been talking to friends from high school who work in service industries to verify that my assumption of what their problems are is indeed accurate, lurking on message boards (the number of posts deleted for excessive vituperation about missed appointments suggests to me that there may indeed be a market need for this service), and have been doing keyword research.  There appear to be healthy volumes in the core keywords, although I wish it had a built-in longtail search strategy like bingo cards did.

This summer I’m going back to America for about a month to visit family, do a bit of consulting, and have something of a vacation.  Over that time, I’m going to be taking the demo (or the product) on my laptop and showing it to as many service providers as I can stomach seeing.  Thankfully, I expect that they’ll indulge my request for an interview — I intend to pay them their normal hourly, so coffee and a discussion of their industry and opinions about the software will work out just as well as offering a haircut/massage/etc would.

Business Plan

I didn’t write a formal business plan last time and I have no intention to devolve.  That said, I do intend on documenting and revisiting assumptions.  As usual, I’ll be doing most of that on my blog, so you guys are welcome along for the ride.  I’ll also continue my general transparency policy with regards to what works, what doesn’t, and what my statistics are looking like.  That probably won’t rate automatic reporting for a few months yet — no sense building things to track the sales I don’t have.

I’ve essentially got two notes for marketing and intend to be hitting both of them: SEO and AdWords.  AdWords is likely going to be a tough nut to crack in this market due to high spending by companies with very, very high average ticket prices, but most of my competitors do not strike me as extraordinarily web savvy, and I think I can out-think their outsourced SEO/SEM teams.

In terms of reasonably achievable goals, I’d like to have v1.0 of the service open and accepting money by the end of June.  I think that two hundred paying customers is a very achievable target for a year from now, although I’m still not sure yet how being full time affects my skill at marketing, so that might be understating things by a bit.  The last time I made a sales prediction for a new product was when I expressed the wild desire that Bingo Card Creator eventually sell a whole $200 per month.  I hope to be every bit as mistaken.

A Quick Request

I value your opinions tremendously.  If you have suggestions related to the business or forthcoming feature set, I’d love to hear them.  If you have any particular areas you’d like to hear about in my upcoming blog posts, I’d love to hear that, too.

I’m coming to the market several years behind most of my competitors and will be playing catchup for quite some time.  I would be indebted if you took a few minutes to blog about Appointment Reminder.