Rules-based order routing replaces the team member who manually decides which warehouse ships each order. The math gets interesting at 200 orders a day.
By Mohammad Jamnagarwala · Simply Five Studio
A distributor of industrial spares running three warehouses across Mumbai, Pune, and Ahmedabad had a team member whose entire job, from 9 AM to 6 PM, was deciding which warehouse should ship each incoming order. Her name was on every order's routing note. She knew the stock position in each warehouse, the freight rates by destination, the dealer territories, the customer preferences from history, and the live picking load at each location. She was excellent.
She was also the bottleneck. When she took leave for a week in late 2023, orders stacked up. When the firm tried to grow from 140 to 220 orders per day, her capacity capped the operation. The founder considered hiring a second person. The founder considered building rules. The founder ended up commissioning a routing engine that encoded what she did in her head, freed her to handle exceptions, and unlocked the next stage of growth.
This essay is about what rules-based order routing actually involves, why most distributors are still doing it manually, and what changes at 200 orders a day.
Most Indian distributors with two or more warehouses route orders manually. The pattern is uniform. An order arrives. A team member opens the order, checks stock across warehouses, considers freight cost to the destination, weighs the dealer's territory or preference, and assigns the warehouse. They write the warehouse code on the order note. The order moves to picking.
The decision takes between 20 seconds and 2 minutes per order, depending on complexity. At 80 orders a day, the team member spends one to two hours doing nothing but routing. At 200 orders a day, the same work fills four to five hours, which means a dedicated person, which means a salary line item that scales with volume.
The decision is also dependent on tacit knowledge. The team member knows that the Ahmedabad warehouse runs short on a particular SKU in the last week of the month. They know that the Bangalore dealer prefers shipments from Pune because the transit time matches their schedule. They know that the freight saver above a certain order value tips the decision toward a different warehouse. The knowledge is real and valuable. It is also locked inside one person.
When that person is unavailable, the routing degrades. When the firm grows, the routing capacity caps.
A routing engine is a structured representation of the decisions the team member is already making. The engine carries explicit rules and evaluates them in defined priority order for each incoming order.
The first rule is usually stock availability. If only one warehouse has the SKU in the required quantity, the order routes there. No further evaluation is needed.
The second rule is dealer territory. Some distributors operate dealer territories that map to specific warehouses. A Pune dealer ships from the Pune warehouse, by policy. The rule encodes the policy.
The third rule is freight cost. When two or more warehouses can fulfil the order, the engine evaluates freight to the destination and selects the lower-cost option, subject to a freight saver threshold.
The fourth rule is customer preference. Specific customers have specific shipping points they prefer, sometimes for transit-time reasons, sometimes for warehouse-relationship reasons. The customer master holds the preference. The engine honours it when stock is available.
The fifth rule is load balancing. If two warehouses can fulfil at the same cost, the engine prefers the one with lower current picking load. This prevents one warehouse from being overwhelmed while the other sits idle.
The sixth rule is exception escalation. If no rule produces a clean answer (stock split across warehouses, freight tied, preferences conflicting), the order routes to a human review queue. The team member handles only the exceptions, not every order.
At 200 orders per day, the difference between manual and rules-based routing produces concrete numbers.
Manual routing at 2 minutes per order on average is 400 minutes per day, which is 6.7 hours, which is a dedicated team member. The cost is roughly 30,000 to 50,000 rupees per month including overheads. Annualised, between 4 and 6 lakh rupees.
Rules-based routing handles 85 to 92 percent of orders automatically in milliseconds. The remaining 8 to 15 percent (15 to 30 orders per day) route to an exception queue and take 2 to 4 minutes of human attention each. The team time required drops from a dedicated person to one to two hours per day, which can be absorbed by an existing team member without a new hire.
The direct saving is 3 to 5 lakh rupees a year in payroll. The indirect saving is the lifting of the routing capacity ceiling. Growth from 200 to 400 orders per day no longer requires hiring a second router. The engine handles the volume linearly.
The additional benefit is decision consistency. Manual routing decisions vary by team member, by time of day, and by mood. Rules-based routing produces the same answer for the same inputs, every time. The downstream effects on customer experience, warehouse load, and freight spend are measurable.
The technical work is not the hardest part. Encoding a routing engine that evaluates five to seven rules in priority order is a few weeks of development for a competent team.
The harder part is articulating the rules. The team member who has been routing manually for three years cannot always articulate why she chose a particular warehouse for a particular order. The choice involved tacit pattern-matching that the routing engine has to make explicit. The work of extracting those rules is a series of conversations with the routing team, often spread over four to eight weeks, while the engineering happens in parallel.
The third part is integration with the rest of the operation. The routing engine has to read live stock from the warehouse management system, the freight rates from the logistics partner integration, the customer preferences from the dealer master, and the territory map from the operations setup. We have written about this integration discipline in our pieces on multi-warehouse inventory sync and WooCommerce plus a custom ERP. The engine cannot route well if its inputs are not reliable.
The architecture we built for AKSD handles routing as part of the unified order queue. Orders from WooCommerce, phone, and WhatsApp land in the same queue. The engine evaluates routing rules at the moment of order acceptance. The team works exceptions. The same routing pattern, simpler in form because the operation has a single physical location, sits inside Car Seat Wala's ERP.
The visible change is at the operational level. Orders move faster. The routing team's capacity expands. The growth ceiling lifts.
The deeper change is at the decision level. The routing engine produces a structured record of every routing decision, including the rule that fired and the alternatives that were considered. The founder can analyse routing patterns over time. Which warehouse is being chosen most often. Where freight cost is driving routing away from the natural choice. Which customer preferences are creating cost. The data supports decisions about warehouse capacity, freight contracts, and territory adjustments.
A team member doing routing manually produces no data. A routing engine produces a complete audit trail. The audit trail becomes part of the firm's internal systems decision layer.
A founder running distribution at three or more warehouses should ask two questions of the current operation. First, what would happen if the team member who does routing took a month off. Second, how would the firm route 50 percent more orders next year without hiring a second router. If either question produces an uncomfortable answer, the routing engine is the next investment.
The work of encoding the routing rules is also the work of making the firm's logistics intelligence durable. The knowledge moves from one person's head into the operational system. The system continues to serve as the team changes. This is what decision infrastructure looks like at the warehouse layer.
Generic school management software does not understand voluntary contributions, WhatsApp as the parent channel, or the relationship between a tahfeez and its community. A fitted system does.
A premium ceramic and sanitaryware showroom does not sell the way retail sells. The software that runs the floor has to follow walk-ins, designers, and vendor POs as one continuous journey, or it stays in the way.
Indian print-on-demand is artwork-heavy. The operational backbone for a 20 to 100 order-per-day shop covers capture, approval, production scheduling, and dispatch.
The contact form takes about two minutes. The reply comes from the founder within two working days.
