An insurance company in Bangladesh needed a chatbot to help customers file claims. Sounds straightforward: collect claim details, submit request, done. But their actual claim process was a maze of conditional logic.
The business rules looked like this: “If claim type is Health and amount is over ৳50,000 then require medical reports. But if the customer has a premium policy then waive the medical report requirement, unless the claim is for a pre-existing condition, then always require medical reports. However, if customer age is over 60 then require reports regardless of policy type, except if the claim is emergency hospitalization then fast-track approval, but if the emergency claim is over ৳200,000 then still require hospital verification. And if the claim is submitted within 24 hours of the incident then expedite, unless the incident happened on a weekend then add 1 business day. Wait, if the customer has filed 3+ claims in 6 months then flag for review, but premium customers get 5 claims before review. Oh, and if claim type is Accident then different rules apply…”
The flowchart had 47 decision points. The chatbot had to navigate this without errors, without frustrating users, and without creating compliance issues.
Why This Was Insanely Complex
Let’s walk through a real scenario.
A user says, “I need to file a health insurance claim for ৳75,000.” The bot now has to determine claim type as health and confirm the amount is above the ৳50,000 threshold, which means medical reports are required. Then it has to check the customer’s policy type and query the database to find they’re on a premium policy. Premium policy would normally waive medical reports, so the bot temporarily flips the requirement to not required.
But then it has to check pre-existing condition status. It asks, “Is this for a pre-existing medical condition?” The user says, “Yes, diabetes treatment.” That activates a rule that always requires medical reports, overriding the premium waiver.
Then it checks age in the database and finds the customer is 62. Age over 60 requires medical reports regardless of policy type, which further confirms the requirement.
Next it checks whether this was an emergency hospitalization. The user says yes, admitted last night. Emergency triggers fast-track approval. Then the bot checks emergency claim amount against the ৳200,000 threshold and sees ৳75,000 is under it, so hospital verification is not required.
Then the bot checks time since incident and calculates it was under 24 hours, so expedite applies. But it also checks day of incident and discovers it happened on Sunday, a weekend, which adds 1 business day.
Finally, it checks claim history and finds two claims in the last six months. Premium customers get five claims before review, so no review flag is triggered.
The correct outcome is: medical reports required due to pre-existing condition and age, fast-track processing due to emergency and under 24 hours, timeline adjusted because of weekend, no hospital verification required because it’s under ৳200,000, and no review flag because it’s under the claim limit. One wrong decision would create a compliance violation or an angry customer.
Failed Approaches: What Didn’t Work
The first attempt was a linear question flow. The bot asked questions in a fixed order like claim type, amount, and premium policy status. In the example case, it concluded “no medical reports needed,” which was wrong because it didn’t check age or pre-existing condition. Linear flows can’t handle conditional branching. Accuracy was around 40%.
The second attempt was nested if-then prompts. We tried to encode the entire logic in one giant prompt like, “If health then if amount > 50k then if premium then if age > 60 then if pre-existing…” The prompt grew beyond 2,500 words. The AI got lost in the nesting, skipped conditions, or applied wrong rules. Accuracy improved slightly to 55%, but it still failed frequently.
The third attempt was a decision tree with 47 nodes. We mapped every possible path. It became a maintenance nightmare with 89 possible paths. The bot still took wrong turns, and debugging was nearly impossible because you couldn’t easily identify which node failed. Accuracy reached 62%, but reliability was nowhere near acceptable.
The Breakthrough: Modular Conditional Logic System
We realized the bot couldn’t process all conditions simultaneously. It needed to think step-by-step, like a real claims processor.
We built a five-stage evaluation system.
Stage 1 was information collection with no logic applied. We collected all required information first: claim type, amount, policy type, customer age, pre-existing condition status, emergency status, incident date and time, time since incident, and claim history.
Stage 2 was base rule application with no overrides. We applied fundamental rules such as health claims over ৳50,000 requiring medical reports, age over 60 requiring medical reports, emergency enabling fast-track, submissions within 24 hours enabling expedite, and amounts under ৳200,000 not needing hospital verification.
Stage 3 handled overrides and exceptions in a strict priority order. We applied premium policy waivers first, then checked whether pre-existing conditions override those waivers, then verified age-based exceptions that override policy benefits.
Stage 4 applied modifiers like fast-track timelines, weekend adjustments, and review flags based on claim history thresholds that differ by policy tier.
Stage 5 performed final validation and output. We cross-checked conflicts, ensured the priority rules were respected, and generated a clean, consistent answer.
The Technical Implementation
We implemented this using a structured evaluation protocol.
The system instruction forced strict sequential execution. Stage 1 required complete data collection before Stage 2 could run. Stage 2 applied base rules for each claim type. Stage 3 applied overrides and exceptions using a priority hierarchy, where absolute rules like pre-existing condition requirements cannot be waived. Stage 4 applied timeline and review modifiers. Stage 5 validated conflicts, used the longest timeline if multiple modifiers applied, and ensured review requirements override fast-track when needed.
The output format was designed to be clear: claim details, required documents with reasons, processing timeline and status, next steps, and important notes.
Real Example Walkthrough
In a typical conversation, the bot first gathered missing details. It asked the user for amount, emergency status, and whether the treatment was for a pre-existing condition. Meanwhile, it pulled policy tier, age, and claim history from the database.
Internally, it processed the stages. Base rules marked medical reports as required because the amount was above ৳50,000 and the customer was over 60. Overrides confirmed medical reports were absolutely required because of the pre-existing condition, regardless of premium waivers. Modifiers applied emergency fast-track and then added a weekend adjustment. Review logic checked the claim limit and did not flag review. Validation confirmed there were no conflicts.
The final response gave a clear breakdown: medical reports required due to pre-existing condition and age, fast-track processing due to emergency, timeline adjusted due to weekend, no hospital verification needed because it was below ৳200,000, and no review flag because claims were within premium limits. It then guided the user to upload specific documents like discharge summary, medical reports, and itemized bill.
Edge Cases We Had to Handle
We handled conflicting rules like premium waivers versus age requirements by enforcing priority. We handled multiple modifiers stacking together, such as emergency plus weekend plus public holiday. We clarified claim limit boundaries like whether “5+ claims” includes exactly five. We handled borderline amounts like ৳50,001 being strictly above the threshold. We also handled missing data, where the bot could not proceed until it confirmed whether the claim was related to a pre-existing condition, because that single answer changes the required documentation.
The Results
Before the modular logic system, claim assessment accuracy was 62%. Incorrect requirements were given in 38% of cases. Compliance issues occurred 12–15 times per month. Customer complaints about wrong information were common. Manual review was required for 70% of claims, and average processing time was 6–8 days.
After implementing the staged system, claim assessment accuracy reached 97%. Incorrect requirements dropped to 3%, mostly edge cases. Compliance issues fell to 1–2 per month and were mostly unrelated to the bot. Customer complaints became rare. Manual review dropped to 25% and focused on truly complex cases. Average processing time improved to 3–4 days.
The business impact was clear. Accuracy improved significantly, manual review was reduced, processing became faster, customer satisfaction rose, compliance violations dropped sharply, and customer service workload decreased. The system also reduced escalation volume and avoided compliance-related costs.
Technical Insights: What We Learned
Sequential processing beats simultaneous evaluation. Trying to evaluate everything at once creates confusion. Staging ensures nothing is missed.
Priority order is critical. When rules conflict, you must define which wins.
Data collection must come before logic. If Stage 1 is incomplete, Stage 2 will produce incorrect outputs.
Validation catches contradictions. A final cross-check prevents the bot from saying two conflicting things.
Modifiers should be explicitly additive. Weekend and holiday adjustments need clear stacking logic.
Implementation Tips for Complex Conditional Logic
Document every rule first and define a priority hierarchy. Use stage-based processing: collect, apply base rules, apply overrides, apply modifiers, then validate. Define priorities explicitly so conflicts are predictable. Test edge cases obsessively, including boundary values. Log every decision so you can debug exactly which rule fired.
The Core Lesson
Complex conditional logic isn’t about smart AI. It’s about structured decision-making.
Our system handled 47 decision points, nested overrides, conflicting rules, and edge cases with high accuracy because we broke complexity into sequential stages and enforced explicit priority rules. When AI is guided to collect all data first, apply base rules, check overrides in order, apply modifiers, and validate, it can handle real-world complexity without errors.
Your Turn
Are you building systems with complex conditional workflows? How do you handle rule conflicts and overrides in your automation? What’s the most complex decision tree you’ve had to implement in conversational AI?
Written by Faraz Farhan
Senior Prompt Engineer and Team Lead at PowerInAI
Building AI automation solutions that handle real-world complexity with precision
Tags: conditionallogic, workflow automation, conversationalai, businessrules, promptengineering, processautomation
Top comments (0)