29 comments

[ 4.3 ms ] story [ 64.5 ms ] thread
> sometimes it requires doing great work manually before you should ever consider automating the task

I'd say this is the crux of it. You (or someone before you) should _always_ do something manually before automating it. If you see existing automation, make sure that it solves exactly the problem you have before you implement it. And the best way to see exactly the problem you have is... to do it manually.

Yup. It's natural human tendency to reduce mundane work. But it can be illuminating how much you can improve results by stepping in and getting your hands dirty first.
I worked for a company once that was trying to let people book something online that people often did by talking to salespeople in a shop. These companies were slowly dying as people started to do it more online.

Their initial strategy was to automate the crap out of everything. They would try to to keep margins low and part of that was to try to avoid having people talk to non-scaleable customer sales agents.

They did pretty poorly in the beginning until they decided to do a 180 and allow people to have full control in the sales funnel over when they would like to use the website and when to talk to a person (including not using the website the whole way if they so chose).

When they did this sales and profits took off like a rocket.

They then hired enough customer service agents to service demand this way (which was a lot).

I thought it was interesting that they kind of stumbled from 100% automation to a kind of hybrid model that hit an amazing sweet spot.

They did try to reduce certain types of call volume by A/B testing website copy and the like but they always made it super easy to pick up a phone and give a code and instantly talk to someone who could see all their details and never tried to discourage anybody even if doing it online was trivial.

(comment deleted)
I expect they also made it super easy to _not_ have to talk to customer support as well.

Millenial/GenZ jokes aside, having to talk to someone can be a massive deterrent. I might be waiting at a doctor's office, on a train, etc. I can't tell you how many trials I've bailed on once I hit a mandatory "Talk to a salesperson" step.

The fact that pretty much the whole company was tech savvy and preferred to avoid talking to people when booking stuff online is what made this 180 doubly impressive, IMHO.

The customers tended to be older, I think.

Awesome story. Gives me a lot of confidence in the value that Mantis provides.

There will always be people who don't need or want to speak to a human, but having the outlet to do so when it's useful to the customer can make a huge difference.

As much as I like the idea, those hourly rates seem way too low.
Presumably you're getting someone in a call center in Bangladesh who's lucky to get $100 a month for 60 hour weeks.
From their website's FAQ :

Who Are The Assistants? Where Are They Located?

Magic is fully remote with an operational headquarters in Manila. We hire smart generalists who are resourceful, fast on the computer, 100% fluent in English, and have graduated from top universities in the Philippines.

Our assistants are looking to work remotely for startups or small to midsize businesses. We do not operate a “call center”—we have a screening process for the companies we work with, and we pay our assistants significantly above the market rate.

Magic Dedicated Assistants are paid well above the Philippines’ minimum wage of $9 per day (source).

> those hourly rates seem way too low

Perhaps they use investor money to make up for the difference (a kind of growth hacking). Perhaps their idea is to replace workers by AI at some point.

This is interesting. You are the second person on this thread to think that Mantis outsources calls to someone else (it does not).

What on the website makes you think that? Important for me to know so I can clarify it to visitors.

This article couldn't come at a better time for me. I have a list of websites/businesses in my area that could profit from a redesign, which I happen to offer with my website builder. I'm now contemplating if I should automate this and go shotgun-method in the hopes some prospects turn into customers, or I could put in more time but also quality to convince only a small percentage of the list to become customers.

Stuff for thought. Thanks for the article.

I would lean towards quality. In my sales efforts, shotgun approach rarely works and anecdotally is working less over time.

Until you have case studies and social proof, shotgun will never work imo. Referrals are more important than ever.

Thanks, that's also my experience. Besides, it will never hurt to try something new.
Glad to hear!

A lot of my outbounding efforts with Mantis have fallen flat when I sent something that was more or less templated, but have had better results with something far more personalized.

Here's a fantastic article that might be worth a read: https://cloutly.com/blog/cold-email-template/.

Thanks for another article! Reading now. Your inbrowser chat app Mantis looks good too. And your text on the homepage got me scrolling to the end. Good luck!
Good article! Two things popped into my head when reading it. First the talk "Programming with Hand Tools" by Tim Edwald[0]. It's a very cool, entertaining talk with emphasis on the craftsmanship side of things and provokes thinking about which parts to automate (or maybe abstract away) and which parts to craft by hand when we're building stuff. Aside: also reminds me of Casey Muratori's Handmade Hero project [1]. He is a strong advocate for structuring things bottom up and building them ourselves.

[0] https://www.youtube.com/watch?v=ShEez0JkOFw

[1] https://handmadehero.org

---

Secondly when reading this:

> Regardless, the basic idea is that companies are often faced with the decision of doing N units of shitty work or far fewer than N units of great work.

This is obviously oversimplified, but there is an important point that wants to emerge from this line of thought.

As someone who grew up on open source, standardized technologies and the Web, I have been empowered to build a livelihood on Web development, mostly "self-taught" (or rather self-directed). All of this Web stuff is very accessible and gives you actual _leverage_. You can build something useful very quickly and the community around it is happy to share so much knowledge and work. I'm _very_ thankful for that.

But I think as the wider web development community we're losing sight of what that essence is. We started to think of the Web as merely a vehicle for pure scale as in "how to reach the most people and annoy them with notifications" and "how to produce cheap software very fast".

Maybe we, or some of us, should slow the fuck down a notch and think about producing valuable things for the specific needs, pain points or taste of actual people. What the article describes is a process of thinking about the real people and building a human connection. The "top 100" costumers in the article are most likely people who _actually_ need/want/use the damn thing if they see your point. Instead of trying to manipulate the masses to buy a lot of crap (excuse my meta), we should be building relationships. One very good reason for this is that only the latter is sustainable - on all the axis of what "sustainable" means.

I'm writing this "out loud" partly because I started to drift into this abstraction/automation mindset myself more and more. But yes, leverage is solving real problems.

Mantis is 30/mo?

OP can you tell us more about pricing model? 30 seems quite low, especially given that it is audio.

That only buys like 10 hours of time in the Philippines, for example.

How does pricing scale and what is included?

I assume you have to take the calls yourself, Mantis is only the software.
Yes, exactly right.

I'm curious what would indicate otherwise...

People often mix automation and abstraction. In some cases it is interchangeable. In lot of scenarios it is not. In my opinion there is true automation, for example automatic bank account creation, automated sales etc and then there is abstraction where you thinking you are automating but in reality you are adding n+1 tools. For instance, automated chatbot is an abstraction of a customer rep, if 90% of inbound ends up with an customer rep.
I like the idea of "abtracting" a human with automated processes. I think you're right that a semi-automated chatbot is exactly that. The thing to be super careful about in such cases is whether the automated component is purely beneficial, and be rigorous with data to ensure it is.
I take some issue with the comparison as an either-or.

Automation in its correct place shouldn't replace human effort - it should augment that effort.

In this case, it seems one step removed to just do both of these approaches, starting with the first. During the process of finding those 100 high-confidence matches, you could identify the ones that have the most general cases, and reuse the email copy from those.

I think the idea that automation is intended to replace human effort wholesale is improper. We should rely on automation to handle where computers are better than humans, to give the human more time to do things humans are better at.

Thanks for this comment. I think there's an important distinction that's worth clarifying.

Automation is great in most circumstances, and truly does free humans to do more meaningful work. But my take is that you can quickly push up against cases where it's unclear that you've improved a situation. It's easy to make the judgement that you have when you reduce time spent on doing "mundane" work.

Perhaps there is a heuristic that can be developed to let someone quickly assess the usefulness of automating a certain task. Would be happy to discuss this more.

Seems like the author is comparing apples and oranges. There is speed and quality, your automation can process a task faster than an human, but lack quality. Automation can be also slower than an human but create more quality work. If the automation is slower and produces less quality, so of course you don't want that