We built an automation system...but nobady cared

Everyone here is right that outcome beats feature list, but I'd push on something before you rewrite the copy again. A Make + Notion + Payhip stack is catnip to people who could just build it themselves, so sharper outcome wording mostly pulls in more of that crowd, and they poke at it and leave. The ones who'd really pay are creators who would never touch Make in their life.

When I had a similar 'works but nobody bites' tool, the thing that changed it was showing it to a non-technical friend who runs a small coaching thing. She didn't care how it was wired, she cared that a lead got an invoice without her opening her laptop. That reaction told me I'd been demoing to the wrong room the whole time.

So before another messaging pass, I'd go find five people who can't assemble this themselves and watch them react. If they light up, you've got a packaging job and you're close. If they shrug too, the stack is solving something they don't really feel, and no amount of rewording saves that.

This title hit me hard.

I'm currently in early customer discovery for a tool
targeting freelancers who work with international clients.

The biggest thing I'm trying to avoid is building
something nobody asked for.

What was the earliest signal you missed that told you
the problem wasn't real enough?

I’d make the first demo brutally specific: “here is the messy manual sale flow today, here is the same sale after Hermes.” If the buyer can see one annoying job disappear, the stack matters less. Also worth picking one creator niche first, because “solo creators” can still be broad when you get to actual copy and pricing.

I had a version of this with my own launch — PivtTravel's pitch was originally "multimodal routing + delay-based connection scoring," which is accurate but reads like a feature list. The moment it landed better was switching to "tells you if your train connection is actually safe before you find out the hard way." Same product, but one version describes the engine, the other describes the moment someone's stressed at a junction wondering if they'll make it.
One thing I'd add to what's already been said here: even after you nail the outcome-framing, it's worth testing whether the outcome you've landed on is the highest-frequency pain, not just the most technically interesting one to solve. I built around connection-safety first because it was the most novel thing technically, but I'm now realizing something more common (like waitlist-confirmation anxiety, in my case) might've been the stickier hook all along. Worth checking if "sales automation for solo creators" is the most-felt pain your audience has, or just the cleanest one to frame.

This is painfully relatable. Sometimes the thing you build is technically useful, but the market only cares once you describe the exact painful moment it fixes.

I’m finding that broad labels like “automation” or “AI workflow” can sound abstract, while “here is the moment where your workflow breaks” gets much better reactions.

Did you eventually find one specific use case where people immediately understood it?

I'd separate the system into two stories: the workflow it replaces and the decision it improves. "Telegram + Make + Notion + Payhip" is infrastructure; "a creator can capture a lead, take payment, deliver the asset, and know what happened without checking five tabs" is the outcome. The first sales demo should probably start with the current manual mess, not the automation diagram.

"Building infrastructure is easy, but without a clear user-facing outcome it's invisible" — this hit home. I'm in the same spot with my own product: it works, but the hard part was never the building, it's getting people to see why it's for them.
To answer your question: my biggest struggle right now is distribution, not the product. What's shifted things a little for me is writing about the problem I solve rather than the thing I built — when I describe the pain, the right people show up; when I describe features, nobody does. Sounds like you've landed on the same lesson the hard way. Good luck with the rebuild.

Yep. People almost never buy the mechanism first. They buy the moment when something annoying finally stops being annoying. I ran into the same thing with DictaFlow. Saying "AI dictation app" got polite nods, but saying it fixes typing friction in the apps where normal dictation falls apart got a much clearer reaction. Outcomes first, mechanics second. Otherwise, you're asking people to admire the plumbing.

That realization is bigger than the automation stack itself. Features explain how something works. Outcomes explain why anyone should care. The interesting part is that your product didn't really change—you just found the problem it was actually solving. That's often the difference between something people admire and something they buy.

We're currently shifting from"automation tool thinking"→"business system thinking."
Curious if others here have gone through the same shift.