A customer asks where their order is. The agent checks tracking, sees “delivered” and sends a standard reply. But the customer writes again: they do not have the parcel. For the carrier, the journey is complete; for the store, the request seems handled; for the buyer, the problem has only just begun.
Classify delivery enquiries by the customer's need and verified facts, not just the shipment status. “When will it arrive?” can be a routine question, a delay report or a complaint. These situations require different next actions even though they concern the same parcel.
A practical solution is to track delivery status separately from service-case status. Below we explain how to receive these requests, assign checks to the warehouse or carrier and give customers verified information. This is an operating procedure, not legal advice about claims or compensation.
Two statuses instead of one
Shipment status describes a logistics event: label created, handed to the carrier, in transit, arrived or delivered. Names and meanings depend on the carrier. Request status describes your team's work: checking information, awaiting a partner response, agreeing a solution or verifying completion.
Do not automatically close a service case just because tracking shows delivery. The customer may report a missing item, damage or a different recipient. Equally, an open ticket does not prove the shipment is lost: the customer may simply need an explanation of the current delivery stage.
The purpose is not to add fields but to prevent the wrong action. Support needs the source of the logistics fact, the time it was checked and the buyer's outstanding need. Conflicting information calls for investigation, not a choice of whichever version is more convenient.
Distinguishing a routine enquiry, a delay and a complaint
At first contact, establish what the customer expected and what actually happened. Compare the answer with the order and current delivery terms. Do not ask the buyer to select your internal request category.
- Routine status enquiry. Progress matches the agreed terms; the customer needs an explanation or tracking link. Check that the information is current and give a clear answer.
- Deviation from expectations. The agreed deadline has passed, tracking is not updating or events conflict. Check the cause, assign an owner and set the next update time.
- Complaint situation. The buyer reports non-delivery, damage, missing contents or another specific fulfilment defect and expects a solution. Record their request and evidence, then assign an authorized employee.
These are operational routing categories, not legal definitions of a claim. Deadlines, documentation and remedies depend on the contract, carrier, order and applicable rules. Do not replace checking those terms with a universal promise of compensation within the same deadline for everyone.
If the buyer only wants an update, a complex claims process is unnecessary. But when they explicitly say “I did not receive it,” a template linking to “delivered” no longer answers the main question. Change the case route without making them start again.
Intake record: which information is genuinely needed?
Collect the minimum needed to identify the shipment and understand the issue. An order number and a shipment number are different identifiers. If an order ships in parts, a customer record alone will not explain which box is missing.
Record the order, specific shipment, reply contact, issue in the customer's words, agreed expectation, latest verified fact and its source. Add the communication owner, next action and review time. This already lets a colleague continue without reconstructing the history from personal chats.
Request documents and photographs when the particular situation requires them. Do not demand a full evidence package for a simple route question. Never ask for payment details or identity documents in a public comment. Access to contacts, addresses and attachments should match employee roles, and retention should follow company rules.
The source and time matter more than a copied status
“Parcel in transit” quickly loses value. A better note says it was checked in the carrier portal, identifies the latest event as transfer to sorting and records the check time in the case. This does not guarantee an arrival date, but shows whether the agent is using current information.
A label created by the store is not itself evidence that the carrier received the parcel. If acceptance is unconfirmed, direct the first internal question to the warehouse or dispatch owner. Otherwise support may search for goods with a partner that has not received them.
One customer-facing owner, separate internal tasks
Checking may involve the warehouse, logistics, finance and an external carrier. That does not mean the buyer should contact each in turn. Assign a service-case owner who gathers results and answers the customer even when another department does part of the work.
An internal task needs more than “check delivery”: specify an output such as dispatch confirmation, recipient verification or available replacement-shipment options. Set a response deadline and a way to return the result to the case owner. A carrier enquiry also needs a reference and a review date.
“Awaiting the carrier” describes a dependency, not an absence of responsibility. The case owner monitors the next update and communicates changed circumstances. If the partner does not answer, the owner follows the agreed follow-up or escalation route without inventing investigation findings.
General task coordination principles are discussed in our helpdesk platform comparison. For delivery, add verification of the specific shipment: the existence of a task does not prove where the goods are or what to offer the buyer.
What to tell customers before you have the answer
A message should separate the known fact, the company's action and the next contact point. Do not turn an internal review date into an unconfirmed delivery promise. Clearly saying that arrival time is being checked is better than repeating yesterday's estimate as a new guarantee.
A hypothetical template: “The latest shipment update does not explain the delay. We have contacted the carrier and are checking dispatch with our warehouse. By the agreed time, we will report the findings or the next step, even if the partner has not yet answered.” Insert real facts and a time the team can meet before sending.
If tracking shows delivery but the buyer denies receipt, do not begin by dismissing their account. Acknowledge the discrepancy and explain the check. Do not disclose another possible recipient's details before verifying permissions and grounds for disclosure.
The official Shopify customer-service guidance also emphasizes clear delivery and return policies, a concrete solution and subsequent verification. Turn those principles into ownership and a next action in your procedure, not merely polite wording.
A hypothetical scenario: “delivered,” but no parcel
This is an invented process example, not a customer case or any particular carrier's rules. A store buyer reports that tracking marks a shipment delivered but they have not received it. The agent finds the order, identifies the specific shipment and records the discrepancy.
The case owner assigns logistics to obtain delivery confirmation. The request remains open until verified information returns. The customer is told about the check and next contact, without a promise of automatic compensation. If there are several boxes, each is checked separately so a received part is not confused with the missing one.
Once facts are established, an authorized employee agrees an available remedy under the order terms. If a replacement shipment is chosen, creating a label does not finish the case: actual handover and completion of the agreed remedy still need checking. For another remedy, closure evidence must match that remedy.
Settlement with the carrier and the buyer's remedy may finish at different times. Keep them linked, but do not leave the customer uninformed solely because an internal settlement remains open. Conversely, do not consider a financial claim against the partner finished just because the customer conversation is closed.
What to check in HelpDeskStar before launch
HelpDeskStar combines customer requests and internal tasks. Bring a delivery scenario with conflicting information to the demonstration instead of asking for an abstract feature list. Check how the team sees the owner, case status, internal work results and outstanding actions.
Separately confirm where shipment identifiers will be stored, who can access evidence and how current carrier information will be obtained. A ready-made connector, automatic status synchronization or dedicated complaints module must be confirmed for your configuration. This procedure does not claim these integrations are already available without setup.
For low shipment and request volumes, a shared register with an owner may be enough. Evaluate a helpdesk when requests routinely involve several people and manual control becomes unreliable. Departments, access and working procedures can be agreed during turnkey HelpDeskStar implementation.
A team acceptance test
Walk through three situations: delivery is on schedule; the agreed deadline has passed; tracking shows delivery but the customer denies receipt. For each, check that the fact source, case owner, internal action, next message and completion evidence are clear. If all three follow the same route, classification is not yet helping the work.
Conclusion
Delivery support works better when a team does not confuse goods movement with resolution of the buyer's need. Separate shipment status from the service case, check fact sources and retain one communication owner. Even a dependency on an external partner will then have a clear next step.
Start with a short intake record and three routes: information, deviation and complaint. Test them against real request types, agree exceptions and only then add automation.