Hi there! This is Liz from HiOperator. We set out earlier this year to build a scalable US-based customer service solution that we would have used as startup founders ourselves.
Would love your thoughts! Happy to answer any questions and tell you more.
Our usual onboarding time is around a week although our record is 1 day for a company that was in a tight spot. We don't charge setup fees for most situations. It's built into the price and we want our customers to stick with us because they like the service - not because they've forked over a large upfront fee!
Hi, I'm Phil, the other founder. I'd say keep it as a core competency! It's important and it's why we're in business. We understand why you'd want to do that and all of the companies we work with feel the same.
That said, keep in mind there will always be a lot of repetitive time consuming stuff, and that's where we excel. Everyone likes to think they're a unique and irreplaceable snowflake, and that may be true in total, but there are parts that can be handled more efficiently elsewhere.
I would love to hear some more detail about how you tackle onboarding / knowledge transfer. How do you handle a more complicated business that may have a lot of different edge cases? Do you just build up exhaustive documentation?
Also, I know you're just starting, but I got to your site and wanted to read a LOT more about your service than the information that was available on the single page site. I was thinking: Tell me way more about how it all works, but there was no where else to click! :)
I can speak about onboarding and knowledge transfer from the viewpoint of our clients. Usually they give us access to their past tickets and we have an hour long conversation where we ask a million tailored questions. Then clients put us in a sandbox to play where we can't hurt anyone. To fill knowledge and capability gaps, our ops managers pose questions to in-house teams, usually over Slack, but it can be anything. Once everyone is comfortable, they let us out into the world. :)
On the back end, I wish I could brag a little about this, but it is our "secret sauce" so I'm just going to have to say it's proprietary and I believe the beginning of something great.
To directly answer your first question regarding edge cases, it's simple: we don't do them, opting instead to let your in-house team do the complex edge cases. Over time though, we inevitably end up doing some of them as we find commonalities across clients (shipping exceptions, insurance disputes, etc).
Incredibly optimistic about the future for HiOperator. Having run a 100+ agent contact center, they are solving some complicated challenges that many growing companies will undoubtedly face.
Somewhat tangential to what you're doing here, but I was a Technical Lead at Support.com for 5 years. We did general support and malware-specific support but we also had contracts where we would troubleshoot a specific product or brand. We, like you intend to, had a large, distributed workforce.
While the business development team there (along with their head of training, Mary Waltuch) are largely responsible for the constant failure of that company, I think that SPRT's experiences proves unequivocally that this business model does not work at any reasonable scale.
Your clients are strongly incentivized to demand your service at a significantly lower rate come contract renewal regardless of what your cost to deliver is. Your competitors, like Support.com and Sutherland, among others, will happily underbid you. Aggressively. While I worked there, I had my salary and benefits _cut_ at least once a year.
You'll cut costs by moving some operations to places like the Philippines while not learning the lessons of others who have done the same. One bad monsoon season and none of your workforce will show up for weeks/months. Support.com learned this one the hard way, despite my warnings.
Maybe you'll show some backbone in negotiations, not bend over and take shitty contract terms from "huge brands" like our bizdev did at SPRT. This is more critical to your success than you can imagine. We sure did love hiring bizdev people whose experience was at failed companies (RadioShack, Circuit City and a bunch of people from Intuit who got sacked).
Best of luck to you. I really hope that you succeed...there isn't really good service from anyone in this market segment right now; the training is poor and it's a race to the bottom on price. Consumers need this to be good. Don't f' it up.
Thanks for commenting - it’s good to get your take on things. We’d love to chat further if you’d like - ping us at hi@hioperator.com .
A few quick thoughts though. We are committed to keeping support local - in this case in the US. We’re not trying to be the lowest cost option, nor are we trying to handle the long tail of customer support. We focus on 80/20. And there is plenty of 80 to be had, even at scale.
There are a few specifics to how we’re organized and how we incentivize our agents that we’re seeing help align incentives a bit better.
I knew a few who worked at influx.com , similar story. This business is a race to the bottom , clients want it cheap or they can just do it in house otherwise
Reminds me of a recent negative experience with Apple Customer support. I had an issue, and they bounced me around to several different people for pretty much no reason. Then they harassed with me "Senior" Apple advisers after the issue had already been resolved. It's pretty amazing that a company as big as Apple still has no idea how to do customer service. Looking forward to someone teaching them how it's done. Then again I also feel that it might be even more complicated for a third party to support me with that...
Thanks for the perspective! To be fair, we can't claim to have any experience running operations at the scale of thousands and thousands of agents - we think we know a way to get there someday soon.
As a related tangent, one thing we do for a few companies is essentially serve as air traffic control. Even if we can't solve all of the issues and some issues need escalation, we help make sure that it's only one hop away from the right group.
I like the idea, but you guys really miss the mark on costs. I don't know where you got the idea that any small business or startup would be okay paying this. Definitely out of reach for 99% of the businesses out there.
--------------
From the website:
--------------
$999/month
Starting at $3.50+/case for most everything
Starting at $1.25/minute for a voice operator
8 hours of coverage, 5 days a week
--------------
My small project handles about 30 cases per day, I spend about an hour on the phone with customers, .
That's 76,788 a year. Can you even hire someone to do product support for your startup in SF for that? Salary, Taxes, Insurance, Office space? I have strong doubts.
And that would just give you _one_ person who can only do one call at a time. If you can't justify hiring an employee to do this, you aren't a target customer of this service anyway, I imagine.
I KNEW this was going to be an answer. "OH IN SF YOU HAVE TO PAY SO MUCH MONEY FOR SALARIES so it makes sense if you're in SF." That's ridiculous and you know it is.
Most businesses aren't in SF, most startups aren't even in SF. Yes, I know you think you guys are the center of the world. But there is a reason call centers are in lower income areas and its not because people are just getting around to decentralized support centers.
Amazon has been doing this for.. nearly a decade already? Other companies do this in the Philippines. It has nothing to do with justifying an employee, it has everything to with justifying hiring 3-4 employees (or even 10) rather than one service who is just going to be a glorified answering service.
Woah, guy. I'm not even in SF. Wouldn't work there for any amount of money.
I'm just saying that the obvious immediate market for this to me seems to be towards b&m or medium-touch product sales businesses that are _in_ areas like SF. Many Bay Area startups are selling services to other Bay Area startups, that's just the reality of this sort of thing.
If you're not their target market, you're not their target market. If you are looking to hire people and this ends up being a viable alternative you will save a ton of money.
I worked in/around call centers for most of my first career, I know the score.
Most of the companies that we work with actually aren't in SF either.
Think of it as an AWS analogue. If you are a company running some large predictable number of servers with a constant load, it's probably cheapest to just have a rack of servers, if the scale can cover the people to maintain them. If you have varying loads across different days and seasons though, AWS might make a lot of sense since you don't have to pay for servers sitting around idle. That flexibility comes at a premium.
To take it a step further, if you're a slightly smaller company that values time and agility and doesn't have a large dev ops team in-house, you might want to use a PaaS, like Heroku.
I'm not sure how you arrived at that figure, but it seems a bit high for the use case you described.
Now might be a good time to clarify our pricing a bit and state that our pricing is not a one size fits all model. We analyze our clients ticket and call histories and find a price that works for both.
The $999 is a minimum spend and from that we deduct cases and voice minutes. The minimum covers training and overhead to ensure we're not losing money for clients that are too small. We've also found that, in our experience, companies who tend to spend less than $999/month are sometimes still at the point where their support tickets are full of a lot of edge cases and are best handled in-house.
We're aimed at small and medium companies, not individuals running small projects (yet). Someday in the future hopefully, but we're not there yet.
I arrived at the figure by using the numbers I also shared in my post. I didn't know that the $999 was a minimum though, i just added it as a fixed cost.
If you aren't ready for my small project, you aren't targeting small business. We have a small team and the revenue to support it, which is well into the average revenue statistically for small business.
If you don't hire within SF, your numbers don't make sense.
And for further clarification, your bill would probably be slightly higher than the minimum, but quite honestly, we wouldn't feel comfortable taking you on as a client for quite some time.
As we grow and move downstream, we'll lower prices and expand our offering. It sounds like you're just downstream; nothing to get upset about. Just wait and eventually we'll make sense for you too.
They haven't asked you questions, but you have shared information about your support usage patterns. So, I'd guess that they're still working with lighter loads and plan to go larger from there. They didn't say they didn't want your business for good.
does any company provide the inverse? I would love someone to call, wait on hold, and talk to a customer service agent for me. keep calling until they fix the problem.
Assuming your approach to handling the 80% is very systematic and process-oriented than I suspect you are destined for success.
Having spent a couple years in enterprise support, I would guess that less than 20% of the workforce carried over 80% of the weight. This was my first experience working in a support organization, and at first I assumed it was due to unusually lacking management, but after meeting people in similar roles elsewhere I think it's par for the course.
Support seems to suffer from the Peter Principle[1] more than the other enterprise departments. The few competent people who were around me were almost always using the support role as a steppingstone to learn a new technology, with no long term plan to stick around, nor any desire for promotion within the organization.
Like many new hires, I starting identifying process issues that occupied a lot of time that should have been spent more efficiently. I even documented the issues and proposed changes to improve organizational efficiency to management, who said "good stuff, thanks" but then went on fighting fires instead of preventing them in the first place. These were very basic improvements easily understood by anyone with a technical mindset who spent a week or two observing our support process. A couple years later and I hear nearly identical ideas are finally being phased into the process. I take no credit, because the people with whom I shared the ideas have moved on.
This turned into a bit of a rant, but the gist of it is I see a huge opportunity for disruption of the customer support process for any company with regular case intake. For the sake of everyone who ever needs to obtain support, which is all of us, I hope your team succeeds!
I know exactly what you mean! I worked for Marriott in support for one of my first jobs and automated myself out of it in about 2 weeks so I could play games on company time. People call in, I push 1-10 and go back to playing while I make small talk on the phone until my scripts executed. :)
34 comments
[ 2.8 ms ] story [ 72.9 ms ] threadWould love your thoughts! Happy to answer any questions and tell you more.
What would you say to a company on the fence who considers providing support a core competency within their org?
That said, keep in mind there will always be a lot of repetitive time consuming stuff, and that's where we excel. Everyone likes to think they're a unique and irreplaceable snowflake, and that may be true in total, but there are parts that can be handled more efficiently elsewhere.
Also, I know you're just starting, but I got to your site and wanted to read a LOT more about your service than the information that was available on the single page site. I was thinking: Tell me way more about how it all works, but there was no where else to click! :)
On the back end, I wish I could brag a little about this, but it is our "secret sauce" so I'm just going to have to say it's proprietary and I believe the beginning of something great.
To directly answer your first question regarding edge cases, it's simple: we don't do them, opting instead to let your in-house team do the complex edge cases. Over time though, we inevitably end up doing some of them as we find commonalities across clients (shipping exceptions, insurance disputes, etc).
While the business development team there (along with their head of training, Mary Waltuch) are largely responsible for the constant failure of that company, I think that SPRT's experiences proves unequivocally that this business model does not work at any reasonable scale.
Your clients are strongly incentivized to demand your service at a significantly lower rate come contract renewal regardless of what your cost to deliver is. Your competitors, like Support.com and Sutherland, among others, will happily underbid you. Aggressively. While I worked there, I had my salary and benefits _cut_ at least once a year.
You'll cut costs by moving some operations to places like the Philippines while not learning the lessons of others who have done the same. One bad monsoon season and none of your workforce will show up for weeks/months. Support.com learned this one the hard way, despite my warnings.
Maybe you'll show some backbone in negotiations, not bend over and take shitty contract terms from "huge brands" like our bizdev did at SPRT. This is more critical to your success than you can imagine. We sure did love hiring bizdev people whose experience was at failed companies (RadioShack, Circuit City and a bunch of people from Intuit who got sacked).
Best of luck to you. I really hope that you succeed...there isn't really good service from anyone in this market segment right now; the training is poor and it's a race to the bottom on price. Consumers need this to be good. Don't f' it up.
A few quick thoughts though. We are committed to keeping support local - in this case in the US. We’re not trying to be the lowest cost option, nor are we trying to handle the long tail of customer support. We focus on 80/20. And there is plenty of 80 to be had, even at scale.
There are a few specifics to how we’re organized and how we incentivize our agents that we’re seeing help align incentives a bit better.
As a related tangent, one thing we do for a few companies is essentially serve as air traffic control. Even if we can't solve all of the issues and some issues need escalation, we help make sure that it's only one hop away from the right group.
Suddenly I'm at $6,399 MINIMUM.
Nice try I guess.
And that would just give you _one_ person who can only do one call at a time. If you can't justify hiring an employee to do this, you aren't a target customer of this service anyway, I imagine.
Most businesses aren't in SF, most startups aren't even in SF. Yes, I know you think you guys are the center of the world. But there is a reason call centers are in lower income areas and its not because people are just getting around to decentralized support centers.
Amazon has been doing this for.. nearly a decade already? Other companies do this in the Philippines. It has nothing to do with justifying an employee, it has everything to with justifying hiring 3-4 employees (or even 10) rather than one service who is just going to be a glorified answering service.
I'm just saying that the obvious immediate market for this to me seems to be towards b&m or medium-touch product sales businesses that are _in_ areas like SF. Many Bay Area startups are selling services to other Bay Area startups, that's just the reality of this sort of thing.
If you're not their target market, you're not their target market. If you are looking to hire people and this ends up being a viable alternative you will save a ton of money.
I worked in/around call centers for most of my first career, I know the score.
That's my point, its not a viable alternative ESPECIALLY if you are going to hire people.
Think of it as an AWS analogue. If you are a company running some large predictable number of servers with a constant load, it's probably cheapest to just have a rack of servers, if the scale can cover the people to maintain them. If you have varying loads across different days and seasons though, AWS might make a lot of sense since you don't have to pay for servers sitting around idle. That flexibility comes at a premium.
To take it a step further, if you're a slightly smaller company that values time and agility and doesn't have a large dev ops team in-house, you might want to use a PaaS, like Heroku.
Now might be a good time to clarify our pricing a bit and state that our pricing is not a one size fits all model. We analyze our clients ticket and call histories and find a price that works for both.
The $999 is a minimum spend and from that we deduct cases and voice minutes. The minimum covers training and overhead to ensure we're not losing money for clients that are too small. We've also found that, in our experience, companies who tend to spend less than $999/month are sometimes still at the point where their support tickets are full of a lot of edge cases and are best handled in-house.
We're aimed at small and medium companies, not individuals running small projects (yet). Someday in the future hopefully, but we're not there yet.
If you aren't ready for my small project, you aren't targeting small business. We have a small team and the revenue to support it, which is well into the average revenue statistically for small business.
If you don't hire within SF, your numbers don't make sense.
And for further clarification, your bill would probably be slightly higher than the minimum, but quite honestly, we wouldn't feel comfortable taking you on as a client for quite some time.
As we grow and move downstream, we'll lower prices and expand our offering. It sounds like you're just downstream; nothing to get upset about. Just wait and eventually we'll make sense for you too.
How would you know? You haven't asked me any questions at all? All you've done is make assumptions and then tell me you didn't want my business.
Disclosure: knew this since just yesterday I was searching for Elm jobs to add to my wesite https://www.jobsinnew.tech/post-49/
We originally approached the customer service problem from this angle, but found our approach better suited to our vision.
They are great and I've used them before.
Having spent a couple years in enterprise support, I would guess that less than 20% of the workforce carried over 80% of the weight. This was my first experience working in a support organization, and at first I assumed it was due to unusually lacking management, but after meeting people in similar roles elsewhere I think it's par for the course.
Support seems to suffer from the Peter Principle[1] more than the other enterprise departments. The few competent people who were around me were almost always using the support role as a steppingstone to learn a new technology, with no long term plan to stick around, nor any desire for promotion within the organization.
Like many new hires, I starting identifying process issues that occupied a lot of time that should have been spent more efficiently. I even documented the issues and proposed changes to improve organizational efficiency to management, who said "good stuff, thanks" but then went on fighting fires instead of preventing them in the first place. These were very basic improvements easily understood by anyone with a technical mindset who spent a week or two observing our support process. A couple years later and I hear nearly identical ideas are finally being phased into the process. I take no credit, because the people with whom I shared the ideas have moved on.
This turned into a bit of a rant, but the gist of it is I see a huge opportunity for disruption of the customer support process for any company with regular case intake. For the sake of everyone who ever needs to obtain support, which is all of us, I hope your team succeeds!
[1] https://en.wikipedia.org/wiki/Peter_principle