Source Reddit post: https://www.reddit.com/r/smallbusiness/comments/1uovkpg/has_anyone_found_a_good_solution_for_tracking/
opportunity / idea_filter. The fresh Reddit post is useful smoke, not proof: a small-business operator asks how to track returns that are in transit after a customer has shipped back the item but before the warehouse has scanned in receipt, and specifically says “aside from just connecting DHL or FedEx to Shopify.” External evidence supports a real operational gap, but the wedge is narrow: not generic returns software, not parcel claim recovery, not return-fraud tooling, and not broad payout/accounting reconciliation. The opportunity is a pre-receipt exception queue that sits between Shopify/returns apps, carrier tracking, warehouse/3PL receipt, and refund/customer comms.
Build a return-in-transit exception desk for Shopify and SMB warehouse operators that shows every authorized return before warehouse receipt, ages the risky ones, suggests refund/status actions, and hands off lost/stalled returns to support, warehouse intake, or carrier-claim workflows.
Best-fit ICP: Shopify, BigCommerce, WooCommerce, and marketplace-adjacent ecommerce merchants doing roughly 100-5,000 returns per month, especially apparel, footwear, accessories, beauty, home goods, consumer electronics, parts, collectibles, and any category where refund timing, condition inspection, and inventory restock timing matter.
Likely buyer: founder/operator, ecommerce operations manager, CX/support lead, warehouse manager, or controller at a merchant with in-house warehouse operations or a small 3PL relationship. Daily users are support reps answering “where is my refund?”, warehouse receivers prioritizing incoming RMAs, and ops/finance owners deciding whether a return can be refunded, held, escalated, written off, or turned into a carrier claim.
Best early adopter profile:
Bad-fit ICP: very low-return merchants, merchants with fully outsourced enterprise returns platforms and mature WMS integration, merchants that deliberately instant-refund everything at first carrier scan, and sellers whose main problem is Amazon SAFE-T/FBA reimbursement rather than merchant-controlled return receipt.
The source post asks: “Has anyone found a good solution for tracking returns that are in transit but haven't hit the warehouse yet?” The OP says there is a blind spot between when a customer ships something back and when it actually gets scanned in, then asks what people use beyond connecting DHL or FedEx to Shopify. This is not demand proof by itself: the post had only one visible comment at capture time. But it is unusually clean pain language because it names the gap between carrier data and warehouse receipt rather than asking for generic returns management.
Shopify Help search results describe returns as something merchants can create and manage in Shopify admin, with customers receiving return shipping information and merchants issuing refunds after inspecting returned items. That implies a meaningful status interval between return creation/customer shipment and inspected receipt. A Shopify Community thread about canceling return labels shows a related state-management gap: one merchant says after a return label is created, Shopify can leave an order in “Return in Progress,” and another agrees it is disruptive when there is no tracking history and the return label has not been scanned by the carrier. This is not the same wedge as pre-receipt carrier tracking, but it validates that Shopify return statuses can get stuck between real-world events and admin state.
AfterShip Returns, Loop Returns, ReturnGO, ReturnLogic, and Redo all sell paid returns-management layers for Shopify/ecommerce. Pricing pages show concrete WTP: AfterShip Returns lists Essentials from $16/month for under 100 returns/month and Premium from $99/month for 100-400 returns/month; Loop lists Essential at $155/month and Advanced at $340/month; ReturnGO lists Premium from $147/month and Pro from $297/month. These products validate budget around return automation, refunds, exchanges, store credit, fraud prevention, return analytics, WMS/ERP integrations, and notifications.
The gap is that a merchant asking this question may already know about broad returns apps. They are asking specifically: which returns are in transit, which are aging, which have carrier events, which are not yet scanned by the warehouse, and what should support/refund/warehouse do next?
ReturnGO’s item-validation page says warehouse teams, in-house or outsourced, inspect incoming packages, document what was received, upload images, and then the merchant can decide whether to refund and restock. It also says validation can trigger refund/exchange automation once an item is marked as validated. That supports the pre-receipt gap: before validation, the return is neither fully customer-resolved nor inventory-resolved.
ShipBob’s WMS guide says WMS software uses barcode scanners and real-time inventory visibility, and that the scanning system helps log returned items back into inventory while syncing with returns platforms used for returns or refund processing. This confirms the handoff line: carrier tracking and return authorization are not the same as warehouse receipt scan.
ShipBob’s 2026 returns-management guide defines returns as a systems-driven workflow from customer-initiated return through inspection, disposition, inventory reintegration, and customer resolution. It explicitly says ownership spans customer experience, warehouse operations, inventory, and finance; without clear ownership and handoffs, returns can languish in processing limbo. This is almost the buyer narrative for the exception desk: the blind spot exists because no single team owns the in-transit-before-receipt state.
FedEx’s Basic Integrated Visibility API can return tracking status, estimated delivery, event codes, and delivery options; it also points to advanced near-real-time updates and delivery-event visibility. DHL’s Shipment Tracking API says it can return current shipment location, ETA, shipment status and milestone timestamps, complete travel history, proof of delivery where available, tracking identifier, pieces, weight, and dimensions, depending on service/product availability. Those APIs can feed the desk. But the APIs do not decide whether to hold a refund, message a customer, alert the warehouse, mark an RMA at risk, or prepare a claim handoff.
Claimlane’s 2026 comparison describes “returns parcel tracking” as where the customer’s return parcel is on the way back to the warehouse: drop-off, in transit, received. It separately describes returns-resolution tracking as what happens after receipt: inspection, refund issued, exchange shipped, warranty claim approved, repair completed. That taxonomy is useful because the opportunity sits exactly between return parcel tracking and return resolution: operational exception handling before the warehouse says “received.”
Return volume is not a niche edge case. ShipBob’s returns-management guide says return processing includes return shipping fees, receiving labor, scanning, inspection, disposition, refund processing, payment reconciliation, and customer communication. It also cites high consumer sensitivity to poor returns experience and says recovery value erodes when returns sit unprocessed. Even if some vendor stats should be treated cautiously, the direction is clear: return handling is both CX and margin work.
Preserve these exact phrases for interviews, landing pages, and Reddit replies:
1. Return pressure is now an ops problem, not just a policy page. Merchants are trying to reduce return-related cost while keeping the customer experience smooth. Refund timing is a live tradeoff: refund too early and you risk fraud/loss; wait too long and support tickets pile up.
2. Stacks are fragmented. A Shopify merchant may have Shopify returns, a returns portal, carrier labels, AfterShip/Loop/ReturnGO/Redo, ShipStation/Shippo/EasyPost, a WMS, a 3PL portal, Gorgias/Zendesk, and spreadsheets. Each tool sees part of the state. The pre-receipt gap lives between systems.
3. Carrier tracking APIs are accessible enough for a thin layer. FedEx and DHL expose tracking status and event histories; aggregator APIs can normalize carriers. A v1 does not need to automate refunds or carrier claims. It can start as a carrier-event + Shopify/RMA exception queue.
4. Warehouse/3PL receipt remains a physical event. WMS pages still rely on barcode scans and return logging. That physical scan can lag carrier delivery, happen in batches, or be missing from the merchant’s returns portal. The delay creates ambiguity for support and finance.
5. Incumbents are broad. Large returns platforms have many features, but broad platforms often leave narrow operator pain unsolved or buried. A focused desk can win by being fast to install, opinionated, and explicitly about “open returns before receipt.”
Weekend-buildable v1:
Avoid in v1: becoming a full returns portal, instant-refund fintech product, label-generation platform, full WMS, fraud-scoring engine, or carrier-claim recovery suite. The product is the thin operational layer that makes the pre-receipt blind spot visible.
Best first channel: reply helpfully to exact operator questions in r/smallbusiness, r/shopify, Shopify Community, ecommerce ops Slack groups, DTC Twitter/LinkedIn, 3PL operator communities, and Gorgias/Zendesk/Shopify agency circles. The wedge phrase is not “returns management.” It is “returns that have a carrier scan but are not warehouse-received yet.”
Concrete outreach angles:
Likely pricing test: $99-$299/month for stores under a few hundred returns/month, then $499+/month for higher-volume merchants or 3PL-adjacent workflows. Concierge setup can be $500-$2,000 if it includes mapping Shopify, returns app exports, WMS/3PL exports, and support macros.
Shopify can create/manage returns, send return shipping info, and issue refunds after inspection. It is not primarily an exception desk for aging in-transit returns across carrier events, WMS receipt scans, customer comms, and refund policy rules.
AfterShip Returns, Loop Returns, ReturnGO, ReturnLogic, Redo, Narvar, ParcelLab, Claimlane, ZigZag, WeSupply, and others cover portals, labels, exchanges, store credit, rules, analytics, fraud prevention, WMS/ERP integrations, and notifications. They are both validators and threats. If they expose a good “in transit but not received” queue with aging rules and support macros, the standalone product is too thin. If the feature exists but is buried or enterprise-priced, a narrow desk can still win.
ShipBob-like WMS/3PL systems track receipt and scanned inventory. They often do not own the merchant’s support/refund policy or all carrier events before receipt. The desk should integrate with WMS receipt exports rather than compete with WMS.
DHL/FedEx/UPS tracking can answer “where is this package?” but not “which of my open RMAs are aging, which customer should be updated, which refunds are blocked, and which warehouse receipts are missing?”
Common workaround: export returns, paste tracking links, tag tickets, and manually check carrier pages. This works until volume grows, high-value returns need controls, warehouse receipt lags, or support needs consistent refund-status answers.
Offer a lightweight, no-code audit first: ask a merchant for an export of open returns with return creation date, tracking number, order value, refund status, and warehouse receipt/validation status. Return a ranked exception sheet: no first scan, in transit > policy threshold, carrier delivered but not warehouse-scanned, refund promised but receipt missing, high-value stalled returns, and customer-contact candidates. If 5 merchants say “this is exactly what I need every morning,” build the app.
REDDIT_RESPONSE_DRAFT_START
Yeah, this is a real gap. Carrier tracking will tell you “label created / in transit / delivered,” and Shopify or the WMS usually does not feel real until the warehouse scan happens, so you end up manually checking the weird middle state while the customer is asking about their refund.
The lightweight version I’d set up is an exception list of every open return with tracking status, days since first carrier scan, whether it shows delivered to your return address, whether the warehouse has scanned it, and whether a refund is pending/held. Then you can have rules like “delivered 24+ hours ago but not scanned” or “in transit 7+ days” and use that for customer replies and warehouse follow-up. I help small shops wire together these Shopify/carrier/WMS gaps, and I’d probably start with a CSV/export before buying another big returns platform.
REDDIT_RESPONSE_DRAFT_END
A focused return-in-transit exception queue is a practical SMB ecommerce ops product with clear repeat usage, reachable buyers, and cash-flow/support ROI, though incumbents could absorb the feature.