ENZAXA customer emails a business at 9pm asking about pricing. An autoresponder fires back within seconds: "Thanks for reaching out! We'll get back to you within 24-48 hours." The customer, who just spent thirty seconds writing a specific question, now has an email that answers nothing and sets an expectation nobody is going to check on until Monday. This is what a lot of "automation" looks like in practice, and it's a large part of why automation has a bad reputation with customers who've been on the receiving end of it.
Treating acknowledgment as if it were a response
The most common mistake is confusing "we received your message" with actually helping. A generic acknowledgment email is fine as a backstop, but if it's the entire automation, you haven't automated the inquiry process. You've automated the appearance of responsiveness while the real work still waits for a human. Good inquiry automation reads the message, figures out what's actually being asked, and does something useful with that: routes it to the right person, answers a common question directly, or flags it as urgent so it doesn't sit in a queue.
Building for the average case and ignoring the edge cases
Most businesses design their automation around the inquiry they see most often, then get surprised when a customer sends something slightly unusual and the system handles it badly. A message that asks two unrelated questions in one email. A form submission in a different language. A customer who's clearly upset and needs a different tone than a routine pricing question. These aren't rare in the way people assume. Over any real volume, a meaningful share of inquiries won't match the tidy template the automation was built around, and what happens to those cases matters as much as what happens to the common ones.
The fix isn't trying to anticipate every possible edge case up front, which is impossible. It's building in a way for the system to recognize when it's uncertain and hand the message to a person instead of guessing confidently and getting it wrong.
No visible way to reach a human
Some businesses automate the front door so thoroughly that a customer with a genuinely unusual problem has no obvious way to skip the bot and talk to someone. This is where automation starts actively costing goodwill instead of saving time. The systems that work well almost always have an easy, visible escape hatch: reply "human" and get a person, or a phone number that isn't buried three menus deep.
Automating a process that was never actually defined
This one is subtle. A business decides to automate lead qualification, but the truth is nobody had ever written down what makes a lead "qualified" in the first place. It lived in someone's head, adjusted case by case based on gut feel. Trying to automate that means the system ends up encoding a rough guess at the rules, and it will get plenty of borderline cases wrong, not because the automation is bad but because the underlying process was never actually consistent to begin with.
Fixing this means going backward before going forward. Get the actual criteria written down, even roughly, before building anything. If two experienced people on the team would disagree about whether a given inquiry counts as qualified, that's a sign the rules need to be nailed down first.
Never checking what actually went out
The last mistake is the quietest one: automating a response system and then not looking at its output for weeks at a time. A tone that reads as robotic, a wrong detail confidently stated, a reply sent to the wrong person entirely. These things happen even in well-built systems, and they're easy to catch early and expensive to discover late, after a customer has already complained on a review site. Spot-checking a sample of what the automation actually sent, on a regular schedule, is unglamorous and one of the highest-value habits a business can keep.
Copying someone else's workflow without adapting it
Template workflows shared online or sold as ready-made products are a reasonable starting point, but a template built for a generic service business rarely matches the specific questions your customers actually ask or the specific way your team categorizes a lead as qualified. Using one unchanged usually means the automation is technically running while quietly misclassifying a meaningful share of real inquiries, because the rules baked into it were never actually yours. Adapting a template to your real categories and real edge cases takes extra time upfront, and it's the difference between an automation that fits and one that just looks like it does.
No one notices when the automation itself goes down
Systems fail. An API key expires, a third-party service has an outage, a workflow silently stops triggering after an unrelated change somewhere else in the stack. A business that has no alert for "this automation hasn't run in six hours when it normally runs constantly" can go days without noticing that every inquiry during that window went unanswered. This is arguably worse than never having automated at all, since the business now assumes something is being handled that isn't. A simple monitoring check, even something as basic as an alert if the workflow hasn't logged any activity in an unusually long window, closes this gap cheaply.
What good inquiry automation actually looks like
It reads the message and understands what's actually being asked. It knows what it doesn't know and routes those cases to a person instead of guessing. It leaves an obvious way to reach a human. It's built on rules the business had actually agreed on ahead of time, rather than rules invented mid-build. And someone checks its output regularly instead of assuming it's still working correctly six months later.