TE
科技回声
首页24小时热榜最新最佳问答展示工作
GitHubTwitter
首页

科技回声

基于 Next.js 构建的科技新闻平台,提供全球科技新闻和讨论内容。

GitHubTwitter

首页

首页最新最佳问答展示工作

资源链接

HackerNews API原版 HackerNewsNext.js

© 2025 科技回声. 版权所有。

Emailing SaaS companies to test support time

56 点作者 steve-benjamins将近 9 年前

13 条评论

travelton将近 9 年前
I&#x27;ve worked with two startups now, both with low support volumes, which grew many times upon acquisition. In both cases, these acquisitions brought upon an influx of new customers. It&#x27;s simply bad business to scale your support staff based on MRR in the long term.<p>When the tipping point between growth and headcount arrives, a dev is usually assigned to figure out how to slow the incoming requests. There are many ways to do this, and some of the best companies have figured it out and mastered it very well at scale (see Google, Facebook, etc).<p>Some ideas:<p>1. Offer self-help&#x2F;self-resolution documentation or tools (Gmail&#x27;s self help is quite good!).<p>2. Categorize support requests, capture low hanging fruit, deploy fixes (sign up deficiencies, UI bugs, etc).<p>3. Set up a status page to proactively notify customers for outages&#x2F;maintenances.<p>4. Increase customer communication when large functional or UI changes disrupt users.<p>5. Automation&#x2F;AI&#x2F;Bots (Not easy, and hardly ever done right)<p>6. Offer chat to increase interactions served by a single CS agent.<p>An interesting method, that is often heavily debated... Only offer support to paying customers. I think businesses can only get away with this, if they offer plenty of self-help documentation&#x2F;tools, and your core product is relatively rock solid. Operating on a freemium model always brings about interesting challenges.<p>Edit: Formatting.
评论 #11972284 未加载
gk1将近 9 年前
As Nassim N. Taleb said, you wouldn&#x27;t attempt to walk across a river that&#x27;s <i>on average</i> only four feet deep.<p>If you look at the raw data (kindly provided at the bottom of the post), there are tremendous variations for individual companies between two email attempts.<p>For example:<p>Formdesk: 987, 6<p>Get Response: 4, 1445<p>Appointy: 12, 1209<p>Two attempts just aren&#x27;t enough to reach conclusions.
评论 #11970509 未加载
评论 #11970972 未加载
trjordan将近 9 年前
The larger companies were probably slower because they have started prioritizing their support tickets by how much you pay.<p>If you signed up for a $5,000 &#x2F; month plan with all of them, then emailed support, you&#x27;d have a different experience.
评论 #11970793 未加载
评论 #11970766 未加载
评论 #11970443 未加载
pcora将近 9 年前
While I find it interesting, I would be more interested in seeing the times of these companies when you are a paying customer. I expect faster responses, but I would not get surprised if some took ages..
评论 #11970919 未加载
codezero将近 9 年前
If you&#x27;re interested in a similar post, StatusPage emailed 100 companies a few months ago and wrote it up here: <a href="http:&#x2F;&#x2F;blog.statuspage.io&#x2F;customer-service-email" rel="nofollow">http:&#x2F;&#x2F;blog.statuspage.io&#x2F;customer-service-email</a><p>I&#x27;d really prefer to see the questions and depth of reply. Time to respond can be easily lower bounded by giving a shitty answer fast.<p>In my experience, customers are much happier with a response that takes longer, if they: 1) know it will come and 2) know it will be thorough.
评论 #11971542 未加载
zimbatm将近 9 年前
At what time did these emails get sent out?<p>I wouldn&#x27;t be surprised if overseas companies for example took longer to respond just because you reached them out of office times.
评论 #11971183 未加载
bks将近 9 年前
They should all be using <a href="http:&#x2F;&#x2F;www.leadactivate.com&#x2F;" rel="nofollow">http:&#x2F;&#x2F;www.leadactivate.com&#x2F;</a> - it takes an inbound email and then places an inbound call to a phone number or multiple phone numbers and then uses text to speech to notify the agent about the call.<p>Typically used for sales, but it reduces response times down to about 20 seconds for inbound emails and leads.
FatAmerican将近 9 年前
I would also expect the times to be shorter for paying customers who contact them through established channels.
tonyedgecombe将近 9 年前
I&#x27;m quite surprised how quickly people responded, I thought it would be longer.<p>In my business I commit to one working day, although issues don&#x27;t usually wait that long I don&#x27;t know how I could shorten it without having someone dedicated to support.
troydavis将近 9 年前
For any given SaaS company, the fastest response is probably not the optimal result. At least 3 other variables are equally important:<p>1. Quality. How thorough is the response? As the blog post says, &quot;Plus email reply time says nothing about the quality of support.&quot;<p>2. Cost. Are customers willing to pay more for speed and&#x2F;or quality (either in dollars or because the company spends less elsewhere)? Up to what point?<p>Those 2 are the obvious trades (<a href="https:&#x2F;&#x2F;en.wikipedia.org&#x2F;wiki&#x2F;Project_management_triangle#.22Pick_any_two.22" rel="nofollow">https:&#x2F;&#x2F;en.wikipedia.org&#x2F;wiki&#x2F;Project_management_triangle#.2...</a>). There&#x27;s at least 1 more:<p>3. Point of diminishing returns. Assuming a customer is willing to pay more, what&#x27;s the real impact of a longer delay or lower quality? How {fast,good} do they actually benefit from?<p>Faster is only better when the test is only measuring speed. If you&#x27;re reading this post and thinking &quot;Man, our team should respond faster!&quot; -- maybe they should, but maybe those other factors mean they shouldn&#x27;t.<p>To give three examples I&#x27;ve seen in support teams:<p>- Company A has a big team of inexperienced staff sending fast responses. They succeed on speed (and would show up at the top of this list), but probably fail on quality. As a user, this is form letter hell.<p>- Company B has a big team of very skilled staff sending fast responses, or has developers or whole engineering team task-switch when a question comes in. They succeed on speed and quality but, depending on the product, probably fail on cost. May also have lower quality, since customer support&#x2F;service is a skill that not everyone does well. As a user, this feels great. Sometimes the person who coded the feature I&#x27;m asking about is replying to me. OTOH, if I don&#x27;t actually need knowledge that&#x27;s unique to them, their time may be more valuable working on that feature :-)<p>- Company C succeeds on all of these, with a right-sized group providing high-quality answers quickly (let&#x27;s say 2 hours, not instantly). Alas, customers aren&#x27;t willing to pay for that. Their customers perceive diminishing returns from answers in less than 24 hours, and&#x2F;or the price premium they want to pay for a faster (or maybe more thorough, or more clearly written..) answer is very low.<p>Sounds obvious, but based on how often companies make one of these mistakes, it&#x27;s not. When one aspect is relatively easy to measure and others are hard or impossible, they tend to lose.
timlod将近 9 年前
I think talking of average when the sample size is 2 is misleading. I find such a test (and possible conclusions) interesting, just wished it was carried out in a more rigorous way...
exolymph将近 9 年前
It&#x27;s interesting that big companies did worse. I guess because they tend to have longer support queues?
评论 #11970431 未加载
bluejekyll将近 9 年前
Out of curiousity, why wasn&#x27;t Salesforce part of this study?
评论 #11970733 未加载