I want to build an AI support agent for Shopify stores — am I solving a real problem?
Before writing a single line of code I want to talk to real store owners first.
The idea: an AI that handles repetitive support tickets (order tracking, returns, FAQs) for Shopify stores at a flat monthly fee.
If you run a Shopify store, I have 3 quick questions:
What does support cost you monthly?
What's the most painful part?
Would you ever trust AI to handle it?
Happy to DM if you'd rather keep it private.
Trending on Indie Hackers
not a shopify owner but i built an AI agent in a different vertical (job applications), and the thing that killed my first version was misreading "repetitive support tickets" as a single category. once i actually shadowed real ops, it split into three very different buckets:
the question i'd push on: what percentage of tickets are actually bucket 1? my guess is stores overestimate because they feel busy, but the bucket 1 ratio determines whether your flat-fee math works or not. the fewer bucket 1 tickets, the more your AI ends up just being a fancy knowledge base and the willingness to pay collapses.
also if you're pre-code, the shopify app store already has a dozen AI support tools. worth reading the 2-star reviews on the top 3 to see where they actually break. that's where the real wedge is.
The three bucket breakdown is incredibly useful — especially the emotional ticket category where AI tanks hard. That's exactly what needs human escalation. And the 2-star review tip is brilliant. What percentage of tickets do you think actually fall into bucket 1 for a typical store?
You don’t prove it with claims — you prove it with a small, controlled win.
Something like:
→ take last 20–30 return/chargeback cases
→ run your logic on them
→ show: what you’d approve/reject vs what actually happened
→ and quantify the difference ($ saved / time reduced)
Even a rough “this would’ve saved you $X last month” is enough to get attention.
Early on, it’s less about being perfect and more about making the outcome visible.
If they can see the delta, they’ll want to test it.
Also — if you lean into “saves money weekly” as the core promise, your positioning (and even name) should reflect that outcome, not support.
So the demo isn't a product demo — it's a retrospective audit. "Here's what your last month of returns would have looked like with this." That's a much more convincing proof than any feature list. Did you find stores were willing to share that historical data early on?
Usually yes — if the ask is small and clearly tied to value.
You’re not asking for full access, just:
→ a small sample (20–30 cases)
→ in exchange for a clear “you lost $X here” insight
That feels more like help than risk.
If you position it as:
“quick audit to find missed revenue / bad approvals”
most will say yes — especially if returns are already painful.
Once they see the loss, the sale becomes much easier.
Quick audit to find missed revenue" — that's a completely different conversation than asking for data access. It's offering value first. So the first interaction with a store isn't a sales call, it's a free audit. That's a much easier yes to get. How many cases do you think is enough to make the insight convincing — 20, 30, more?
20–30 is probably enough to show direction — but not enough to make it undeniable.
If you really want it to hit, I’d push closer to:
→ 50–100 cases
→ across at least a couple weeks
Otherwise it’s easy for them to say “this was just a lucky sample.”
Also — one thing I’m thinking:
If the audit shows something like
“you lost $2.3k last month from bad approvals”
that’s not just a nice insight — that’s basically the whole pitch.
At that point it’s less:
“do you want this tool?”
and more:
“do you want to keep losing this every month?”
That changes the dynamic completely.
Curious — when you ran this, did stores actually convert right after seeing the loss, or did they still hesitate?
Why this works:
This is a real problem—especially for stores with growing support volume.
The challenge isn’t answering FAQs, it’s maintaining accuracy when queries involve real order data, returns, or edge cases. That’s where most AI agents break.
We’ve seen much better reliability when the system is grounded with store data (orders, policies, FAQs) using a retrieval layer instead of pure prompting.
Also worth thinking early: how you’ll handle exceptions—refund disputes, damaged items, etc. That’s usually where trust drops.
Curious—are you planning deep Shopify integration from day one or starting with a simpler FAQ assistant?
Starting simple — FAQ and order tracking first to prove reliability before touching anything with money attached. Deep Shopify integration comes once trust is established. Does starting simple hurt credibility with store owners or does it actually help?
Starting simple actually helps—not hurts.
Most store owners won’t trust AI with refunds or sensitive actions anyway, so proving reliability on FAQs + order tracking is the right move.
What matters more is how you position it:
instead of “AI handles everything,” frame it as
“AI handles repetitive queries, humans handle edge cases.”
One thing I’d plan early though: even in “simple” use cases, accuracy depends on access to real store data (orders, policies). That’s where most systems either feel reliable or break.
If you get that part right, expanding into deeper workflows becomes much easier later.
AI handles repetitive queries, humans handle edge cases" — that's the framing that removes the fear. And noted on the data access point — getting connected to real store orders and policies early seems like the thing that separates reliable from unreliable. Is that usually an API integration or do stores just export their data manually at first?
Usually API integration—especially for orders and customer data, since it needs to be real-time. Shopify makes that fairly straightforward.
Some teams start with manual exports for FAQs/policies, but for anything dynamic (order status, returns), APIs are pretty much required for reliability.
A common approach is: start simple with a small set of endpoints (orders, tracking), then expand as trust builds.
For FAQ/order tracking retrieval, the embedding model matters far less than the quality of your input text. Tested 5 models at my company, got only a 7-point spread in accuracy. Switched from embedding raw JSON to LLM-generated summaries and gained 40 points. Spend the savings on data prep, not premium embeddings.
Same phase you are — day 3 of talking to potential users before writing code. The discipline to validate before building is the right instinct, most founders skip it.
Two things that might help based on what I've learned talking to founders this week:
Shopify store owners aren't heavy on IH but they're all over r/shopify and the Shopify Community forums. Might get more responses there than here.
When I asked "what would you pay?" as a direct question, people gave vague answers. When I gave them price anchors ($0 / $19 / $49 / $99) they gave me real ones. Worth trying if you're not getting specific pricing signal.
Rooting for your validation. Drop a follow-up post with what you hear back — curious if Shopify owners answer differently than the SaaS founders I'm talking to.
The price anchor idea is really smart — open questions get vague answers but giving them options gets real ones. And noted on r/shopify, I've been trying but my karma is too low right now. Working on it. Did the price anchors change what tier most people landed on?
Fair warning — my sample is still small (like 4-5 real conversations this week). So the honest answer is "not enough data yet to say definitively."
What I've noticed anecdotally: when I give $0/$19/$49/$99 as anchors, people mostly land on $19 or $49. Nobody has picked $99, which tells me either I haven't described the product as load-bearing enough yet, or $99 really is a ceiling for this audience. Both possible.
On r/shopify karma — classic chicken-and-egg. One workaround: comment thoughtfully on 5-10 other Shopify founder posts over a week before posting your own. Usually enough to unlock.
That's really useful — $19 or $49 landing zone is a clear signal. And noted on the Reddit approach, I'll do it properly this time. Did you find the $99 ceiling was audience-specific or more about how the product was framed?
You are spot on. ~
It’s not that store owners are opposed to AI-it’s that they don't want it to mess up the things that are important to them.
Things like, "Where is my order?" and company policies-those are simple. They really don't care if an AI does that.
However, with refunds, gray area scenarios, and mad customers, that is when people get uncomfortable. They will actually lose more money on one mistake here than they
would save with automated help.
Therefore, the question isn't if the AI will "do support" but rather if it will "handle all the tedious tasks and get only the important issues to you."
Your distinction:
auto-process volume
clearly pass the sensitive issues back
This is exactly right. If they are able to easily and naturally transfer things over, then they are very open.
Also, the phrasing matters a lot.
"Will you let an AI do your support?" versus "Which tickets do you have to respond to at least once every day?" or "Which tickets would you never automate?"
Another point: You aren't just competing with other AIs. You are competing with "This is painful, but it works." Stores are likely already using macros and other automated help and finding that it is "good enough" for some interactions.
Thus, the standard is not "this is cool" but "this is noticeably better and introduces no new issues."
The larger concern, in my experience, is not an incorrect answer but the loss of control over how the store represents itself.
The store owner is more worried about losing their brand's voice, tone and ability to be a human to the customer when necessary.
The thing that makes a store owner finally agree to it, is if they can still feel in charge while the AI takes care of the bulk of the heavy lifting.
Feel in charge while the AI does the heavy lifting" — that's probably the framing that actually sells it. Not "AI does your support" but "you stay in control, AI handles the volume." Did you find store owners responded differently when you framed it that way?
Niceeee
Nice
I run agents daily for PM work - framing matters more than trust. The real question is what the agent does when it hits something outside its playbook. Escalate or just guess? That distinction IS the product.
Escalate or just guess" — that's the exact distinction that matters. A bot that guesses on a $200 return and gets it wrong costs more than the ticket was worth. So the product is really about knowing its own limits. How would you build that escalation trigger — confidence threshold, ticket type, or something else?
There is a lot of apps like that on Shopify either make it easy to integrate or add good diffentitor
yes, but it’s already a crowded space—so the opportunity depends entirely on how you differentiate.
I made something for this already and realised market is flooded. ShopAsk/ PromptMysite, its just the AI can onlu be as good as the content you have
The instinct to talk to store owners before writing a line of code is the right call. The questions you laid out are good, but I would add one: ask them how they currently handle it. Not "do you want AI support" but "walk me through the last time a customer asked about a delayed order." That answer usually reveals whether the pain is in the volume of tickets or the context-switching cost of managing them, which changes what you actually need to build.
The trust question you raised is the real one. Most small Shopify operators are the sole face of their brand, so AI handling a response feels different to them than it would to a mid-sized team. Worth probing whether they want it fully autonomous or as a draft-and-review tool first.
Walk me through the last time a customer asked about a delayed order" — that's a much better question than anything I had planned. It gets to the real workflow instead of a hypothetical. Adding that to my interview script immediately. Did you find people were more honest when you asked it that way?
Talking to users before building is the right call, but watch out for a trap: store owners will tell you "yes this is painful" and then not pay for it. The real test isn't whether the problem exists — it is whether they're already cobbling together some workaround (spreadsheets, VA, a Zapier nightmare) and paying for that. If they are, that's your signal.
One angle worth exploring in your interviews: what happens when the AI gets it wrong? Returns and order disputes have real money attached. The fear isn't "will it work 80% of the time" — it's "what is the cost of the 20% when it doesn't." That's the moat question more than the feature question.
That's the clearest signal filter I've heard — if they're already paying for a VA or Zapier workaround, the pain is real enough. What would you ask in an interview to surface that quickly?
The "would you trust AI to handle it" question is actually the crux. From what I've seen in adjacent markets: trust isn't given upfront, it's earned through a deliberately narrow starting scope. Start with order tracking only — pure lookup, zero judgment needed. Let the AI deflect the top 30% of tickets there, prove it works, then expand to returns/FAQs.
The stores that try to automate everything on day one tend to get a bad review from a customer whose sensitive return got mishandled by a bot — and suddenly the whole experiment is over.
On cost: $8–12k/month for 2 agents + tools is the number I hear for mid-size stores. If you can reliably own even 40% of that ticket volume at $200–400/mo flat, the math works clearly. The challenge is proving the reliability before they'll give you real ticket volume.
Pre-code customer research is exactly the right first move here. Good luck.
Starting narrow to earn trust first makes sense — prove it works on low-risk tickets before touching anything with money attached. How would you suggest proving reliability to a store owner before they give you real ticket volume?
$8k–$12k/month for 2 agents + tools.
Repetitive tickets (order tracking, returns, FAQs) eating most of our time and slowing response during peak.
Yes for simple queries, but not for complex or sensitive issues.
This is exactly the kind of data I was hoping to find. Are you currently using any tool to handle those repetitive tickets or is it still manual?
Different path but might be useful: I did the opposite and shipped a $49 product this weekend without talking to a single customer first. 6 weeks from zero coding knowledge, built it in scar tissue from my own agents breaking, launched today.
Here's what I'd tell you looking back at my own process — talking to users is the smart move, but there's a failure mode where the interviews never end and the product never ships. You get 10 "yes I'd pay" responses and still don't know anything, because people answer hypotheticals differently than they pay.
One thing that would have helped me: ship the free version first. I have 3 patterns free on GitHub, 9 more behind $49. The free ones are the validation — if nobody stars the repo or files issues, the paid pack doesn't matter. Could you do that with support tickets? Free tier that handles one category (order tracking only), paid for the rest? Validates whether they trust AI with the easy stuff before you build the hard stuff.
Also — the commenter on Gorgias/Tidio is right. The wedge matters more than the feature set. What's the one thing those two can't do that Shopify owners actually complain about?
The free tier as validation idea is interesting — let them trust the AI with easy tickets first before asking them to pay for the hard ones. Removes the risk objection completely. How long did it take before you saw real usage signal on your free version?
the problem is 100% real but the commenter who mentioned Gorgias/Tidio is right — the crowded space means your wedge has to be razor sharp. I'd skip the "we do everything" pitch and pick one painful flow that existing tools handle badly. returns processing maybe? that's where store owners lose the most time and money, and the existing tools basically just route it to a human anyway.
also +1 on the advice to do 10 stores manually first. you'll discover edge cases no amount of brainstorming would surface — like how different stores have wildly different return policies that the AI needs to handle contextually, not with generic templates.
The edge cases point is what scares me most about building this — every store has a different return policy and the AI needs to handle that contextually not generically. Did you hit that problem when you were doing stores manually? How different were the policies store to store?
Good idea, but you would need to add a strong USP. Building an AI assistant bot isn’t a big challenge for a mid-sized business.
That said, never back down from your idea. I built a Substack Notes scheduler, even though they launched something similar quietly, I’m still adamant about my idea.
The scheduler is Pubq.io
You're right — USP is the real challenge. Everyone says "AI support" but that's not a reason to switch. Still figuring out what the one thing is that makes this unmissable. What would a strong USP look like to you in this space?
Good instinct starting with conversations first.
The real question isn’t “would you trust AI”, it’s whether it can solve tickets without creating bigger problems.
That's the real bar isn't it — not "do you trust AI" but "does it actually solve the ticket without making things worse." What do you think is the highest risk failure mode — wrong answer, slow response, or something else?
My gratitude goes out to the entire team of Revox Credit repair. Someone left information REVOXCREDITREPAIR at GMAIL dotCOM under a comment section on helping to repair credit. I was interested in knowing more and if the hacking team still does this. I had poor credit, an old bankruptcy and problems with getting approved for an apartment due to 2 broken leases from the past which I explained to Revox Credit Repair when I made contact with them. They cleaned my credit records and they boosted my credit score within just few days of contacting them.
Definitely a real problem — Shopify store owners spend a ton of time on repetitive support queries. The ROI case is easy to make if you can show hours saved per week. What's your target price point — per-ticket or monthly flat?
Flat monthly fee. The per-ticket model is exactly what makes Gorgias painful for stores doing high volume.
Interesting project. Shopify store owners are often skeptical about handing over customer conversations to AI. Have anyone thought about how the brand or identity of the agent affects that initial trust? A lot of founders underestimate how much the naming plays into perceived reliability
The naming point is interesting — I hadn't thought about how much the agent's identity affects trust. Do you think store owners would prefer it to feel like a bot they control, or something that feels more like a human assistant?
@mahiraaaa both actually. Enterprise clients don't want something that feels like a clunky bot but they also get suspicious if it tries too hard to sound human and then makes mistakes. What they really want is reliability and control. The sweet spot seems to be an agent that feels professional and trustworthy like a competent assistant they can rely on, not a replacement for a human.
That's why I think the identity layer (naming or branding) matters more than most founders realize in Shopify or any other AI tools.
Reliability and control" over human-sounding — that's a clear brief for how to position it. So the branding should feel like a competent assistant they manage, not a replacement they hand off to. Does the name matter more than the interface in creating that feeling?
Makes sense to talk to users first before building.
Also agree with the point about strong competition comment below. Even if the problem is real, getting people to trust and try something new can still be a challenge, especially with store owners and so many well-known tools already out there.
That's exactly the plan — talking to store owners before writing a single line of code. Already getting pushed in directions I hadn't considered just from this thread. How did you approach the trust problem when you were early stage
You really have a great idea 🫡
The problem is real but the competition is brutal. Gorgias, Tidio, Zendesk all do this already. The question isnt whether store owners need it, it's why theyd pick you over something they already know. Flat monthly fee is smart though, Shopify owners hate perr ticket pricing. If I were you Id find 10 stores manually and do the support yourself before building anything, that's how you learn what the AI actually needs to get right.
The manual first approach makes a lot of sense — learn the job before automating it. Did you do something similar when validating your own products? And how would you suggest finding those 10 stores willing to let someone unknown handle their support?
You’re solving a real problem — but it’s also one of the most crowded directions right now.
The risk isn’t “does this exist” — it’s “why would anyone pick yours over the 20 others doing the same thing?”
Most tools in this space sound identical:
AI support, automation, faster replies, etc.
So the real question early isn’t just validation — it’s:
can this actually stand out as something memorable, or will it blend in?
Seen a lot of solid products die here, not because they didn’t work — but because they felt interchangeable.
If you get a few store owners interested, pay attention to how they describe it back to you — that’s usually where differentiation (and brand) starts.
That's exactly the kind of honest pushback I needed. You're right — "AI support automation" is everywhere. I'm still in discovery mode so I haven't locked in positioning yet. What do you think makes something in this space actually memorable vs just another tool?
Usually not features — constraints.
The ones that stick in this space feel like:
→ “this is ONLY for X”
→ “it ONLY does Y”
→ “and it does it better than anything else”
Example:
“handles returns for Shopify stores” is more memorable than “AI support agent”
Because now it’s clear:
– who it’s for
– when to use it
– and what to expect
Broad = comparable
Narrow = ownable
Most people start broad and try to stand out later — but it’s usually the opposite that works.
Broad = comparable, narrow = ownable" — that's the clearest way I've heard it put. So instead of AI support agent, something like "handles returns only, better than anyone else" would be more ownable. Does the niche need to be a ticket type like returns, or could it be a store type like fashion or electronics?
Both can work — but early on, ticket-type usually wins.
“handles returns for Shopify” is tied to a clear, recurring pain.
It’s easy to test, easy to measure, and easy for users to say “this solved X for me.”
Store-type (fashion, electronics) is broader — you still end up needing to define what inside that you’re solving.
You can layer store-type later once you see patterns.
Start with:
→ one painful workflow
→ that happens often
→ where speed/accuracy matters
Own that → then expand.
Otherwise you risk sounding niche, but still being vague.
That makes sense — start with one workflow, own it completely, then expand. My gut says order tracking is the most repetitive and high volume ticket for most Shopify stores. Does that feel like a strong starting point or is there a more painful one you'd go after first?
I wouldn’t start with order tracking at all.
It’s high volume, but it’s already “good enough” everywhere — so there’s no real reason to switch.
Early products don’t win on frequency, they win on pain + consequence.
If nothing breaks when your product is bad, nobody cares enough to change tools.
I’d go straight to something like returns/refunds/chargebacks — where:
→ money is involved
→ customers get frustrated
→ and mistakes actually cost the business
That’s where “I need this now” comes from.
Otherwise you risk building something useful… that nobody feels urgency to adopt.
Returns/refunds makes sense — the consequences of getting it wrong are real. Order tracking feels safe but you're right, there's no urgency. So if I focused purely on returns and chargebacks, what would "doing it better than anyone else" actually look like in practice?
“Better” here usually isn’t more automation — it’s removing the parts that cost money or trust.
For returns/chargebacks, that tends to look like:
→ fewer bad approvals (protect margin)
→ faster resolution (reduce frustration / support load)
→ and clear, consistent decisions (no back-and-forth)
Most tools handle the workflow.
Very few actually optimize the outcome:
– deciding when to approve vs push back
– catching edge cases (policy abuse, repeat claims, etc.)
– and making it feel fair to the customer while still protecting the store
If you can do that reliably, it stops being “support automation” and starts being:
→ “this saves me money every week”
That’s usually the threshold where people switch.
So instead of asking “can this handle returns”
I’d frame it as:
“does this reduce loss + support overhead in a way I can see quickly?”
That’s the version that becomes hard to ignore.
Saves me money every week" vs "does my support" — that's a completely different product conversation. So the pitch isn't features, it's a measurable outcome. How would you suggest I actually prove that outcome to a skeptical store owner before they commit to paying?