--- title: "Automating delivery claims and tracking" description: "What answering delivery claims by hand costs, what promising a date that slips costs, and what an agent does at each step of the enquiry." url: https://studiochat.io/blog/reclamos-de-entrega locale: en translations: { es: https://studiochat.io/es/blog/reclamos-de-entrega.md, pt: https://studiochat.io/pt/blog/reclamos-de-entrega.md } site: https://studiochat.io --- [ Back to blog](/blog) A message comes in: "hi, my order still hasn't arrived". Answering it well takes four things. Working out which order they mean, because they almost never send the number. Looking up the status in the carrier's system. Working out whether that status is inside the window or outside it. And translating it into what the person actually asked, which is not the status: it is whether it arrives before Friday. Four screens and one translation, a hundred times a week. ## [The cost isn't answering, it's answering the same question badly twice](#the-cost-isnt-answering-its-answering-the-same-question-badly-twice) There are two populations of claims sitting in the same inbox, and treating them the same is what buries the team. The first is large and easy: the data exists, it is in the carrier's system, and a person answers it exactly the way a system would. Same screen, same field, copied across. The second is small and hard: the shipment is delayed, the status has not moved in three days, and the date the customer wants exists in no system. Somebody has to decide it, and deciding it means calling the carrier. The expensive error lives right on the border between the two. It is answering the second as if it were the first: sending "in transit" to somebody whose shipment is stuck, or worse, promising a Thursday that will not hold. That does not close the case, it multiplies it. ## [The same claim, today and with an agent](#the-same-claim-today-and-with-an-agent) One delivery claim, end to end * the agent does it * a person does it * always a person the steps of the claim * the agent does itIdentify which order they mean Orders Resolves the order from the phone number, the name or the last purchase, without asking for a number the customer does not have. * the agent does itQuery the carrier for the status Carrier Asks the carrier by tracking number and brings back the last event with its date, during the conversation. * the agent does itTranslate it into a date Carrier Turns in transit into when it was due, what has happened since the last event, and whether to wait or whether this is already a problem. * the agent does itSpot the delayed shipment Carrier Compares status against the window and flags the ones that slipped, instead of waiting for the customer to notice first. * the agent does itWrite before they ask WhatsApp Messages the customer of a delayed shipment before they message, which is the only way the second message never exists. * the agent does itOpen the claim with the carrier Carrier Assembles the claim with number, due date and last event, ready to send, which is the step postponed today for lack of time. * the agent does itLog the case and what the carrier said CRM Records what was asked, what the carrier answered and what the customer was told, so the next message does not start from zero. * always a personCommit to a new date CRM Promising a customer a day is a decision. A person makes it, with the claim already open and the carrier's answer in view. Shipping enquiries per month: 300 Minutes answering one takes today: 14.0 Hourly cost of whoever answers: USD 12 Share answered badly or overpromised: 4% What that second round with the customer costs: USD 40 Today that is 70 hours a month and 12 enquiries answered badly. Between the time and the second round, USD 1,320 a month. With the agent holding 7 of the 7 steps, 3 hours and USD 60 are left. The difference is USD 1,260 a month, USD 15,120 a year. And 36% of that difference is not time: it is the answers that do not produce a second message the next day. Of what a person still does, the heaviest step is: Commit to a new date. You set all five numbers. How the minutes split across steps is ours, taken from how it gets done by hand. The modelling assumption: the badly given answer falls in the same proportion as checking the status and translating it stop depending on somebody having time. Switch off the proactive notice and leave the rest on. That is the normal implementation and it works well. But the step that removes the most enquiries is not answering fast: it is writing first, because the enquiry that never happened consumes nothing. This object also has [a page of its own](/delivery-claims-with-an-agent), in case you want to send just that. ## [What the agent does that a person cannot](#what-the-agent-does-that-a-person-cannot) **It looks at every shipment every day.** A person looks at the ones they are asked about. An agent compares every shipment's status against its window and finds the twenty that slipped before anybody writes. **It writes first.** Warning before they ask is impossible by hand, because it means reviewing thousands of shipments to find the few that matter. It is also what cuts the volume most. **It does not improvise a date at seven in the evening.** The error of promising a Thursday that will not hold gets made when things are rushed. An agent says it is delayed, says since when, and says a person will confirm the date. That answer is acceptable; the invented Thursday is not. ## [What stays with a person](#what-stays-with-a-person) Committing to a new date. It is a commitment with consequences and no system makes it. What changes is what that person arrives with: today they arrive with an angry customer and a screen; with the agent they arrive with the claim already open at the carrier, the detail assembled and the carrier's answer in front of them. ## [How it gets implemented](#how-it-gets-implemented) The integration is among the simplest there is: query a shipment by number and receive events with dates. Almost every carrier exposes that. What almost never comes is a reliable estimated date, because the ones carriers publish are commercial promises rather than operational estimates. So the rule worth adopting from the start: the agent reports dates that come from the system when the shipment is on time, and invents none when it is delayed. The order is query and translation first, delay detection second, proactive notice third. The carrier claim can enter at any point because nothing is sent without approval. ## [What to measure](#what-to-measure) Total volume drops fast and is the easy thing to show. The number that counts is different: what share of enquiries produced a second enquiry from the same person within the following 48 hours. That one tells you whether the agent is answering or only informing. And the third, the one that convinces operations: how many delayed shipments were spotted before the customer wrote. That number starts at zero in every operation. Frequently asked questions ### What does an AI agent do with delivery claims? It identifies which order they mean even when the customer has no number, queries the carrier for the status, translates that status into the real question which is when it arrives, spots the shipments that fell outside their window before the customer asks, writes first, and opens the claim with the carrier for the delayed ones. ### Why doesn't answering in transit work? Because it does not answer what the customer asked. The customer wants to know whether it arrives before Friday, because they have something planned for Friday. A status with no dates in it is an answer to a question nobody asked, and the symptom is the same person writing again the next day. ### What about shipments that are already delayed? An agent does not resolve those by answering: somebody resolves them by chasing the carrier. What the agent does is pull them out of the pile, open the claim with the detail, and free the team from the easy enquiries so it has time to fight those twenty. A person commits to the new date. Share [ X](https://x.com/intent/post?text=Answering%20where%20an%20order%20is%20takes%20four%20screens%20and%20one%20translation&url=https%3A%2F%2Fstudiochat.io%2Fblog%2Freclamos-de-entrega) [ LinkedIn](https://www.linkedin.com/sharing/share-offsite/?url=https%3A%2F%2Fstudiochat.io%2Fblog%2Freclamos-de-entrega) [ WhatsApp](https://wa.me/?text=Answering%20where%20an%20order%20is%20takes%20four%20screens%20and%20one%20translation%20https%3A%2F%2Fstudiochat.io%2Fblog%2Freclamos-de-entrega)Copy link Iván Itzcovich Iván Itzcovich · Co-founder, StudioChat Want agents like these working for your team? [Talk to us now](https://cal.com/studiochat)