A logistics company in Bangladesh needed a WhatsApp bot that could quote shipping prices instantly. Sounds simple—just calculate weight × distance × rate, right? Wrong.
Their pricing was incredibly complex.
Base calculation included weight with 0.5kg increments, distance city-to-city with zone variations, and service type options like Express, Standard, and Economy.
Then came the complications. Conditional multipliers applied for fragile items at +20%, hazardous materials at +35%, oversized packages at +40%, and temperature controlled shipments at +50%. Time-based variations added peak season surcharges during Eid or holidays at +25%, weekend delivery at +15%, and same-day service at +60%. Volume discounts reduced pricing for 5-10 shipments per month by -8%, 11-25 shipments by -15%, and 26+ shipments by -22%. Location surcharges increased pricing for remote areas by +30%, island delivery by +45%, and hill tract regions by +25%. Promotional offers included first-time customer discounts at -10%, corporate account discounts at -12%, and referral codes with variable discounts.
Their existing manual process was painful. The sales team used Excel sheets with 15+ tabs, took 5-10 minutes per quote, and frequently made calculation errors. Customer expectation was instant quoting on WhatsApp. The challenge was building a bot that handled all this complexity without errors, in under 3 seconds.
Why This Was Incredibly Complex
Here’s what a real quote request looked like.
A user asked, “How much to send 7.5kg from Dhaka to Chittagong, express delivery, fragile item, need it tomorrow (Saturday), I'm a new customer with referral code SAVE15?”
That single message created a stack of variables. The base price required weight, Dhaka-Chittagong distance, and express rate. Then fragile added +20%, weekend added +15%, new customer subtracted -10%, and referral SAVE15 subtracted -15%. But we also needed business rules: does referral stack with new customer discounts? Operational constraints: is tomorrow actually possible for express? Location checks: is Chittagong city center or a remote area with surcharges?
A single quote required navigating 8-12 conditional logic branches with business rules that sometimes conflict.
Failed Approaches: What Didn’t Work
Attempt one was a simple calculation prompt: “Calculate shipping cost based on user input.” The bot couldn’t handle multiple modifiers. A user said, “7kg, Dhaka to Cox’s Bazar, fragile,” and the bot calculated the base price only. It ignored the fragile modifier and ignored that Cox’s Bazar can require remote area surcharge. Accuracy landed around 40%.
Attempt two was a hardcoded formula approach. We wrote explicit formulas like Base × 1.2 for fragile × 1.3 for remote × 0.9 for discount. It worked for simple cases, then broke on edge cases. What if the user qualifies for multiple discounts but policy says maximum one discount applies? What if promotional discount conflicts with volume discount? The formula ballooned into 200+ lines of nested IF statements and became unmaintainable.
Attempt three was a decision tree approach. We built a massive flowchart of conditional paths: “If fragile and express then… If remote and weekend then…” The decision tree reached 400+ nodes. The bot got lost in the complexity, response time jumped to 8-12 seconds, and the error rate still sat around 25% due to edge cases we didn’t anticipate.
The Breakthrough: Structured Calculation Engine
We realized the bot needed to think like a pricing analyst, not like a calculator.
We built a five-stage calculation system.
Stage 1 was information extraction. The system parsed the user message to identify all relevant variables. For example, if a user said, “7kg Dhaka to Sylhet express fragile weekend delivery corporate account,” we extracted weight as 7kg, origin as Dhaka, destination as Sylhet, service as Express, modifiers as fragile and weekend, and customer type as corporate.
Stage 2 was the base calculation. We calculated the foundation price without modifiers. Using an example structure, weight was 7kg, distance zone for Dhaka-Sylhet was Zone 2 at 80 km, service was Express at ₹18 per kg, and base cost became 7 × 18 = ₹126.
Stage 3 was modifier application in a strict priority order to avoid conflicts. Priority one was item type modifiers, so fragile made ₹126 × 1.20 = ₹151.20. Priority two was location modifiers, and if Sylhet had no remote surcharge, it remained ₹151.20. Priority three was time modifiers, and weekend delivery made ₹151.20 × 1.15 = ₹173.88.
Stage 4 was discount resolution. We applied business rules for discount conflicts. If available discounts included corporate at -12% and volume discounts depending on shipment history, the business rule was “only highest discount applies.” So we applied corporate at -12%, making ₹173.88 × 0.88 = ₹153.01.
Stage 5 was edge case validation. We checked for business logic violations. Weight within service limits, destination serviceable, weekend delivery available, fragile allowed in that service type, and other constraints. If all passed, the quote was approved.
The Technical Implementation
We implemented this using structured prompting with explicit calculation stages.
The system instruction defined a calculation protocol executed in order.
First, extract variables: weight in kg rounded to nearest 0.5kg, origin city, destination city, service type as Express, Standard, or Economy, item modifiers like fragile, hazardous, oversized, temperature controlled, time modifiers like weekend, same day, peak season, customer type as new, regular, or corporate, and discount codes if mentioned.
Second, do base calculation as weight × distance zone rate × service multiplier. We used a rate table: Express at ₹18 per kg, Standard at ₹12 per kg, Economy at ₹8 per kg. Distance zones applied multipliers: Zone 1 at 0-50km used base rate, Zone 2 at 51-150km used base rate × 1.2, Zone 3 at 151-300km used base rate × 1.5, and Zone 4 at 300+ km used base rate × 2.0.
Third, apply modifiers in priority order. Item type modifiers: fragile +20%, hazardous +35%, oversized +40%, temperature controlled +50%. Location modifiers: remote area +30%, island +45%, hill tract +25%. Time modifiers: weekend +15%, same day +60%, peak season +25%.
Fourth, resolve discounts with the rule that only the highest discount applies. New customer -10%, corporate -12%, volume 5-10 -8%, volume 11-25 -15%, volume 26+ -22%, promotional codes variable. The business rule enforced maximum one discount.
Fifth, validate constraints: Express max weight 30kg, Economy max weight 50kg, hazardous not allowed in Express, temperature controlled only in Express, weekend delivery only in Express and Standard. If validation failed, the bot informed the user of the constraint.
We also defined a clear output format showing the base, applied modifiers, applied discount, the total, an estimated delivery window, and quote validity.
Real Example Walkthrough
A user asked, “How much for 12kg from Dhaka to Rangpur, standard delivery, it's electronics so fragile, I have corporate account, need it delivered on Sunday?”
Stage 1 extracted weight 12kg, origin Dhaka, destination Rangpur, service Standard, modifiers fragile and weekend, customer corporate.
Stage 2 base calculation was 12kg × Zone 3 × Standard ₹12/kg. With Zone 3 multiplier at 1.5, that became 12 × 1.5 × 12 = ₹216.
Stage 3 applied modifiers. Fragile made ₹216 × 1.20 = ₹259.20. Weekend made ₹259.20 × 1.15 = ₹298.08.
Stage 4 applied discount. Corporate -12% made ₹298.08 × 0.88 = ₹262.31.
Stage 5 validation passed because weight was within limits, destination serviceable, weekend delivery allowed for Standard, and fragile allowed.
The bot output showed the full breakdown and asked the user to reply “CONFIRM” to book the shipment.
Edge Cases We Had to Handle
Conflicting discounts came up constantly. If someone said, “I'm a new customer with corporate account and referral code SAVE15,” the discounts were -10%, -12%, and -15%. The system applied the highest discount only, which was SAVE15, and clearly told the user other discounts weren’t stackable.
Invalid service combinations were another major issue. If a user requested hazardous material via Express, the system explained hazardous isn’t allowed in Express and offered Standard or Economy alternatives.
Weight rounding ambiguity was common. For 7.3kg, the system rounded to 7.5kg and explained the policy while noting pickup verification.
Promotional code validation mattered. If a code was expired, the bot informed the user and offered current promotions.
Same-day cutoff times required operational logic. If the request came after cutoff, the bot offered the next best service option instead of generating a misleading quote.
The Results
Before the dynamic pricing bot, quote time was 5-10 minutes. Calculation errors were 18-22% of quotes. Lost customers due to wait time were 34%. The sales team manually handled 200-250 quotes per day, and after-hours quoting wasn’t possible.
After the bot, average quote time was 2.8 seconds. Calculation errors dropped below 1% and were mostly edge cases. Lost customers dropped to 8%, unrelated to pricing. The sales team handled exceptions only, about 15 per day. After-hours quotes became fully automated.
Business impact was immediate. Quote capacity went from 250 per day to unlimited. Sales productivity improved 15x as they focused on conversions instead of calculations. Customer satisfaction improved from 3.2 out of 5 to 4.7 out of 5. After-hours revenue grew from zero to $12,000 per month. Pricing disputes dropped by 95%. Average response time went from 8 minutes to 3 seconds.
Revenue impact followed. Quotes per day increased from 250 to 800+. Conversion rate increased from 28% to 41% because faster quotes increased intent capture. Monthly revenue increased by $47,000. Customer retention rose by 23% due to trust in accurate pricing.
Technical Insights: What We Learned
Order of operations matters. Applying modifiers before discounts versus after produces different results, so the sequence had to be explicit.
Business rules must be encoded clearly. “Only one discount applies” feels obvious to humans, but AI needs exact rules.
Validation prevents bad quotes. Checking constraints before finalizing prevents promising impossible deliveries.
Transparency builds trust. Showing the breakdown makes customers trust the pricing.
Edge cases are most of the work. The first 20% was base calculation, and the remaining effort was conflict resolution, constraints, and exceptions.
Implementation Tips for Dynamic Pricing Systems
Define calculation stages explicitly and don’t let AI guess the order. Create business rule documentation for every pricing rule, discount policy, and constraint. Build validation layers for impossible combinations before quoting. Show your work so users can verify logic. Test edge cases obsessively.
The Core Lesson
Dynamic pricing isn’t about complex math. It’s about handling complexity with consistent logic.
Our system calculates hundreds of quotes daily, each potentially involving 10+ variables and 5+ conditional rules, with 99%+ accuracy. The key wasn’t building a smarter AI. It was building structured logic with explicit priorities, validation checks, and clear business rules.
Complexity managed through structure beats intelligence without structure.
Your Turn
Are you building pricing systems with multiple variables? How do you handle discount conflicts and edge cases in your automation? What challenges have you faced with conditional logic in AI applications?
Written by Faraz Farhan
Senior Prompt Engineer and Team Lead at PowerInAI
Building AI automation solutions that handle real-world complexity
Tags: dynamicpricing, aiautomation, chatbot, logistics, promptengineering, businesslogic
Top comments (0)