I went from 40 support tickets/month to 8 — by stopping the question before it was asked
I run a small ecommerce store using Printful (print-on-demand).
Every day the same emails: "Where is my order?" "Has it shipped?" "When will it arrive?"
I was spending 3+ hours/month copy-pasting tracking links and answering the same question.
So I built a different system.
Instead of responding after customers ask, I connected my backend to Printful's webhooks. Every fulfillment event (printing started, shipped, delivered) automatically triggers a proactive email with the order status and a tracking page — no login required, token-based access, similar to how DHL works.
The result:
→ Support tickets: 40/month → 8 (-80%)
→ "Where is my order?" emails: 32 → 0 (-100%)
→ Time handling support: 3h/month → 35min
Customers never ask because they already know.
I'm now validating whether other ecommerce founders have the same pain before building this as a proper SaaS tool.
Two questions for this community:
- Does this problem sound familiar to you?
- Would a plug-and-play version of this system be useful for your store?
Landing if you're curious:
👉 https://app.lujandev.com/inbox-zero?utm_source=indiehackers&utm_campaign=launch_feb2026&utm_medium=forum
The proactive approach is brilliant. I've seen this same pattern with user confusion in my apps too. When people don't know what's happening, they reach out for help, even when everything is actually working fine.
Building PadelTracker (watch app for tracking padel matches), I noticed players would often restart the app mid-match thinking it froze, when it was actually just waiting for them to tap the next point. Added a subtle pulsing animation and a 'tap to score' hint. Support questions about 'app not working' dropped to almost zero.
The token-based access without login is the real insight here. Friction creates support tickets. Remove the friction, remove the ticket. Your 'stopping the question before it's asked' framework applies way beyond e-commerce.
The numbers are impressive. If you turn this into a SaaS, do you see it more as a Shopify/Printful-style integration product, or something more generic for any ecommerce stack?
This is basically the same pattern I've seen kill support load on every project I've worked on. The "where is my order" email is the canary in the coal mine — it tells you your system isn't communicating state changes fast enough.
I ran into something similar building internal tools. We had a dashboard that showed deployment status, but devs would still ping Slack asking "is it deployed yet?" Turns out they weren't checking the dashboard because it required a context switch. The fix was dead simple — push notifications to the channel they were already in. Ticket volume dropped to almost nothing overnight.
The token-based access bit is the real insight here though. I've seen so many order tracking implementations that require login, and customers just... don't. They email support instead because it's less friction than remembering a password. Removing that barrier is half the battle.
To answer your validation question — yeah, this pain is everywhere in ecommerce. A friend runs a Shopify store doing ~200 orders/month and easily 30% of his support is WISMO (where is my order). He'd pay for this in a heartbeat. The tricky part will be making the integration plug-and-play enough that non-technical store owners can set it up without touching webhooks directly.
The token-based detail is the whole insight.
Most tracking systems technically exist — Printful sends a number, customer goes to USPS and searches. That’s 4 steps and a context switch. So they email instead.
One click → tracking page → answer. No account, no password. The information finds them.
And here’s what surprised me: most of those 40 tickets weren’t real problems. The order was fine. Customers just didn’t know — so they asked. Remove the uncertainty and the ticket never exists.
Would your Shopify friend be open to a quick chat? 200 orders/month with 30% WISMO is exactly who I’m building this for.
Love this approach. Proactive > reactive is such an underrated principle.
We're seeing the exact same pattern but in internal operations — team members constantly asking "what's the process for this?" or "where do I find the SOP?" Instead of building better documentation, we realized the answer needs to show up where the work is actually happening, not in a separate wiki nobody checks.
Your webhook-based approach is a great example of solving the information gap at the right moment. The "anticipatory design" framing in the comments nails it. How long did it take you to set up the initial webhook integration with Printful?
The internal ops parallel is spot on — information asymmetry creates overhead everywhere, not just in ecommerce.
To answer your question: the initial Printful webhook setup took me about 3-4 hours as a developer. That’s the exact problem I need to solve for the SaaS version — making it a 5-minute setup for non-technical founders.
How are you currently handling the “where’s the SOP?” problem in your team?
This is one of the sharpest examples of anticipatory design I've seen.
The 80% drop isn't just about automation — it's about eliminating the friction that creates the question in the first place. Most founders treat support as reactive cleanup. You identified it as a design gap.
The part that makes this especially effective is the behavioral layer underneath: when customers don't know what's happening, they default to asking. That creates cognitive load on both sides. By flipping it proactive, you removed the uncertainty that triggers the support request.
The "no login required, token-based access" detail is critical. A lot of tracking systems technically exist but require customers to create accounts or dig through dashboards. That friction gap is where most implementations fail. You removed it.
One thing I'd add — this pattern applies beyond ecommerce. Anywhere there's a status-dependent workflow (onboarding, approvals, processing), the same dynamic exists. People ask because they don't know. If you tell them before they ask, the question never surfaces.
The validation question is smart. This problem is universal across fulfillment-based businesses. The specific pain varies (shipping notifications, processing updates, approval status), but the root cause is identical: information asymmetry creates support overhead.
Your framing of "stopping the question before it's asked" is spot on. That's not just support optimization — it's friction elimination at the source.
“Information asymmetry creating support overhead” — that’s the sharpest way I’ve heard the root cause described. Stealing that.
Started with ecommerce because that’s where I had the pain and the data. But you’re right — the pattern is identical anywhere there’s a status-dependent workflow. Someone always defaults to asking when they don’t know.
The anticipatory design framing changes how I think about the positioning entirely. Thank you for that.