I did it for 10 years, but more recently have moved away from phone support as much as possible (or delegated to others to do).<p>The main reason - I am a solo developer. And the brain mode for 'developer' is VERY different from the brain mode for 'support agent'.<p>It was basically impossible for me to get into 'flow' state during a normal working day. Even one phone call during the day took me away from my creative, programming mindset and into an empathetic, listening mindset. And the transition between the two were very different. It's like asking a racing driver to knit a scarf each time he came into the pits, before he could go out on the track to drive at high speed again.<p>It also made it hard to plan blocks of work. Most times it was OK, but there were days where I would plan to do about 5 or 6 bug fixes, but I would get a slew of phone calls that meant I got 0 programming done that day, and would have to move other plans.<p>I actually enjoyed support, but in the end I had to decide which of the two parts of the job was moving the business ahead more than the other, and pure development work won out.
Working at the Apple Store as a sales person has helped me IMMENSELY in my career, not only in terms of understanding how human beings approach technology but from a sales standpoint as well. In the first startup I was a part of, every single member of the 3 person team did email support for our school teacher userbase. Do it. Everyone needs to do it. Doing this kind of work is very grounding and humbling.<p>When you box yourself into the "But, I'm an engineer" corner and decide it's beneath you to talk to customers, you limit yourself. Don't do that. Become a more well-rounded person. Talk to your users. Understand them. Empathize with them. It will make you a better engineer. And if you're a solo founder or part of a small team, it's even more critical that you do this.
I've been doing this for over 15 years with an invoicing app I have and I've got to know a lot users pretty well over that time.<p>My app is simple and easy to use, and I've made "Training Videos" for just about everything you can do with, and I've had years to work out any bugs that have popped up, so I don't get a lot of calls anymore. But every call is a chance to learn something and improve the app and I pay very close attention to those who call.<p>My approach is that it's never the user's fault, and I tell them that. I work click by click with them to show them how to do something and I tell them if something doesn't work it's my fault and I will fix it. And I also ask them how they think it should work.<p>Before I made my first app back in the `90s I read a book Apple put out called something like "Apple Human Interface Guidelines". At first glance I thought it was a waste of money, but since I'd spent it I decided to read it all.<p>It explained some of the history of the Apple GUI and how and why things were designed the way they were, which was basically on things people were familiar with, like "Radio Buttons" and "Checkboxes", etc.<p>By the time I was done I realized the genius in the approach. I'm still impressed with it. My goal has been to make web apps that the user doesn't have to learn anything to use. That it all works like they expect it should. After 15+ years I've got pretty close now. I rarely get any calls or emails.<p>Kind of feel like the "Maytag Man" now.
I created a shareware Tetris clone for OS X in the mid 2000s and provided my cell number in the readme. I'd get a trickle of calls from all over the world at all times of day. That's where I learned never to have a serial number generator that included the number 0 since it looks so close to the letter 0.<p>It was weird to be out and about and suddenly get a tech support call, but people were usually really nice.
It is very, very difficult to offer phone support as a solo developer, particularly at low price points (below e.g. $5k per year) and for low tech-literacy customers. You can still <i>do</i> it, if you need someone to talk to, you want to do customer development, or you have a customer who strikes your fancy for non-market reasons, but you probably should not message the expectation that you're available.
My experience with doing phone support for applications is that it is <i>excellent</i> if well-augmented, and absolute garbage otherwise.<p>Due to a variety of factors, my previous employer provided about 50-50 phone and email support, often with phone as the first point of contact. That worked because phone calls came in with proper context (essentially providing information about who is calling and information about their account status) and I had tools to guide callers when something wasn't extremely basic: most applications are primarily visually- or textually-rich environments, and verbal descriptions require a high degree shared context on both sides (e.g. you are a competent CCNA contacting Cisco TAC, and both parties share a common verbal language to describe non-verbal tools). Absent that, screen-sharing capability is critical, as otherwise phone support is endless dead air of "I'm looking at things you can't see while you describe things I can't see and have no context for, let's both black box everything and pray for telepathy." My current employer doesn't provide that, so phone support devolves into a push button for customers to say, "this issue is urgent!" while support says "probably, but we can't send you screenshots over the phone, so please go away while we write a response that actually provides useful information--you can remain on the phone if you want, but it's going to just be dead air or us talking you down from panic mode while not actually doing anything to address the problem."
I offer phone, email and skype support (as a solo developer). Ratio of support queries I receive is roughly:<p>90% email
8% skype
2% phone<p>On my website's contact page I have a few sentences beside the email address saying that you should give as much information as possible about the problem, and that we reply within 1 business day but normally sooner. I think that implies two things: [1] we do actually reply to emails quickly, and [2] email is preferred for support.<p>Some people just prefer to talk to a human being, at least the first time they contact you. This is either due to them checking to make sure you are responsive and can be contacted, or they are frightened of technology and need a little hand-holding. If I didn't put my phone number of the website I might lose these customers. It doesn't really take much time to deal with, overall.<p>The only minor issue is that some people (mostly other developers, usually from India) seem to want submit all support requests via skype, and I have to push back at that because [1] it's intrusive and [2] it means I don't have a record of their previous support queries in my email. Unless it's a quick question, I usually email them back. Of course you have to balance the need to provide the support in the way the customer wants to make them happy vs not letting them suck up too much of your time.
Man, I did a job that was nothing but phone support for 8 months, and while I think it was great training for designing UIs that won't confuse people you'd have to pay me a lot to go back to doing that. Many people are <i>not</i> kind, patient, or understanding, and they assume you're unintelligent and uneducated (or else why would you be answering phones for a living?). The misery of that experience was the spur that made me abandon plans for a career in Japanese translation and learn IT (and eventually programming) in the first place.
Support person (at least for the last few years) here, context switching and the issues it creates is a real thing for other roles - not just developers. Everyone needs headphone DND time, both in and outside for the technology sector - it's called concentration time.<p>A support agent at most tech companies will have to support multiple products in multiple languages and platforms and be ready to provide a useful response to a customer at any time, these responses could be:<p>Diagnosing code issues,
Diagnosing product issues (internal or external)
Writing code for the customer,
Developing the customer use case,
Working with Engineering,
Finding some free time to learn new products,
Training new agents<p>etc etc.<p>This is no easy task and shifting mindsets is sometimes tough.<p>I strongly echo the comments that documentation is key, if the product docs are written to be consumed by humans it's very helpful support engineers, we're lucky to have great documentation at the company I work so it makes our life easier.
I'm also a solo developer, and I take support and sales phone calls for FormAPI [1]. I found a nice number on Twilio: (856) FORM-API<p>I have a license for on-site deployments, and I think every enterprise inquiry has started with a phone call.<p>I also send a welcome email to new customers where I say that I'm happy to have a call to talk about their requirements or questions. I also use Drift [2] for live chat, and I've handled a few support cases on there.<p>My advice: I don't think this is an optional thing. You don't solve the problem by removing the phone number from your site. If you're getting too many calls, you need to improve your self-help support pages, or hire another person to help with the phones.<p>[1] <a href="https://formapi.io" rel="nofollow">https://formapi.io</a><p>[2] <a href="http://drift.com" rel="nofollow">http://drift.com</a>
Because my startup's tools are used heavily in the dyslexia and ADHD communities, I have found that phone support is a very helpful thing to offer. Some of our users have difficulty reading/deciphering our instructions, but they have no problem once we provide directions verbally on the phone.
What a mundane post and simplistic topics. Yet it was outstanding. How come I loved reading it? Nice work Non.<p>One thing that wasn’t a big point, but I hope most people appreciate: Founders/developers/key employees doing some phone support is not tactical grunt work, it can be a strategic, powerful weapon.<p>In essence, it’s white glove, world class customer service. That alone is good, but what makes it so powerful is it’s on a very small list of things that AmaFaceGoogSoft and other large companies can almost never match you at. In fact forget beating you, they often do poorly at it. Every know anyone who left angry after dealing with F500 support?<p>In a past life I’ve used high six figure “enterprise” support agreements, w/VIP status. Yes, way better than the Windows consumer help line, but hard even then to match your service. 1MM/yr enterprise support doesn’t buy a product dev or exec. Ironically, it’s easy to lunch with them, but they’re not handling your daily tickets.<p>Your sales person (you I guess :-) should use it as a club against big companies and do your best to beat them to death with it.<p>Other things you touched on can also be strategic. Gaining valuable insights (admittedly not the only channels for this) that optimizes your roadmap, occasionally is the difference between staying afloat and sinking.<p>Of course the reality check is, how much time can you allocate when not only is development a life blood role, you probably wear other hats as well? I don’t think there’s a stock answer, depends on team/company/stage/everything else in the balance.<p>Anecdotally, I can say one customer relationship built this way turned out to be the connection that led to the acquisition of my company. However as usual, it was impossible to foresee when the contact request email came in.<p>I mean it as a compliment that you’re post seems deceptively ordinary (speaking plainly is good), I hope people will mine the true value of it. Thanks for writing it, best of luck to you going forward.
Interestingly enough I've found through my own company that it's not so much whether or not you're solo but rather the price of your software that determines if you can economically offer phone support or not.<p>I wrote about it here: <a href="http://www.followsteph.com/2006/10/10/is-technical-phone-support-a-viable-option-for-a-software-company/" rel="nofollow">http://www.followsteph.com/2006/10/10/is-technical-phone-sup...</a><p>I then followed it up with an article discussing whether or not companies should charge for support based on my findings in the previous article: <a href="http://www.followsteph.com/2010/10/19/should-software-companies-charge-for-technical-support/" rel="nofollow">http://www.followsteph.com/2010/10/19/should-software-compan...</a><p>The short version, under the $1000 price point it's very hard to economically offer free phone support as part of your product. If you're product is subscription based then the same metric applies using the total lifetime value of your customer. Under that price it's very hard to do, whether your a solo developer or a company without charging for support.
I'm launching an app soon, and was planning on making customer service an available and plentiful commodity, not hiring any employees yet, so therefore I'll be the de facto phone support guy. I hadn't considered the emotional benefit of both urgency from the negative, and encouragement from the positive, I was mostly thinking about hearing first-hand the bugs, use cases, user experiences, etc, and being able to put out any fires asap. Thanks!
This was very well written. Effective communication with people is far more challenging (and rewarding) than the communication with devices that we developers do on a day to day basis. It’s easy to get lost in that cloud, and lose touch with the people we’re building for.<p>In startups, this aspect can too quickly get shunted off to a QA or CS personnel, and problems get abstracted into incident tickets (that are often ignored in favor of the Next Big Feature). That seems to me to be giving up one of the classic fundamental advantages of a small business: the personal touch.
I absolutely _loved_ doing phone technical support, but I don't do it any more because I can't afford it. I earn far more money as a developer and I can't turn that down. I wish good support was valued more highly , and compensated accordingly so I could afford to keep doing it.
Many people admire Steve Jobs, sometimes to the point of mimicking him by wearing jeans and black turtleneck sweaters.<p>Steve Jobs would sometimes answer to customer support calls. This was in order to understand the customer, their frustrations, and how to work through them with a better product.
Great article. An effective engineer needs to know how to work with non-engineers. Unless, you're on a team composed of purely engineers and don't need to interact with non-engineers. But even then, it's a good skill to hone for potential career changes in the future.
This reminds me of Word Perfect's unlimited free phone support years ago. Though the call to Orem, UT during business hours was neither free nor inexpensive, the service was excellent and part of the reason Word Perfect was so beloved...reveal codes being another reason.
Thank you very much. I am very glad to see this as #1 here.<p>There is a typo on Voicepaper's description in iTunes. It reads "Voicepaper is a test to speech voice reader..." instead of "Voicepaper is a text to speech voice reader".
What I'm curious is how he markets his apps and what kind of revenue target he goes for.<p>I know just posting something on the app store is not the way to go. As an iOS developer I know it's tough to be a solo app store developer successfully.
I'll be interested to read your follow-up post on the differences between offering phone support in Japanese and English. A few of the interactions you described here sounded distinctly Japanese to me.
I recently thought about the idea of holding "office hours" of sorts, which would help with the context switching I've seen mentioned.<p>Has anyone been able to monetize phone support as an upsell?
Interesting. I always thought putting personal phone number in your app is a bad idea, but you raised some good points there. I might consider to do that if I release an app for local market.