A decision engine is an automated system that watches a stream of your business data, checks each new event against a rule or a model, and fires an action the instant a condition is met. The action might be a reorder, a price change, a hold on a suspicious payment, or an alert to the one person who can deal with it. Unlike a dashboard, which sits there until someone looks at it, a decision engine acts on its own.
Every one of these workflows has the same three parts: an event that triggers it, a decision that evaluates it, and an action it fires. Get those three right and you have a system that catches the fraud, the stockout, or the leaving customer in the seconds that matter, instead of finding out the next morning when the damage is done.
The payoff is real, but so is the catch. Companies that put data at the centre of decisions are 58% more likely to hit their revenue goals and 162% more likely to beat them (Forrester Consulting). The catch is that “real time” is genuinely worth it for only some decisions, and bolting it onto the wrong ones just adds cost and noise. This is a guide to building the right ones.
The anatomy: event, decision, action
Strip away the jargon and every real-time workflow is three stages wired together.
- The event (the trigger). Something happens and is recorded as a small piece of data: a payment is attempted, a unit is sold, a customer abandons a cart, a sensor crosses a limit. This is the spark.
- The decision (the brain). The engine evaluates that event. Either it checks a fixed threshold rule (“is stock below 20?”) or it asks a model (“how risky is this transaction, given everything we know?”). It returns a verdict.
- The action (the response). Based on the verdict, the engine does something: send an alert, place a reorder, decline a payment, drop a price, open a ticket. An action no one defined means the whole chain ends in silence.
The reason this matters for a small business is that you do not have someone watching every screen all day. The engine is the watcher. Your job is to define, once, what counts as worth reacting to and what should happen when it does.
Event streams: reading data as it arrives
For an action to land in seconds, the data has to be read as it happens, not saved up and analysed later. That continuous flow of small records, one per thing that occurs, is an event stream.
The contrast is with batch processing, the way most small businesses run today: collect a day or a week of data, then process it all at once. Batch is perfectly fine for a monthly sales report. It is useless for catching a problem while it is still happening. On instant-payment rails, money settles irreversibly in seconds, so a batch fraud review that runs overnight flags the theft 12 to 48 hours after the cash is already gone (Lucinity). Mature real-time fraud systems score a transaction in under 50 milliseconds, fast enough to decline it before it completes (Materialize).
You do not need a giant streaming platform to start. For most SMEs, an event stream can be as humble as a webhook that fires every time an order is placed, or a small script that watches a database table for new rows. The principle is what counts: each event is evaluated the moment it arrives.
This is also where raw data quality decides everything. An event arriving with a missing timestamp, a wrong product code, or a duplicated record will trigger the wrong action, fast. Before any of this runs reliably, the underlying data engineering has to be solid, because a real-time system magnifies a data problem instead of hiding it.
Threshold rules vs model-based decisions
The “brain” in the middle comes in two flavours, and most SMEs need both for different jobs.
A threshold rule is a fixed line you draw yourself. Alert when stock falls below 20 units. Flag any single invoice above one lakh. Notify me if a refund exceeds the order value. Rules are transparent, instant to set up, and easy to trust, because you can read exactly why they fired. Start here. Most useful alerts in a small business are simple thresholds, and a rule you understand beats a model you cannot.
A model-based decision is worth the extra effort when no single number captures the call. Fraud is the classic case: a 5,000 rupee transaction is not suspicious by amount alone, but a 5,000 rupee transaction from a new device, in a new city, at 3am, on a card that normally spends 500 rupees, is. A model weighs all of those signals together and returns one risk score. The same logic powers a churn signal (intent built from drop in logins, support tickets, and a cancelled add-on) or a smart reorder point that learns each product’s real sales pace instead of using one flat number.
| Threshold rule | Model-based decision | |
|---|---|---|
| How it decides | A fixed line you set | Learns patterns from history |
| Best for | Clear, single-signal limits | Many signals, no obvious cutoff |
| Why trust it | You can read the rule | Tested against past outcomes |
| Example | Stock below 20 units | Fraud risk score, churn signal |
The honest rule of thumb: use a threshold until you can point to real cases the threshold gets wrong, then a model earns its place. Galific’s real-time inference engines are built for exactly the second case, scoring each event as it arrives.
Alert a human, or act automatically?
This is the line that separates an alert from a true decision engine, and it is the most important design choice you will make.
An alert tells a person and then waits. It is the right call when the situation needs human judgement, the cost of a wrong automatic action is high, or the decision is rare enough that a person can handle it. “A high-value customer just hit a cancellation page, call them” is an alert. A human decides what to say.
A decision engine acts on its own and logs what it did, usually with a human able to override or reverse it. It earns its place when the decision is well understood, repeats constantly, and loses its value if a person has to be in the loop. Declining an obviously fraudulent transaction, placing a reorder when stock crosses the line, throttling a runaway ad campaign: these are decided thousands of times, the same way each time, and waiting for a human defeats the point.
A practical pattern is to run both at once on a sliding scale of confidence. Below a risk score of 30, do nothing. Between 30 and 70, alert a human to review. Above 70, act automatically and tell the team afterwards. The engine handles the clear-cut cases by itself and escalates only the genuine grey areas to a person.
Whichever side you land on, guard against alert fatigue, the quiet killer of real-time systems. In security operations, where alert volumes are extreme, studies find that the large majority of alerts turn out to be false alarms (CyberDefenders), and once that happens people simply stop reading them. A system that cries wolf is worse than no system. The fixes are concrete: tune the conditions, group related events into one notification, route each alert to the single person who can act on it, and let the engine quietly handle the routine cases so humans only ever see what truly needs them.
Where real time pays off (and where it does not)
The whole question of whether to build any of this comes down to one thing: how fast does the decision lose its value? Data is perishable; the worth of acting on an event can drop to almost nothing within minutes (Cognizant). Match the speed of your system to that decay, and not a step faster.
Real time clearly pays off here:
- Fraud and payments. On instant-payment rails the money is gone in seconds, so the decision has to be made in seconds. There is no slower version of this that works.
- Stockouts on fast movers. Products that run out stay out for an average of 35 days, and 43% of shoppers simply buy from a competitor when they hit an out-of-stock item (Opensend). A same-minute reorder trigger on your bestsellers protects real revenue.
- Churn and abandonment signals. A customer about to cancel or about to abandon a full cart is reachable now and gone in an hour. The window is short by nature.
Real time is overkill here:
- A weekly stock review for slow, steady products. A scheduled report is cheaper and just as good.
- A monthly financial close. Nothing is decided second by second, so streaming adds complexity for no return.
- Long-term trend analysis. Strategy questions are answered with depth, not speed.
The mistake that wastes the most money is treating every metric as urgent. The discipline is the opposite: pick the two or three decisions where seconds genuinely change the outcome, build real-time engines only for those, and leave everything else on a sensible schedule.
From raw data to a decision that acts
A real-time engine is the last link in a chain that runs all the way back to your messy source data. Scattered records become clean, timestamped events through data engineering. Those events feed the rule or the model that decides. The decision fires an action inside the tools your team already uses. Skip the first link and the rest of the chain delivers fast, confident, wrong answers, which is precisely why Galific starts every engagement with a data audit rather than code: we confirm your events are clean and complete enough to trust before anything is wired to act on them. That audit-first habit runs through all of our data intelligence work.
Done well, a decision engine quietly removes a whole class of “I wish we had caught that sooner” moments. The fraud is declined before it clears. The reorder is placed before the shelf is empty. The leaving customer gets a call while they are still on the page. None of it needs a person watching a screen, which is the entire point of building it.
If you have a decision where seconds change the outcome, tell us what it is and we will start by checking whether your data can support an engine to handle it, before you spend anything on building one.
