Types of Decision-Making in Business: 2026 Framework

Why decision-making type matters before you pick a tool

In my last three BRMS evaluations with mid-market P&C carriers, the conversation always started the same way: "We want to automate our decisions." Two months in, we would find the carrier had bundled three different problems into one project - a strategic product-launch decision that needed executive judgment, a tactical pricing-policy change that needed analytics support, and 14 000 operational underwriting decisions that needed to fire in under 200 milliseconds.

Each of those problems wanted a different tool. The strategic one wanted a structured decision meeting and a market analysis. The tactical one wanted a quarterly review backed by loss-ratio data. The operational one wanted a rules engine - and that's where Higson typically enters the picture.

Mixing the three is the most expensive mistake I see in insurance technology projects. Treat a strategic decision like an operational one and you'll automate a bet you should have debated. Treat an operational decision like a strategic one and your customers wait 11 days for a quote that should have taken 11 seconds.

This guide separates the 6 types of decision-making most relevant to insurance and finance - strategic, tactical, operational, programmed, non-programmed, and data-driven - and shows which ones a business rules engine can automate, which ones it can support, and which ones it should not touch at all.

I have written it the way I would brief a new architect joining the Higson team. We'll keep the management-theory framing brief (you already know McKinsey models exist) and spend most of the page on what the categories actually look like inside a $500M-$5B GWP carrier's quote-to-bind, claims-FNOL, and product-launch processes.

If you're reading this because somebody asked you to "automate decisions" and you're not sure where to start - start by sorting the decisions, not the technology.

The 6 types of decision-making in business (direct answer)

Business decision-making falls into six types:

• ‍strategic (long-horizon, executive, e.g. entering a new state),
• ‍tactical (medium-horizon, departmental, e.g. quarterly pricing change),
• ‍operational (daily, repetitive, e.g. underwriting approve/refer),
• ‍programmed (rule-based, automatable),
• ‍non-programmed (novel, judgment-based), and data-driven (analytics-supported).

Operational and programmed decisions are the natural fit for a business rules engine like Higson.

Strategic decision-making: long-term direction

What strategic decisions look like

Strategic decisions set direction for 3-10 years. In insurance, that's product-line expansion, state entry, distribution-channel rebuild, M&A, reinsurance treaty restructuring, core-system replacement. They sit with the C-suite - CEO, CFO, CRO, CUO, CMO - and they touch capital allocation, regulatory posture, and competitive positioning.

The signal I look for: the decision can be wrong without being unrecoverable, but reversing it costs 18-36 months and $5M-$50M.

Insurance examples I have seen up close

A regional Allianz unit I worked with spent 11 months deciding whether to underwrite cyber for SMB commercial. That's a strategic decision. Wrong product-market fit means three years of bad loss experience and capital tied up in reserves.

A mid-market commercial carrier deciding to exit New York personal auto - strategic. The exit is regulatory, operational, and reputational all at once.

A CTO deciding to replace a 14-year-old policy administration system - strategic, with capital implications well past the IT budget.

Why a rules engine is not the answer here

In my experience, executives reach for tools that pretend to "model" strategic decisions and end up with weighted-average scoring sheets that hide the real conversation. A business rules engine has nothing useful to say about whether you should enter New Jersey. What Higson and similar tools do help with is the operational decisions downstream of the strategic one - once you have decided to enter the market, you need 4 000 underwriting rules, 12 rate tables, and a claims-eligibility flow. That's where the rules engine carries weight.

A common Daniel-the-architect concern: "But our CFO wants AI-driven strategic recommendations." Push back gently. NAIC's 2024 Model Bulletin on AI Use in Insurance is explicit - high-impact decisions with consumer-facing effects need audit trails and human oversight. Strategic AI-recommendation systems are not the place to start.

Tactical decision-making: implementing strategy

Tactical decisions sit in the middle

Tactical decisions translate the strategic intent into a 3-12 month plan. They're owned by VPs, department heads, line-of-business leaders. In a mid-market P&C carrier, that means the VP Underwriting setting next quarter's appetite, the VP Claims approving a new ECM vendor, the Head of Product launching a pricing tier.

Tactical decisions need data, but they also need context - they are rarely made the same way twice. Mid-management knows the business; the data informs them, it does not replace them.

Insurance examples

• The VP Underwriting deciding to relax minimum credit-score thresholds in three states to chase market share for two quarters.

• The Head of Product launching a "renters-with-roommate" pricing tier in California.

• The COO restructuring the claims team after a 14% growth quarter.

• The Chief Distribution Officer changing commission curves for independent agents to push retention.

The rules engine as tactical support, not tactical owner

Higson supports tactical decisions in two ways. First, it gives executives current data - "what's our denial rate by state, by product, this quarter?" - without waiting for IT. Second, once a tactical decision is made, the rules engine deploys it: a quarterly appetite change becomes 30 rule updates in 48 hours instead of a release-train backlog.

I recommend keeping a clean line: the rules engine executes tactical decisions; it does not make them. Confusing these creates an automation black box that no underwriter or actuary can defend in front of a regulator.

Operational decision-making: daily execution

Where the volume lives

Operational decisions happen thousands of times per day. Approve the quote, refer it, decline it. Auto-pay the claim under $2 500, route the rest to an adjuster. Adjust the commission for a third-party producer. Re-rate a renewal where the vehicle changed.

A mid-market P&C carrier I have worked with handles 80,000-120,000 operational decisions per day across quoting, binding, endorsing, claims FNOL, claims payment, and producer compensation.

These are the decisions a business rules engine was built for. They are repetitive, well-structured, well-documented, and high-volume.

What operational decisions need from the engine

In my experience working with mid-market P&C carriers, four characteristics separate a real operational-decision platform from a generic rule library:

• Speed. Sub-second is table stakes for real-time quoting. Higson's typical execution sits at 0.23 ms with 9 000 sustained requests per second - well above mid-market peak load.

• Audit trail. Every decision needs a "who, what, when, why" record. NAIC's Insurance Data Security Model Law and state DOI examinations both require it.

• Versioning. Yesterday's rules need to be reproducible for next year's audit.

• Business-user editing. When the rule says "refer if credit < 620 in Texas" and Texas regulators change the threshold, a business analyst should be able to update it without a developer release.

This is the Linda persona - the BA who owns the rule library. In Higson Studio, Linda edits decision tables visually, runs UAT against historical quote data, and deploys to production without involving Daniel's engineering team. In my experience, this is the single biggest accelerator for operational decision speed.

Insurance examples

• Underwriting: approve / refer / decline based on 40-60 rules covering credit, prior claims, vehicle, driver, location.

• Pricing: apply territory factors, multi-policy discounts, telematics adjustments.

• Claims: straight-through payment for low-severity, low-complexity claims (typical mid-market STP rate 35-55%).

• Compliance: apply NAIC Model Bulletin AI documentation requirements automatically.

• Producer compensation: calculate commissions across hierarchies, overrides, and bonuses.

Programmed vs non-programmed decisions

Programmed decisions

A programmed decision has a known structure, repeats often, and can be expressed as a rule. Herbert Simon coined the distinction in the 1960s, and it remains the cleanest way to decide what belongs in a rules engine.

Examples:

• Loan eligibility based on credit score, DTI, and employment history.

• Auto-renewal of policies meeting standard criteria.

• Commission calculation for a producer hierarchy.

• Flag-for-review on suspicious claims (basic fraud heuristics).

Programmed decisions belong in Higson, Drools, FICO Blaze, InRule, or - for low-volume cases - a well-documented spreadsheet.

Non-programmed decisions

A non-programmed decision is novel, ambiguous, or judgment-laden. There is no rule because the situation has not repeated enough to extract one - or because the stakes warrant human judgment regardless.

Examples:

• Setting reserves on a complex commercial claim with multiple coverage triggers.

• Deciding whether to defend or settle a third-party liability claim with reputational risk.

• Underwriting a cyber risk for a first-of-its-kind exposure.

• Responding to a regulator's market-conduct inquiry.

Non-programmed decisions need experts, frameworks, and time. A rules engine has nothing to add - and forcing one in creates the audit-trail liability without the decision quality.

The 80/20 split in mid-market carriers

In a typical mid-market P&C carrier, about 75-85% of daily decisions are programmed (operational). About 15-25% are non-programmed (referrals, exceptions, complex claims). The job of a modern BRMS isn't to push that to 100% automation - it's to free senior underwriters, claims professionals, and product managers from the 80% so they can spend their judgment on the 20% where it matters.

Data-driven decision-making

What "data-driven" actually means in 2026

The phrase gets abused. Most "data-driven" decisions are really data-supported, judgment-led. A true data-driven decision is one where the decision-maker has a quantified loss function, a measurable outcome, and the willingness to follow the data even when it contradicts intuition.

In insurance, data-driven decision-making shows up in:

• Pricing models built from loss-development triangles and actuarial credibility.

• Fraud-detection scoring combining rule-based heuristics and ML models.

• Reserve adequacy using stochastic simulation.

• Distribution analytics for producer performance.

The hybrid pattern Higson uses

The version I have watched work best is a hybrid: rule-based decisions provide the audit trail and regulatory guardrails; ML models (deployed via ONNX runtime inside the rules engine) provide the predictive signal where you have data and where the regulator allows it.

Higson supports ONNX runtime natively, so a fraud-scoring model trained in PyTorch can run inside the same decision flow as the deterministic rules. Decision: "If the ONNX fraud score is above 0.8 AND any of the 6 fraud-rule conditions are met, refer to SIU." That's a single decision, two information sources, one audit record.

Per NAIC's 2024 Model Bulletin on AI Use in Insurance, this hybrid pattern - rules as guardrails, ML for inference - gives you the explainability regulators expect while capturing the lift ML delivers.

I have worked with one US life insurer where the model-only fraud system was rejected by the CUO because adjusters couldn't explain why the system flagged specific claims. Adding a rule layer on top - "model score + at least one rule hit" - made the same system deployable.

How a BRMS supports each decision type (honest mapping)

This is the table I show to a Daniel-the-architect on his first PoC scoping call. The honesty matters: if a vendor tells you their BRMS handles strategic decision-making, they are either confused or pitching consulting hours.

Common mistakes in decision-making programs

Mistake 1: Automating before classifying

Teams pick a BRMS, then go looking for decisions to put in it. The result is a project that automates a non-programmed claim-handling decision (bad - needs adjuster judgment) and misses an obvious programmed underwriting decision because no one mapped them.

Fix: spend two weeks before vendor selection mapping decisions by type, frequency, and current owner.

Mistake 2: Treating analytics dashboards as decisions

A dashboard is not a decision. Loss ratio by state on a Tableau page is information. The decision happens when someone - VP Underwriting, in this case - picks an appetite change. Confusing the two is how mid-market carriers end up with 40 dashboards and three slow tactical decisions per quarter.

Mistake 3: Letting AI cross category boundaries without controls

ML models excel at programmed and data-driven decisions when you have data. Pushing them into non-programmed territory (claims judgment, complex underwriting) without an explicit hybrid pattern is where NAIC and state DOI examinations focus. Build the rule-layer guardrail before you deploy the model.

Mistake 4: Hard-coding operational decisions inside application code

In my experience, this is the most common pattern I see in mid-market carriers - roughly 70% of the assessments I run turn this up. Underwriting rules live in if-statements scattered across a policy administration system written in 2012 Java. Every change is a 4-month sprint. The fix is not to rewrite the system - it is to extract the decisions into a rules engine. Notus Finance went through this exercise with Drools, then with Higson; the migration took 4 months and reduced rule-change cycle from quarters to days.

Where Higson fits (and where it does not)

Where Higson fits

Higson is built for the operational and programmed decision tier in mid-market P&C insurance carriers ($500M-$5B GWP) and mid-market banking ($1B-$20B AUM). The product specs that matter for this tier:

• 0.23 ms typical rule execution (P50), <1.5 ms P99

• 9 000 sustained requests per second on standard cloud sizing

• No-code Higson Studio for business analysts to edit decision tables, expression rules, and rule flows

• ONNX runtime inside rules for hybrid AI / rules patterns

• MCP server with 50+ tools so AI agents (Claude Code, others) can read, test, and deploy rules through natural language

• CREST certified, SOC 2 Type II attestation

• AWS Marketplace at $0.63 / hour for proof-of-concept

Higson reference cases I can talk about freely:

• Notus Finance - migrated from Drools to Higson; 100 000 calculations in 8 seconds (vs 14 seconds in Drools); business users now update commission rules without IT.

• InterRisk (VIG Group) - Digital Sales Platform Transformation; Higson powers product configuration and underwriting decisions.

• Allianz - 20+ year Decerto partnership across distribution and product configuration.

• BNP Paribas Cardif - credit scoring and insurance product rules in one engine.

Where Higson does not fit (paradox of transparency)

I would rather lose a deal than win one badly. Three places where I tell prospects Higson is not the right choice:

• Enterprise scale beyond 50 000 sustained req/s. Higson handles 9 000 req/s comfortably; large national carriers with real-time mobile-commerce volume will hit our ceiling. At that scale, InRule or IBM ODM may fit better.

• BPMN workflow-centric needs. If your problem is mostly long-running workflows with human tasks (a 30-day commercial submission process with 8 hand-offs), Camunda is purpose-built for that. Higson focuses on the decision points inside such a flow, not the orchestration of the flow.

• .NET-only enterprise architectures with internal mandates. Higson is Java-native with REST API for cross-platform integration. If your enterprise architecture board mandates .NET-only with no REST tolerance, InRule (.NET-native) is a more natural fit.

How to map your decisions before picking a BRMS (practical framework)

The 6-step exercise I run with mid-market carriers before any vendor RFP - and in my experience, the carriers who skip even one of these steps are the same ones who stall in PoC at month 12:

1. List every recurring decision in the quote-to-bind and FNOL-to-payment flows. Aim for 80-200 entries.

2. Tag each one as strategic / tactical / operational / programmed / non-programmed / data-driven.

3. Score volume and current cycle time. A decision that fires 10 000×/day at 12 seconds is your fastest ROI candidate.

4. Identify the rule owner. If a Business Analyst already maintains the spec in Excel, the BRMS migration is a 2-week effort. If the rule is buried in legacy code with no documented owner, plan for archaeology.

5. Flag regulatory sensitivity. NAIC Model Bulletin AI Use, state DOI rate-filing rules, and Privacy Protections Model Act exposure all matter.

6. Bucket into PoC scope. Pick the top 5-10 programmed / operational decisions for an initial BRMS PoC. Hold the non-programmed ones for phase 2 - and consider that "phase 2" might be a different tool.

Carriers who run this exercise hit production with their BRMS in 3-6 months. Carriers who skip it are still in PoC at month 12.

‍

FAQ

What are the 6 main types of decision-making used in business?

The 6 standard types are strategic (long-term, executive), tactical (medium-term, departmental), operational (daily, repetitive), programmed (rule-based, automatable), non-programmed (novel, judgment-based), and data-driven (analytics-supported). Operational and programmed decisions are the natural fit for a business rules engine; strategic decisions are not.

What's the difference between strategic and operational decision-making?

Strategic decisions set direction over 3-10 years and are made by executives - entering a new state, acquiring a carrier, replacing a core system. Operational decisions execute the strategy daily at high volume - approving a quote, paying a claim, calculating a commission. Strategic decisions need judgment and context; operational decisions need speed, consistency, and an audit trail, which is where a BRMS like Higson contributes.

How do you classify a decision as programmed or non-programmed?

A decision is programmed when it repeats often, has clear input criteria, and can be expressed as a rule. It is non-programmed when it is novel, ambiguous, or stakes-dependent in a way that requires human judgment. In a mid-market P&C carrier, roughly 75-85% of daily decisions are programmed; the remainder need human input.

Can a business rules engine automate strategic decisions?

No - and any vendor claiming otherwise is overselling. Rules engines automate operational and programmed decisions where the logic is stable, the volume is high, and the audit trail matters. Strategic decisions involve novel context, multi-stakeholder input, and judgment calls that rule logic cannot capture. Higson's role in strategic decision-making is to execute the operational follow-through, not to make the strategic choice.

What is the difference between tactical and operational decisions in insurance?

Tactical decisions in insurance are made by department heads - VP Underwriting, VP Claims, Head of Product - and cover 3-12 month periods. Examples include quarterly appetite changes, pricing-tier launches, and producer commission curve adjustments. Operational decisions execute daily inside the policies set by tactical choices: approving an individual quote, paying an individual claim, calculating an individual commission line.

How does a rules engine help with data-driven decision making?

A modern rules engine like Higson supports data-driven decisions through hybrid patterns. The rule layer provides regulatory guardrails and audit trail; ML models running inside the same decision flow (Higson supports ONNX runtime natively) provide the predictive signal. This combination satisfies NAIC's 2024 Model Bulletin on AI Use in Insurance, which requires explainability for high-impact decisions, while capturing the lift that ML models deliver.

How long does it take to implement a BRMS for operational decisions?

For a mid-market P&C carrier with well-documented rules and a defined PoC scope (5-10 operational decisions), implementation typically takes 3-6 months. Carriers who skip the decision-mapping exercise before vendor selection often hit 12-18 months. Notus Finance migrated from Drools to Higson in 4 months including data migration and UAT.

What is the difference between a decision and a workflow in business automation?

A decision is a single "what should we do?" choice - approve, refer, decline; pay, hold, reject. A workflow is the orchestration of multiple steps over time, often with human tasks in between (e.g. a commercial submission that requires underwriter review, broker confirmation, and reinsurance check). Higson is a decision-focused BRMS; BPMN engines like Camunda are workflow-focused. Many insurance operations need both.

‍

Talk to Higson

The hardest part of decision-making programs in mid-market insurance is not the technology - it is the discipline to sort decisions by type before reaching for a tool. Carriers who run the mapping exercise first hit production in 3-6 months. Carriers who skip it are still scoping at month 12, and their competitors have already shipped two new product launches.

Higson is built for the operational and programmed decision tier in mid-market P&C ($500M-$5B GWP) and mid-market banking. We are not the right answer for strategic decisions, BPMN workflow orchestration, or 50 000+ req/s enterprise scale - and we'll tell you that on the first call. Where we do fit, our customers move from 4-month rule-change cycles to 24-hour ones, with audit trails that hold up to NAIC examinations.

If you'd like to see Higson Studio (the no-code authoring tool Linda uses), the decision-tables format, and the MCP integration that lets AI agents propose rule changes, I would be happy to walk you through it.

Three ways to start:

• Schedule a 30-minute demo - we'll review your decision-mapping and show the rule-flow.

• Try Higson on AWS Marketplace at $0.63 / hour - run your first rule in 15 minutes, no commitment.

• Download the BRE Comparison Guide - 12 vendors, 45 pages, for your technical evaluator. (/business-rules-engine-comparison)

‍

Citations

7. NAIC Model Bulletin on the Use of Artificial Intelligence Systems by Insurers (2023, updated 2024-2025).

8. NAIC Insurance Data Security Model Law (#668).

9. Herbert A. Simon, "The New Science of Management Decision" (1960) - foundational programmed vs non-programmed distinction.

10. Daniel Kahneman, "Thinking, Fast and Slow" (Farrar, Straus and Giroux, 2011) - decision theory foundation.

11. James G. March, "Decisions in Organizations" - operational vs strategic decisions theory.

12. Gartner Hype Cycle for Decision Management Software (2025) - analyst context for BRMS in decision-making.

13. Forrester Wave: Digital Decisioning Platforms (Q1 2026) - vendor landscape.

14. McKinsey "Building Workflow-Enabled Decisioning".

15. ONNX Runtime documentation.

16. Notus Finance / Higson case study - https://www.higson.io/case-study/