Skip to main content

JD.com's 700,000-Robot Claim Makes Delivery Labor a Network Design Variable

ยท 7 min read
CXTMS Insights
Logistics Industry Analysis
JD.com's 700,000-Robot Claim Makes Delivery Labor a Network Design Variable

Delivery robotics is easy to discuss as a labor story. That is the loudest version of the topic, and this week it got louder.

Logistics Management reported that JD.com founder Richard Liu said robots will eventually replace the company's 700,000 delivery workers. According to the report, Liu made the comment during the APEC CEO Forum in Beijing and said replacement would happen "sooner or later" as automation advances. He also said JD.com is working with roughly 120 schools to retrain employees for robot maintenance and repair roles.

That is startling. But for logistics leaders, the more practical question is not whether every delivery worker disappears. It is what happens to the network when delivery labor stops being the default unit of capacity.

Robots do not simply make the same route cheaper. They change where depots should sit, which orders can be served locally, how far a delivery zone can stretch, when exceptions need human intervention, and how customer service promises should be written. Once automation enters the last mile at scale, labor planning becomes only one variable inside a broader delivery network design problem.

Robots Change the Shape of Densityโ€‹

Human delivery networks are built around routes, shifts, vehicle capacity, driver availability, and service territories. A robot network is built around density, range, charging cycles, payload limits, supervision ratios, curb access, geofencing, and recovery workflows.

That difference matters. A dense urban neighborhood with frequent small orders may be a strong robot candidate. A suburban zone with long driveways, low order frequency, poor sidewalk continuity, and heavier baskets may still belong to vans, couriers, or local carrier partners. A mixed zone may need both, with routing rules that assign each order to the delivery mode that can meet the promise at the right cost.

This is why the JD.com claim should not be read only as a workforce prediction. It is also a statement about network ambition. Replacing delivery labor with robots requires enough delivery density to keep assets utilized, enough depot coverage to keep range practical, and enough operational control to handle the exceptions that robots cannot resolve on their own.

The market is moving in that direction, but it is not evenly distributed. Mordor Intelligence estimates the autonomous delivery robots market at $1.33 billion in 2026, growing at a 19.74% CAGR to $3.27 billion by 2031. Its analysis says outdoor robots generated 57.20% of 2025 revenue, while units carrying up to 10 kg accounted for 46.10% of market size. Food delivery led with 42.10% revenue share in 2025, and retail and e-commerce logistics represented 48.60% of end-user share.

Those figures show where the operational fit is strongest today: small payloads, repeatable local trips, high-frequency demand, and dense networks. They also show the constraint. Most delivery networks still move a wide range of order sizes, service promises, address types, and exception profiles. A robot is not a universal last-mile answer. It is a delivery mode that needs rules.

Routing Is Only the Visible Layerโ€‹

Many companies will be tempted to treat delivery robots as a routing optimization project. That is too narrow.

Supply Chain Dive reported that AI adoption in routing and visibility is already above 70% among surveyed large retail and logistics executives, based on Bringg's 2026 Last-Mile Performance Outlook. The same article noted that 68% of executives plan more investment in routing and planning AI, even though weaker performance sits in less visible workflows like carrier management, billing reconciliation, and exception handling. It also reported that only about 14% plan increased investment in billing reconciliation and carrier management, while cost per delivery sits at only 36% overachievement.

That mismatch applies directly to delivery robotics. A robot fleet can improve route economics in the right operating zone, but routing software cannot fix poor depot placement, weak carrier allocation, bad order eligibility rules, manual exception recovery, or unclear customer communication.

For example, a robot may be assigned to a short delivery that looks efficient on a map. But if the order contains an oversized item, requires proof of age, needs apartment access, or has a tight delivery window during a weather disruption, the operational answer changes. The route engine needs eligibility rules before it optimizes the route.

The same is true for labor substitution. If robots handle a meaningful share of small local deliveries, human work does not disappear cleanly. It shifts into supervision, maintenance, remote intervention, customer-service recovery, charging and staging, depot operations, and exception delivery. Liu's comment about working with roughly 120 schools to retrain workers for robot maintenance and repair points to that transition. The labor model changes from route execution to network support.

The New Control Pointsโ€‹

Delivery robotics creates several control points that transportation leaders should design before deployment.

First, define mode eligibility. Orders should be assigned to robot, courier, van, parcel carrier, or other delivery modes based on dimensions, weight, distance, service window, customer requirements, geography, weather, access conditions, and cost-to-serve. If those rules are informal, robot adoption becomes a pilot program rather than an operating capability.

Second, design depot density deliberately. Robots need launch points close enough to demand to protect utilization and battery life. That can change the role of stores, micro-fulfillment sites, urban depots, partner locations, and parcel lockers. The question is not "Can the robot complete the trip?" It is "Can the network repeat this profitably at volume?"

Third, build exception playbooks. A blocked sidewalk, failed handoff, customer no-show, mechanical fault, damaged parcel, temperature-sensitive delay, or security concern needs a clear recovery path. Some exceptions need remote support. Others need human field recovery or mode reassignment. The system should know the next action before the customer asks.

Fourth, monitor service performance by mode. Robot delivery should be measured against cost per delivery, successful first-attempt handoff, customer satisfaction, intervention rate, recovery time, utilization, dwell time, and complaint patterns. A low-cost delivery mode that creates high service noise may not be cheap in the full operating model.

Finally, connect robotics decisions to carrier mix. Robots will not replace every partner. They will change which partners are needed, where they are needed, and what volume they receive. Carrier allocation, route density, local courier use, and owned-fleet planning all need to respond together.

CXTMS and the Robot-Ready Last Mileโ€‹

The lesson from JD.com's 700,000-worker claim is not that every logistics network should race to replace delivery staff. It is that last-mile capacity is becoming more modular. Robots, couriers, parcel carriers, vans, lockers, and store pickup will all compete for the same order pool, and the winner should be determined by service promise, operating constraints, and real cost.

CXTMS helps logistics teams manage that complexity by connecting delivery-mode rules, carrier allocation, route exceptions, service milestones, and performance monitoring in one execution layer. When automation becomes part of the network, the TMS has to do more than track a shipment. It has to decide which delivery mode fits, watch the exception path, and preserve the audit trail behind every service commitment.

If your last-mile operation is evaluating delivery robotics, start with the network design question before the labor-replacement headline. Request a CXTMS demo to see how CXTMS helps teams orchestrate multi-mode delivery networks with better rules, cleaner exceptions, and stronger service control.