I'm the co-founder of a company that provides "elastic customer service" (influx.com) and I'm happy to share with you what I see happening in practice.
Most founders start out doing customer themselves. This is absolutely the right thing to do for reasons outlined elsewhere in this thread.
When the business grows, the the founder(s) can't continue handling 100% of customer support, both because there other priorities and because the volume grows beyond what the founders can personally handle.
Generally in this "transition phase" time-to-first-response grows steeply.
I wrote about my experience providing customer support on a open source project, you can see where the "wheels started to fall off" - ie time to first response climbed steeply:
At the time, I felt bad about TTFR growing steeply.
I now understand that it's a really common state of affairs.
So at some point, the founders need help, and they either hire or outsource, or do a combination of both.
You asked about "the average time it takes you to resolve customer queries". A typical time-to-first response before Influx starts working with a client is 12-15 hours, with a outliers at 1-2 days.
On "stay close to your customers" - it's 100% correct but a harder question is "how do I stay close to my customers and scale at the same time?". The answer depends on the size of the business. I see people using a combination of metrics and qualitative insights. The metrics look after big picture health and qualitative insights involve customer support staff bubbling issues back up to the product+dev teams.
Yep, the zindus addon has this problem. Very hard (impossible?) to do something automatic and risk free.
I'm not happy with the answer that I settled on with zindus: http://zindus.com/i/reporting-bugs
because there is a lot of sensitive information in a logfile.
Even when someone gives permission and sends you a logfile, if there is sensitive data it creates a maintenance burden on your end to deal with it appropriately.
One (not very good) idea: pass the diagnostic data through some sort of anonymizer. Unappetizing because it would involve a lot of work and would need heuristics that could only be learned through trial and error.
FYI, the purpose of this slideshow isn't to deliver practical skills. It's to link the big ideas in The Innovator's Dilemna to the modern database market with the intent of illustrating the ongoing relevance of the book.
And maybe to interest a few people enough that they'll go read it.
Most founders start out doing customer themselves. This is absolutely the right thing to do for reasons outlined elsewhere in this thread.
When the business grows, the the founder(s) can't continue handling 100% of customer support, both because there other priorities and because the volume grows beyond what the founders can personally handle.
Generally in this "transition phase" time-to-first-response grows steeply.
I wrote about my experience providing customer support on a open source project, you can see where the "wheels started to fall off" - ie time to first response climbed steeply:
http://moniker.net/2013/07/10/two-open-source-emails-a-day-f...
At the time, I felt bad about TTFR growing steeply. I now understand that it's a really common state of affairs.
So at some point, the founders need help, and they either hire or outsource, or do a combination of both.
You asked about "the average time it takes you to resolve customer queries". A typical time-to-first response before Influx starts working with a client is 12-15 hours, with a outliers at 1-2 days.
On "stay close to your customers" - it's 100% correct but a harder question is "how do I stay close to my customers and scale at the same time?". The answer depends on the size of the business. I see people using a combination of metrics and qualitative insights. The metrics look after big picture health and qualitative insights involve customer support staff bubbling issues back up to the product+dev teams.