We’ve been working on our first product for almost a year now. While we still enjoy every second of it, there have been a few areas that take away from what our users really love — adding features. When we began development, most of our time was spent on implementing features and polishing the application. Since launch, development time now comes in at around 80% (20% goes to support), and only about half of that time is spent implementing features that our users actually see. Here are some of the tasks that aren’t always thought about when making an application, but that eventually need to be considered.
Account Management
To aide support, account management is crucial. The idea is that a customer can be viewed, and in one glance their support, billing, and usage history can be seen. Given that information, the support admin can then fix outdated databases, upgrade, downgrade, cancel, refund, and perform any other task with one click. Ryan Carson writes on how making it easier to help your customers results in better service.
Stat Tracking
You make what you measure, or so they say. That said, graphs and reports on signups, sales, conversion ratios, cancellations, unsatisfied customers, and more over time periods of days, weeks, months and years are necessary.
Attracting Users
Word of mouth is great, but how else can we get users to our site? Whether the method is advertising, referral programs, SEO, conferences or promotions, tracking performance must be in place. And once a user gets to the site, it is important to know what makes them signup, and what makes them leave.
Inactive Accounts
So a ton of people sign up for a free account. Great! But eventually they become a burden when they start to take up server resources. To remedy this, we flagged any free account with no entries or logins in the past 3 months as inactive. At first, we were going to simply delete these accounts, but that wasn’t good enough. We wanted people to be able to restore their accounts, so we had to work out a way to programmatically back up their information. Once that was completed, what would the user see when they logged on, and how would their account get restored. The site had to be visually modified, and a one click restore had to be added to the account manager.
Documentation
This is something we’re still trying to figure out how to handle properly. In addition to trying to stay up with the text and videos of the actual documentation, we have to figure out and track how to move users with questions from within the program to the actual documentation. The ultimate goal being to reduce support tickets to 0.
Rewriting Code
Yes, almost 85% of our code has been rewritten since launch, and the other 15% will follow shortly. There are multiple reasons for this, but the main three are for scaling, optimization, and preparation for an API. We can imagine that this number would decrease if the 3 of us made another application, but there are definitely some growing pains.
Inactive Accounts -“so we had to work out a way to programmatically back up their information” - Can you give us an idea of how you did that? Whats involved? Thanks.
“Rewriting Code - Yes, almost 85% of our code has been rewritten since launch, and the other 15% will follow shortly.”
Aren’t web apps the best?
For inactive accounts, the method will change greatly based on your setup. For us, we have a master table with all accounts, so we had to add a 1 or 0 column to it showing if it is inactive or not. Then, we had to create a file structure to store our backups in. In some cases you can do a mysqldump for the rets of the data, and in others you might have to run queries to build a custom sql backup file. The goal is to store all customer information in an SQL backup file, so that is where the difference will be per application. Then for the restore, all missing tables are recreated, and then the batch file is executed again, and the customer is flagegd as active again.
One thing we have been trying to decide, is whether to create a database per account, or run x accounts in the one database.
Any advice on this?
Really depends on what you’re building and what you’re comfortable with. We’ve done both approaches and they both work. One DB per account has the advantage of isolating problems and keeping things organized. But it also takes a good hit on the RAM of your server (especially during backups) so you will need about 4gigs more per server than a standard approach. I would make the choice depending on what you are doing. If each account can reasonably grow outside the limits of one table, the multiple DB’s might make sense.
Hey guys— would love to hear about the “attracting users” portion. Wufoo doesn’t inherently create a large “net” of SEO optimized pages like a lot of other startups (forums, wikis, blogs, vertical search sites, etc).
What advice do you have to bring in folks besides the occasion news mention and adwords?
I ‘stumbled’ across your site whilst actually searching for something else, however the well written and useful articles made me stop read and subscribe. The latest “The underbelly of a web app” I enjoyed not just because it was interesting but I found that the content actually applied beyond the scope of the original title with many of the points raised equally applicable to any area of good customer service.
Tony, that could probably be an essay all on its own. Right now, word of mouth is huge for us. We do our best to provide awesome cusotmer service, and that goes a long way. We have done a decent amount of SEO (only the clean stuff) and it has worked out quite well. We’re now on the first page for many of our search related terms. Two things we haven’t done at all are separate landing pages, and advertising. We will be getitng into both of those within the next 2 to 3 months, so we’ll see how they work out. Chris has all of the stats on this stuff, so maybe he’ll write up on it one day.