I haven't found the need to use much software to manage the daily operation of Blot. We like email because it is quieter and less hurried than messaging applications. We like working with plain text to manage our tasks and organize our plans because they are easy to track and share.
We use a text-file (todo.txt) to keep track of tasks. If somebody needs to be notified when a task is complete, I include a link to the appropriate email thread in the task. This text-file is checked into version control which means we can easily summarize our completed tasks – the feed of work completed on Blot's news page is generated automatically from this todo list.
I've used a variety of complicated tools to track tasks in the past but I still prefer a text-file.
I use a spreadsheet which I update once per month with my revenue and costs.
My email inbox only contains email to which I need to respond. Once I respond to an email, it is archived. If there is a longer task which I need to complete, I will make an entry in todo.txt with a link to the archived email thread, so I can follow up with the customer as soon as the task is complete.
We use Gmail to host our email, since despite all the downsides its interface is the best available. We pay them a few dollars a month so we can use our own domain.
We use Stripe to process payments. They have been excellent.
Before working on Blot, I hadn't had a customer-facing job. Here are a few of things I have learned over the years. It's worth mentioning that Blot's customers have been polite and good-natured, even in situations when a lapse in politeness would have been reasonable.
We use a text-file to track all of the tasks for Blot. If the task involves following up with the customer – perhaps fixing a bug or adding a feature – we add a link to the relevant email correspondence.
Because this text-file is also used to render our News page, the customer has a public committment from us that we will fix their problem. This helps, especially when the problem takes a while to solve.
Plenty of the suggestions we receive from our customers are good and are eventually incorporated into the software. However, when the suggestion isn't suitable, it's important to learn how to say no politely and concisely. This became easier with practice.
Asking the customer to provide information that is easy to look up
I often find myself asking the customer information that I could look up with a little effort (what's the URL to your site? which blog post are you having that issue with?). Responding with even a single question back makes it much more likely the customer will lose interest in the issue, which sometimes feels like solving the problem, but really isn't.
Taking too long to respond
When the customer's inquiry involves a bug whose solution is easy, I found myself waiting to fix the bug before responding to the customer. The proper way to handle things is first to respond saying I am fixing the problem, then follow up with a response when the problem is fixed, rather than leave the customer in the dark until the problem is fixed.
Avoiding responsibility for mistakes
When a bad bug in our product affects a customer, I found it easy to use language which seperated myself from the bug. I find it annoying when people fail in their job and don't take responsibility for it. I don't want to do that myself, although it is tempting.
Mistyping the customer's name
I have made too many errors transcribing a customer's name from memory. I now copy and paste the name to avoid these mistakes.
Constantly checking my support inbox
I often find myself aimlessly refreshing the inbox for supoprt requests when I should be working. I also find myself distracted by a new support
I try and end all of my communication with customers with something along the lines of Can I help you with anything else?. I know it's cheesy but I worry that without it, an excessively polite customer might worry that I'm somehow annoyed that they've emailed me to ask something they could have found out with one or two web searches.