Lost or Damaged Parcel: Reported in Chat, Decided by Your Team

In the weeks before Christmas, many online shops receive a growing number of messages about parcels that do not arrive, that are marked as delivered but are missing, or that reach the customer damaged. The person writing is usually annoyed, and the first message rarely contains everything the team needs to process it. An assistant on the website can accept these reports, answer from your stored shipping and complaint terms with a source, ask for the missing details, accept photos where attachments are switched on and, once the customer confirms, pass the matter to the responsible queue as a case. It does not decide on replacement, refund or the question of who bears the loss. This article describes the three typical cases, the legal position when shipping to consumers, the details of a workable report, the route to the team and the commitments that have no place in the chat.

Enlarge graphic

Labels in the illustration

• Not arrived
• no parcel so far
• Marked as delivered
• but cannot be found
• Damaged
• or items missing
• Intake in the chat
• Order number
• Type of problem
• Date
• Condition of packaging
• Affected items
• Preferred contact channel
• Photos, if switched on
• Confirm the summary
• Case with full history
• Enquiry, ticket or handover
• Queue by routing rule on handover
• Shipping
• Customer service
• Decision by your team
• Replacement, refund, deadline, liability
• Attachments off by default · images, PDF, at most five per chat
• Not in the chat
• Tracking history
• Contacting carrier
• Trace request
• Damage assessment

Lost or damaged parcel: the path of a report

Three cases, three routes

A parcel report is not one uniform request. Whether a parcel fails to arrive, is marked as delivered but cannot be found, or arrives damaged changes the questions the assistant has to ask and the queue that takes over the case in-house. With a parcel that has not arrived, the first question is whether it can already be there under your shipping terms at all. With a delivery that was reported but is missing, what counts is where the parcel might have been left and whether a neighbour accepted it. With damage, what counts is the condition of the packaging and which items are affected. The assistant finds the right route only if it classifies the case first.

This article covers the report after shipping. How an assistant answers questions about shipping and delivery times before the purchase from your shipping rules is described in the article on shipping and delivery questions in chat. If the goods arrive intact but have a defect, the subject is the statutory warranty; that is covered by the article on complaints and warranty in chat. Here the subject is what gets lost or damaged between warehouse and front door, and how the report about it reaches the team in good order.

Who bears the shipping risk

One sentence comes easily in a chat: “Please contact the carrier.” The German Civil Code (BGB) settles the question of who bears the risk of a loss in transit in three steps. The basic rule is in Section 446, first sentence, BGB:

For a sale involving shipment, Section 447(1) BGB moves this point forward: if the seller ships the goods at the buyer’s request to a place other than the place of performance, the risk passes “as soon as the seller has delivered the item to the forwarder, the carrier or the other person or institution designated to carry out the shipment”. For consumer sales, Section 475(2) BGB restricts this earlier transfer. Under Section 474(1) BGB, a consumer sale is a contract by which a consumer buys goods from a trader, which is the typical case in an online shop selling to private customers. The provision reads:

According to this wording, when shipping to a consumer the risk passes on handover to the carrier only if the buyer commissioned the carrier and the trader had not named it beforehand. If the shop arranges the shipment itself, as is customary in online retail, the earlier transfer does not usually apply, and the point in time remains the handover to the customer under the basic rule. What is meant is the risk of accidental loss and accidental deterioration. Who has to answer for damage in an individual case, whether a parcel counts as handed over and what has been agreed with business customers are not answered by these provisions alone. Your team clarifies these questions, with professional advice where in doubt.

Six details for a workable report

For the team to process a report without writing back, it needs a few fixed details. Six of them usually carry each of the three cases. Following its instruction, the assistant asks for them one after another, uses what the customer has already written and asks only for the rest: anyone who gives the order number in the first message is usually not asked for it again.

In XICBOT, such details are asked for in the conversation, not through a form placed in front of it. Which six details these are is set out in the assistant’s instruction; it summarises them before passing the report on, so they appear in the request of the case and in the conversation history. Only what the chosen shape knows can be marked as mandatory: for an enquiry to the inbox, name, email, phone and the request; for a handover, the same contact details and the reason; for a ticket, subject, description, email and the order number as a reference. If such a mandatory field is missing, nothing is created and the assistant is instructed to ask for it. Only a custom action that your own system serves has its own field schema; it is set up in the Custom package and does not create a case in the inbox. How an assistant takes complete details of equipment faults is described in the article on fault reports in chat.

Photos of packaging and goods

With a damaged parcel, a photo often says more than any description: the crushed box, the wet corner, the broken part in the packing material. In XICBOT, the customer can upload such images in the chat if attachments are switched on for the assistant; by default they are switched off. The uploaded files are attached to the case and do not sit in a second channel; they are kept, however, no longer than the conversation they come from. Acceptance works as follows:

• Images are accepted as PNG, JPEG or WebP, documents as PDF.
• The assistant accepts at most five files per conversation.
• The type of a file is read from its first bytes, not from the extension and not from what is declared.
• An attachment is not delivered as executable and is not cached.
• By default, no separate retention period is set for visitor attachments; you enter it in days yourself. When the conversation period expires, which for a new account is 90 days by default, the attachments go with the conversation; the enquiry remains. Plan the conversation period so that the photos are still available until a damage case is closed.

Three shots are helpful: the packaging from the outside, the opened packaging with the packing material and the damaged goods themselves. The shipping label carries name and address; the order number is usually enough for the report, so a photo of the label is mostly unnecessary. Whether the damage occurred in transit and what follows from it is judged by your team from the images, not by the assistant. How retention periods for chat logs, attachments included, can be set on a sound basis is described in the article on retention periods for chat logs.

From conversation to case

Once the summary is confirmed, the report goes to your team as a case. In XICBOT, every action that writes something is bound to a confirmation, and that explicitly includes creating a ticket (Custom package): the customer sees beforehand what will be passed on, and only their click triggers the action. Which routes exist and how they are secured is described on the tool control page.

For a handover, your routing rules decide which queue receives the case, not the assistant. They look for their keywords in the handover reason and in the conversation title, which is taken from the first message; for parcel reports for instance “arrived” and “delivered” for the shipping queue, “broken”, “crushed” and “damaged” for customer service. If a text carries keywords of several rules, such as “delivered” and “damaged”, the rule higher up in the order wins; the rule for damage therefore belongs before the one for shipping. An enquiry to the inbox is not assigned a queue, and a ticket is distributed by your ticketing system according to its own rules. Without a matching rule, a handover remains without a queue and stands out in the inbox instead of silently landing with the wrong person. A second handover in the same conversation with the same details does not trigger a second message. How a handover to people should be built in principle is described in the article on handover to human agents.

What the assistant does not promise

An annoyed customer above all wants to hear that a replacement is coming or the money is being refunded, and when. Exactly these sentences do not belong in the chat as long as they are not stated word for word in your documents. An assistant that writes “We will send you a replacement right away” makes a commitment your team has not yet made. In the default setting, XICBOT answers exclusively from the stored documents and usually names the excerpts used; if they say nothing on the matter, it says so. How reliably the source reference works is shown by a value of our own: 42 of 48 (own measurement series of 11 September 2026) answers to questions whose answer is in the knowledge base carried a source reference, six did not. The measurement was taken on a single assistant on our own knowledge base, not on customer projects.

After the model, XICBOT runs a second check over hard statements in the draft: deadlines, amounts and promise words are held against the excerpt material, and whatever does not appear in any excerpt is replaced by a placeholder; if there was no excerpt material at all, this comparison does not take place. It is a net for numbers and promise words, not a block on every kind of promise. The rule that the assistant promises neither replacement nor refund nor a processing time therefore belongs explicitly in its instruction, together with the sentence it says instead: that your team will review the case and get in touch through the preferred channel. How such limits are worded is described in the article on the system instruction.

Statutory rights are not an extra

The legal position from the second section has a flip side for your texts. Your shipping terms and frequently asked questions are the assistant’s source. If a text there highlights as a special service what applies towards consumers anyway, such as “With us you bear no shipping risk” as an advantage over other shops, it comes close to a rule of the Act Against Unfair Competition. Its Annex to Section 3(3) UWG lists under No. 10, as a commercial practice that is unlawful towards consumers:

For the chat this means: the assistant repeats what is in your documents and takes over their tone as well. What can be described factually is how your business handles a parcel report, who processes it and which details are needed. Services your business provides voluntarily beyond the law can be described as such, as long as the text does not create a false impression of what applies anyway. Whether a specific wording falls under No. 10 is a question of the individual case and belongs in a professional review. How the assistant deals with another group of statements regulated by the UWG is shown in the article on environmental claims in chat.

When the tone gets sharper

Someone waiting for a Christmas present that does not arrive rarely writes calmly. Two mechanisms in XICBOT help to pass such conversations to a person in good time. First, the complaints topic can be switched on per assistant in addition to the fixed subject limits; when it is on, the topic rule recognises a complaint and hands the conversation over to a person. Second, the assistant detects frustration without a language model, through a point system: the call for a person weighs heaviest, joined by angry words, the same question asked again, writing in capitals and piled-up exclamation marks. From the configured threshold on, a handover happens, exactly once per conversation; the threshold sits with each assistant version. How this detection works is described in the article on detecting frustration in chat.

Set up before the peak, evaluate afterwards

A parcel report in chat can hardly be introduced in the week before Christmas Eve. Shipping and complaint terms have to be in the knowledge base, the instruction with the six details and the routing rules set up, attachments switched on and the test sentences run before the peak begins. How a shop prepares for the season is described in the article on peak season support spikes. After the season, the evaluation shows whether the intake works: topics emerge from the visitors’ questions, and for each topic the evaluation shows the handover rate, not only as a single total. If it rises for parcel reports, that points to a gap in the documents or to a rule that applies too early. What the evaluation counts is shown on the conversation analytics page.

• Knowledge base: shipping and complaint terms are in it, without a blanket referral to the carrier.
• Three cases: each case is described with sample sentences and has its queue for handovers in the routing rules, with the rule for damage before the one for shipping.
• Six details: the instruction names the six details the assistant asks for: order number, type of problem, date, condition of the packaging, affected items and contact channel.
• Attachments: they are switched on for the assistant, a retention period for attachments is entered, and the conversation period lasts until a damage case is closed.
• Commitments: the instruction rules out promises on replacement, refund and processing time unless they are stated word for word in the documents.
• Test: sentences for all three cases and for an annoyed message have been run before the season.

Frequent questions