Verify identity during exchange pickup and replacement delivery

The replacement product is ready to hand over, but the serial number on the customer's returned item differs from the return authorisation. Completing both tasks would hide the mismatch. Asking the driver to decide warranty eligibility would give the field worker a decision they may not be authorised or equipped to make.

Pilot an exchange workflow that verifies the required identity evidence and preserves both custody paths. The merchant decides how a mismatch is resolved, while the carrier records what was observed, collected or delivered.

Limit the first pilot to one exchange policy

Choose one merchant, product family, carrier workflow and approved identity rule. Use authorised test orders and redacted examples before working with live exchanges. Exclude product categories whose safety, installation or inspection requirements cannot be handled by the agreed field process.

Name the merchant's exchange owner, a customer-service decision maker, the carrier supervisor and the integration owner. Specify who can approve a substitute identity, authorise provisional collection or release a held replacement.

Microsoft's sales-return documentation distinguishes authorising a return from accepting goods or granting credit. That distinction also matters in an exchange: an approved request does not eliminate the later identity and disposition decisions. Microsoft Dynamics 365 — Sales returns

The first automation should support evidence capture and routing. It should not independently decide warranty coverage, impose a deduction or classify a customer as dishonest.

Link the two legs before dispatch

Create an exchange identity connecting the order, return merchandise authorisation, expected return item, replacement item and each carrier task. Retain the customer's agreed exchange arrangement and the policy version that applies.

For each item, define the required evidence: a supported barcode or serial, model, agreed accessories and other relevant identifiers. Do not collect unrelated personal documents or photographs merely because the device allows uploads.

The return and replacement may have different shipment IDs. Both should remain linked to the exchange without merging their custody histories. A successful replacement delivery does not prove that the expected return reached the warehouse.

If the merchant changes the authorised item after tasks are dispatched, invalidate the affected field instruction and issue a controlled revision. An old offline task should not silently inherit the new approval.

Follow a serial mismatch through the handoff

Consider an illustrative exchange X-56. The return authorisation expects serial S814, while the item presented at the doorstep shows S841. Replacement R901 is still in carrier custody.

A transposed character may reflect a master-data error, a capture error or a different physical item. The mismatch alone establishes none of those explanations. Preserve the observed value and the expected value, rather than correcting one to match the other.

In the default path for this example, the customer keeps the presented item and the carrier keeps the replacement until an authorised decision is available. Where the merchant has an approved provisional-collection process, record that separate custody outcome explicitly.

Treat provisional collection as a distinct state

Suppose an unreadable serial prevents confirmation but the merchant authorises collection into an inspection hold. Record the actual item collected, available evidence, authorising person and the destination hold. Do not label the return identity verified.

The replacement may remain held under that policy, or a separately authorised decision may permit delivery. The system must record the actual decision rather than infer it from pickup completion.

Microsoft's disposition documentation shows that configured return actions can affect physical and financial outcomes. Mapping a provisional pickup into a default accepted-return code could therefore advance more than the field team intended. Microsoft Dynamics 365 — Specify how to dispose of returned items

At warehouse receipt, reconcile the item and evidence with the provisional record. A later inspection decision should close the identity exception through a linked event, preserving what the driver could and could not establish.

Reconcile a small operating cohort

Take an illustrative set of 12 attempted exchanges. Nine complete normally. Two stop at the doorstep because of unresolved serial mismatches. One follows the authorised provisional-collection path for an unreadable identifier, with its replacement still held.

There are nine completed exchanges, ten return items in carrier or warehouse custody, and nine delivered replacements. The tenth collected return is unresolved. The two mismatch items remain with customers under this example's policy.

Those counts should coexist. A report that equates ten pickups with ten completed exchanges would close the provisional case incorrectly. A report counting only completed exchanges would hide the tenth item already in the carrier's custody.

Show the remaining replacement locations and next actions. “Exchange pending” is not enough if the team cannot tell who holds each physical item.

Make capture and retry safe

Bind evidence to the current exchange and task version. A driver should see the item and handoff relevant to that customer visit, with a clear result for matched, mismatched or unreadable evidence.

Use stable pickup and delivery event identities. If a device loses its acknowledgement and resends, reconcile the original event rather than create another pickup or another completed exchange.

Keep event time and upload time separately. A delayed upload must not reverse an authorised decision made after the visit without review. Preserve original photographs or scan evidence under the organisation's approved retention and access rules.

OWASP's object-level authorisation guidance applies to APIs retrieving exchange, order or evidence identifiers. OWASP — Broken Object Level Authorization Test that an authorised user cannot retrieve another customer's task by changing an ID.

Define the merchant response path

The case should contain expected and observed identity, source references, custody state, replacement state, policy version and the action needing approval. Assign a merchant owner and a review deadline appropriate to the service agreement.

A decision must identify what is authorised: correct the expected serial, recollect evidence, accept provisional return, cancel the exchange or use another permitted resolution. A generic “approved” message without scope can be misapplied to both legs.

If the customer disputes the observation, retain their account alongside the original evidence. Route the case for review; do not overwrite the field record or turn a mismatch flag into a fraud label.

Where no reviewer is available, use the agreed fallback. The driver should not be forced to choose an unsupported completion status merely to close the app screen.

Measure the pilot against the current handoff

Build a labelled sample of clean exchanges, serial mismatches, missing accessories, unreadable identifiers, task amendments and duplicate uploads. Run the same cases through the existing process to establish active effort, unresolved custody and correction rates.

Begin in shadow mode, then allow supervised evidence capture and case routing. Proposed acceptance requires every collected return and delivered replacement to have a linked custody record, no unreviewed identity exception to be marked verified, and retries to preserve one business outcome.

Measure time to a merchant decision separately from time at the doorstep. A faster scan may not reduce the customer's wait if the review queue is unstaffed.

Stop the automated path when a wrong task is shown, evidence is linked to another exchange, a required approval is bypassed or custody cannot be reconciled. The fallback is the existing authorised exchange process with the same shared exchange register, preventing a second untracked collection.

The merchant exchange owner and carrier supervisor accept the fallback's outstanding tasks and physical-item locations. Before resuming, reconcile any visits completed during the interruption, confirm which decisions reached the driver and retest the failed case. The integration owner restores the technical path; the merchant and carrier owners approve the operational restart.

Close the exchange from both sides

A completed exchange should have known return and replacement outcomes under the merchant's policy. Inspection, refund or warranty decisions can remain separately pending where the process allows, with clear ownership.

Next actions

1. Define one exchange policy, product scope and the identity evidence the driver may collect.
2. Link the RMA, replacement and carrier tasks with versioned merchant decisions.
3. Test mismatch, provisional collection, amendment and lost-acknowledgement cases.
4. Reconcile both custody legs and compare the supervised pilot with the manual baseline.

To scope an exchange-verification pilot, identify the merchant system, carrier channel and mismatch that most often prevents a clear handoff.