Returns keep recurring but the shop cannot isolate the fix

The problem

Return counts alone do not show whether a particular size or product has a disproportionate issue or simply sells more.

Agent job

Join minimized item-level returns to their original sales lines using merchant-generated opaque tokens; form sale-date cohorts, separate missing reasons and compute returned-unit rates against eligible sold units. Surface patterns and competing explanations without causal claims.

Expected output

Reconciled analysis workbook, three evidence-linked hypotheses and a data-quality report.

Why an agent / simpler alternative

Assessment

The agent can interpret messy return-reason labels and propose competing explanations for patterns. SQL or spreadsheet formulas should calculate rates. Use native analytics first if it already answers the question; product and customer-service staff decide whether a proposed fix makes sense.

Setup requirements

Items

1. Matching minimized item-level sales and returns exports with merchant-generated opaque sale-line tokens; sales include SKU, sale date, units and status; returns include unique event token, return date, units and reason. Merchant retains crosswalk. Aggregate SKU-period totals alone are insufficient for this cohort method.

2. Agreed sale-date cohort, observation cutoff, return window, eligible sold-unit denominator, cancellation/exchange handling and reason taxonomy

3. Documented distinction between return, refund, cancellation and exchange

4. Merchant-approved minimum cohort sizes and a review contact

Inputs and access

1. Name

   Minimized item-level returns export: opaque merchant-generated sale-line token, unique return-event token, SKU, return date, returned-unit quantity and approved reason code

   Source or owner

   Consenting merchant; token crosswalk stays with merchant

   Sensitivity

   Pseudonymized transactional data, not guaranteed anonymous; exclude names, addresses, emails, payment details and free-text customer comments

   Permission needed

   Merchant approves these exact fields, processing destination and retention before export; assess remaining reidentification risk

2. Name

   Minimized item-level sales export: matching opaque sale-line token, SKU, sale date, units sold and cancellation/exchange status; SKU-period totals provided only as reconciliation controls

   Source or owner

   Consenting merchant; token crosswalk stays with merchant

   Sensitivity

   Pseudonymized transactional data, not guaranteed anonymous; no customer identifier or financial/payment fields required

   Permission needed

   Merchant approves exact fields, processing destination and retention; retain no token crosswalk

3. Name

   Merchant-approved category and reason definitions

   Source or owner

   Prospective consenting customer or specified official publisher

   Sensitivity

   Use synthetic, public or appropriately deidentified material; confirm actual sensitivity before work

   Permission needed

   Owner authorizes scoped access and processing; verify rights and retention before receiving files

Proposed steps

1. 1

   Define the decision the merchant wants to make and check whether native reports already answer it.

   Expected output: Decision brief and tool-gap check

   Approval gate: Stop if the proposed service duplicates an adequate existing report.

2. 2

   Validate the exact sales/return field manifests and merchant tokenization; detect duplicate sale-line/return-event tokens, reconcile unit totals to merchant controls and list unmatched return lines.

   Expected output: Data-quality and unmatched-row log

   Approval gate: Merchant approves the specified transactional fields and destination before transfer. Exclude personal/contact/payment fields and token crosswalk; never silently drop unmatched returns.

3. 3

   Join each return event to its original sale line, assign the sale-date cohort and apply the approved cutoff/window and cancellation/exchange rules. Sum returned units per sale line; preserve unknown reasons and flag returns exceeding eligible sold units.

   Expected output: Cohort and taxonomy mapping

   Approval gate: Merchant approves category merges and return-window assumptions.

4. 4

   Calculate returned-unit quantity divided by eligible units sold for mature sale-date cohorts using reproducible formulas; show SKU/reason breakdowns, denominator definitions and excluded or unmatched units.

   Expected output: Analysis workbook

   Approval gate: No rankings for cohorts below the agreed minimum without a prominent caveat.

5. 5

   Draft three hypotheses and specify what additional evidence would distinguish them.

   Expected output: Decision memo with alternative explanations

   Approval gate: No claim that correlation proves a defect or that a change will save money.

6. 6

   Reproduce sample calculations with the merchant and deliver a prioritized test list.

   Expected output: Accepted report and open questions

   Approval gate: Human approves any sizing, product, refund or customer-message change.

Synthetic output illustration — not an executed result

Synthetic

Yes

Executed

No

Text

SYNTHETIC: In mature sale-date cohorts, SKU A: 12 returned units / 120 eligible sold units = 10%; SKU B: 8 / 20 = 40%. B has a higher observed unit-return rate but a small denominator. Three returned units have unknown reasons. No real shop data was analysed.

Human approval boundaries

1. Merchant approves deidentified data and interpretation; human decides all product changes, refunds and customer communications.

2. Human service provider reviews quality, scope and quoted fee; customer approves contract, delivery recipients and payment terms. Separately approve purchases, credentials, publication and external sends. No commitments or payments are made in this research.

Failure modes

1. Return windows lag sales

2. Refunds and returns are not interchangeable

3. Small cohorts produce misleading rankings

4. Reason selection can be inconsistent

Recovery and troubleshooting

Items

1. If refunds and returns are mixed, split the records by documented type or declare the dataset unsuitable.

2. If late returns distort a cohort, extend observation or restrict to mature cohorts; disclose the excluded period.

3. If small samples dominate, report uncertainty and recommend collecting more data rather than selling a confident ranking.

4. If only aggregate SKU-period sales counts are available, stop this joined cohort analysis and request a separately approved minimized item-level export. Do not imply that same-period return counts divided by sales are cohort return rates; an aggregate-only descriptive report would require a new agreed scope.

Unexecuted validation plan

Sample setup

Use 200 synthetic sales-line records and 30 synthetic return-event records with matching opaque tokens, explicit sold/returned quantities and dates; seed one duplicate event, one unmatched return, a partial return and delayed returns. No real transactional data is required for this first test.

Acceptance checks

1. Reconcile sold and returned unit totals to fixture controls and detect the seeded duplicate/unmatched events before computing rates

2. Attribute returns to original sale-date cohorts and apply the approved observation cutoff; list excluded or unresolved units

3. Use eligible sold units rather than order counts as denominator; prevent duplicate events or excessive returned quantities from inflating rates

4. No causal or savings claim; show small-cohort caveats

5. Owner can reproduce two unit-based rates manually

Stop conditions

1. Stop if data authority or rights are unclear.

2. Stop if critical seeded failures are missed; do not claim readiness.

3. Stop if manual correction time exceeds the pilot effort budget without customer approval.

Executed

No

Costs and effort — unknown or hypothetical

Status

unknown_or_estimate

Currency

CAD

Items

1. Agent subscription/API usage: not quoted; verify current plan and commercial data terms.

2. Human intake, rights review, QA and revisions: unknown until timed pilot.

3. Storage, hosting, integration and payment-processing costs: excluded unless separately agreed.

4. Customer acquisition and support time: not measured.

Caveat

No margin or income estimate. Price hypotheses are editorial offer tests, not observed market rates; taxes, scope and effort require a real quote.

Proposed service concept — earnings not verified or guaranteed

Buyer

Small online apparel or accessory brand

Deliverable

Reconciled analysis workbook, three evidence-linked hypotheses and a data-quality report.

Charging basis

One-off returns diagnostic; repeat only when data volume supports a meaningful comparison.

Acquisition channel

Permission-based discovery with existing professional contacts, referrals or an opt-in sample page; none executed.

Assumptions

1. Customer has this unresolved problem and values a reviewed deliverable above existing built-in alternatives.

2. A consenting pilot confirms data access, achievable quality and economically tolerable review time.

3. Provider can deliver within a written scope and supports the result.

Revenue guarantee

No

Canadian adaptation — proposed

Proposed Canadian pilot: align sale/return dates to the merchant’s reporting timezone, preserve Canadian and other-market cohorts separately when return windows differ, and map English/French reason codes only with merchant approval. Rates use units, so no currency conversion is needed. Confirm handling of the minimized transactional export; no Canadian implementation or legal assurance.

Limits

1. Original proposed plan; untested.

2. Problem and capability references are evidence of context only, not demonstrated end-to-end success, customer demand, willingness to pay or profitability.

3. Compatibility, workload, delivery effort and availability must be verified in a real authorized pilot.

4. This plan requires the specified minimized item-level sales and return fields. Aggregate sales-by-period alone cannot link delayed returns to original sale cohorts. Opaque tokens reduce disclosure but do not guarantee anonymity.

5. Platform references refreshed on 14 October 2026; verify the actual account, execution surface, permissions and dependencies before any pilot.

Candidate platforms — compatibility untested

1. Name

   Claude (Cowork capabilities)

   Required capabilities

   1. Read supplied files and produce editable documents and spreadsheets.

   Capability source urls

   1. https://support.claude.com/en/articles/13345190-get-started-with-claude-cowork

   2. https://support.claude.com/en/articles/16761823-claude-cowork-and-chat-are-one-claude

   Workflow compatibility

   Unknown; verify in the proposed first test.

   Historical candidate name

   Claude Cowork

   Selection basis

   Editorial candidate from general capabilities; exact end-to-end fit untested.