Shipment status updates and customer replies

The Shipment Status Updates and Customer Replies process is the main communication bridge between the customer support team and anyone asking where their order is. A customer sends an enquiry, typically by email, and an agent has to locate the relevant shipment data by checking the MES, one or more carrier systems, and often a spreadsheet that fills the gaps between those sources. Once the agent has assembled a picture of what is actually happening with the shipment, they compose a reply and send it. If anything looks wrong, whether the data is stale, there is a mismatch between systems, or the news is bad, the agent has to make a judgement call about how to handle it, sometimes escalating to a supervisor.

This happens continuously throughout the working day, with roughly 15,000 enquiries per year. At five minutes per case, that is approximately 1,250 person-hours annually spent on a task where the answer is almost always already sitting in a system somewhere. The vast majority of cases follow a single predictable pattern: find the data, verify it looks current, format a reply, send it. The remaining cases, estimated at around five percent, involve exceptions that require real human judgement, including delays or defects that carry product safety or traceability implications, data entry errors that need correcting before any reply goes out, and bad-news scenarios where the tone and content of the response matters significantly.

The process sits under the customer support team but is overseen by a plant manager and shift supervisors who are also responsible for understanding when an exception has compliance implications. The MES is a legacy system but its database is directly readable, and an automation engineer with a PLC background is available and willing to learn Python, which makes a code-based integration layer a realistic option without requiring external engineering resources.

The recommended path is Hybrid: an AI workflow that handles the routine majority of cases automatically, with a hard human-in-the-loop gate that intercepts every exception before a reply reaches the customer. This is not a close call. The process has a clear structural split between a high-volume, low-variability standard case and a small but consequential exception tail, and the right architecture maps directly onto that split. Automating everything without a gate is irresponsible given the product safety obligations. Automating nothing wastes more than a thousand person-hours a year on a task that does not require human judgement most of the time.

The client has expressed a clear preference for Python, and that preference aligns well with what the technical layer of this solution actually needs. The automation engineer can write Python connectors to read directly from the MES database and pull in carrier data feeds, normalising them into a single status object that the rest of the workflow can query without caring which system the data originally came from. This integration layer is the foundation of the whole system, and building it in Python means it is maintainable in-house without relying on a proprietary platform or a vendor relationship. An orchestration layer such as n8n, or a lightweight LLM-backed service, can sit on top of that Python foundation to handle the natural language reply generation and the triage logic that decides whether a case is standard or an exception.

The alternative paths each fail on one or more meaningful dimensions. A fully automated AI Workflow scores well for the standard cases but has no safe answer for the exception tail, and at this volume the exception tail represents roughly 750 cases a year that could carry recall implications. That is not a tail you can automate away and hope for the best. RPA is the wrong tool entirely: the MES database is directly readable, so screen-scraping automation adds brittleness without adding capability, and it cannot generate contextually appropriate natural language replies. A fully autonomous AI Agent is similarly inappropriate here because compliance obligations require a human to stand between the system and the customer whenever the reply touches a potential defect or delay. Traditional Code alone, meaning Python scripts without an AI layer, could handle the lookup and formatting steps reliably, but it would need an ever-growing library of hand-coded rules to deal with natural language variation in incoming queries and to compose replies that read well across different exception types. That approach scales poorly and becomes a maintenance burden as soon as edge cases accumulate. Education alone does nothing to address the structural fragmentation of the data or the volume problem.

The Hybrid path is honest about what automation can and cannot do here. It automates the part of the process that is genuinely mechanical and gives that time back to the team. It keeps a human in the loop for the part of the process where the stakes are real and the judgement is irreplaceable. The automation engineer's Python skills mean the integration layer can be built, owned and evolved internally, which reduces long-term cost and dependency. The exception gate is not just good practice; it is the compliance control point for the process, and its design deserves the same care as the automation itself.

The two strongest contenders here are Hybrid and fully automated AI Workflow, and the gap between them comes down to one thing: the exception tail. A fully automated AI Workflow could handle the standard status queries well enough, reading from the MES database, normalising carrier data and generating a reply without human involvement. But roughly 750 cases a year involve bad news, data mismatches or traceability concerns that carry real compliance weight, and a fully automated system has no natural place to stop and ask for help. Sending a confident, automated reply about a potential defect or a delay that might trigger a recall conversation is a meaningful legal and reputational exposure. The Hybrid path solves this by keeping the automation for the 95 percent of cases where the answer is simply in the data, while routing everything else to a human with full context already assembled.

Traditional Code is worth considering because the automation engineer is already comfortable in that space and the MES database is directly readable. A Python script could absolutely handle the lookup and formatting steps, and for a simpler process it might be the right call. The problem here is the natural language variation in incoming customer enquiries and the need to compose contextually appropriate replies for edge cases. Hand-coding logic for every possible exception type, carrier format and message tone is a maintenance burden that grows quickly. The Hybrid path uses Python exactly where it belongs, as the integration and data normalisation layer, and hands the language and triage work to an AI workflow layer that is better suited to it.

RPA was considered and ruled out for a clear reason: the MES database is directly readable, so screen-scraping automation adds complexity without adding value. RPA would also struggle with the natural language composition step and with exception triage logic that doesn't follow a rigid screen-by-screen path. At 15,000 cases a year, a brittle RPA layer would generate its own maintenance overhead that offsets much of the gain.

The foundation of the whole system is a clean, unified shipment status object, and that starts with the automation engineer writing Python connectors directly against the MES database. The MES is legacy but database-readable, which is a significant advantage: no screen scraping, no brittle UI dependencies, just direct SQL or ODBC queries pulling the fields that matter for a status reply. In parallel, the engineer builds a normalisation layer that pulls carrier data feeds, whether that's via carrier APIs, SFTP file drops or email-parsed CSVs, and maps them onto the same status schema as the MES data. Where spreadsheets currently fill the gaps, those sources get ingested too, with explicit freshness timestamps so the system always knows how old the data is. This unified status object becomes the single source of truth the rest of the pipeline depends on, and it's worth taking three to four weeks to get it right rather than rushing it and building on shaky ground.

Once the data layer is stable, an AI workflow platform takes over the reply generation and triage steps. A tool like n8n is a practical choice here: it's self-hostable, has good Python integration, and the automation engineer can learn it without abandoning their existing skills. Alternatively, a lightweight service built directly in Python using a hosted LLM API such as OpenAI or Anthropic, called via a simple request handler, keeps the entire stack in one language and under the team's direct control. Whichever platform is chosen, the logic is the same: the workflow receives an incoming customer enquiry, matches it to a unified status object, scores it against a set of routing rules, and either composes and sends an automated reply or packages the case for the human exception queue. The routing rules codify the decision points the team already uses intuitively: is the data current? Is this standard or an exception? Is there any bad-news flag, traceability field or data mismatch that needs a human eye before anything goes to the customer?

The exception queue is where the compliance control point lives, and it deserves careful design. When a case is routed to the queue, the handler sees the incoming enquiry, the assembled status data, the reason it was flagged, and a draft reply if one was generated. The handler can approve, edit or escalate further, and nothing leaves the system until a human has reviewed it. This queue can be implemented as a simple email triage inbox, a Slack channel with structured messages, or a lightweight web interface built in Python and hosted internally. The important thing is that the context travels with the case so the handler doesn't have to repeat the lookup work the system already did.

Before switching off the manual process, the team runs the automated system in parallel for two to four weeks, comparing what the automation sends against what a human would have sent for the same query. This parallel run surfaces misconfigured thresholds, data freshness edge cases and any carrier schemas that weren't fully mapped. A simple monitoring dashboard, which can be a Metabase or Grafana instance reading from a PostgreSQL log table written by the Python layer, shows the automation rate, exception rate, reply latency and any cases where the system flagged uncertainty. After the pilot, the parallel manual process for standard cases is decommissioned, shift supervisors and the plant manager are trained on the exception queue workflow, and the routing rules are documented so that when carrier schemas change or new product lines are added, the team can update the system themselves without external help.