Redis Real-Time Decisioning Demo | Field Service Next Best Action

Stage 1: The Architecture

Unified service context for next best maintenance action

IoT signals, service history, contract state, parts inventory, and technician availability feed Redis through RDI and Redis Feature Form. Redis RAM handles the hot alarm path. Redis Flex holds broader failure history, asset graphs, and similar-case context so the operation can decide the best next maintenance action before downtime compounds.

Data Sources

IoT / SCADA

Asset telemetry, alarms, sensor drift

CMMS / EAM

Work orders, maintenance history, parts plans

ERP

Parts inventory, warranty, contracts, suppliers

FSM

Technician schedules, skills, routes

Kafka / Event Bus

Alarm streams, remote diagnostics, customer events

Ingest Layer

Redis Data Integration (RDI)

Synchronizes asset master, service history, work orders, contracts, and parts availability

Redis Feature Form

Serves failure risk, MTBF, first-time-fix, and dispatch propensity features

Unified Context Layer

Redis RAM

Hot asset state, active alarm windows, technician availability

Redis Flex

Warm failure history, maintenance records, manuals, and similar-case embeddings

Feature Store

Health score, downtime risk, warranty, and resolution features

Redis Context Retriever

Assembles the Job 360 — asset state, technician context, and SLA constraints — and exposes it as structured MCP tools for the decision engine

Decision Engine

Diagnostic Classifier

Remote reset, dispatch, parts order, or engineering escalation

NBA Ranker

Optimizes uptime, service cost, and first-time-fix

Policy Engine

Safety, contract SLA, warranty, and dispatch guardrails

Redis Search

Finds similar failures and successful resolution paths

Output Surfaces

Service Console

Ranked next best action for dispatcher

Technician App

Assignment, parts list, and guided procedure

Customer Portal

ETA, outage notification, and approval flow

Engineering Queue

Escalation with full context packet

↺

Learn: Alarm outcomes, first-time-fix results, technician notes, and parts usage feed Redis Streams or Kafka, then retrain resolution policy in Redis.

Decision Target

<20 ms

Surface

Dispatcher + tech app

Business Goal

Uptime + FTFR + cost

Stage 2: Alarm Trigger

A critical compressor line throws a high-severity fault

At 11:08 AM, a packaging line compressor starts running hot and vibration exceeds tolerance. Production has 45 minutes before throughput drops below customer commit. The operation has to decide whether to remote-reset, dispatch the nearest technician, pre-stage a part, or escalate to engineering.

Live Asset Event

Compressor C7

Packaging line 3 | Food manufacturing plant | Contracted uptime SLA | High-output weekday shift

CRITICAL

Eventhigh_vibration_overheat_alarm

Health score21 / 100

Downtime riskP89 within 45 min

Current production impactThroughput down 12%

Nearest technician18 minutes away

Likely partBearing kit in stock at local depot

Why This Moment Matters

Predictive maintenance has value only when the prediction leads to the right next action in time to protect uptime.

This is a real-time decisioning problem: the system has to combine alarm severity, service history, parts state, technician availability, and SLA exposure in one path.

Stage 3: Ingest

Telemetry, service history, and parts state flow into Redis

RDI synchronizes asset master data, work order history, contract state, and parts availability from CMMS, ERP, and field service tools. Kafka streams live telemetry and alarm signals. Redis Feature Form keeps failure-risk and resolution features online and ready when the alarm fires.

Redis Data Integration (RDI)Redis Feature Form

Systems → Redis

IOT

IoT / SCADA

Temperature, vibration, pressure, and alarm windows

→

CMMS

CMMS / EAM

Maintenance history, manuals, failure codes, work orders

→

ERP

ERP + Inventory

Parts availability, suppliers, warranty, service contracts

→

FSM

Field Service

Technician skills, schedules, travel, and ETA

→

Pipeline Status

Alarm ingestionStreaming

Service history syncContinuous

Parts inventory freshnessSub-minute

Feature parity100%

Stage 4: Context

The asset 360 assembles around the fault

Redis combines the live fault window, the asset’s service history, similar past failures, technician coverage, and part availability in one operating picture. The goal is not to know the machine is unhealthy. It is to know the best intervention now.

Redis RAMRedis FlexRedis Context Retriever

Operational Context

Last similar failure41 days ago on sister asset C5

Remote reset successLow on this failure pattern

Bearing kit availabilityLocal depot, ready now

Technician fitLevel-3 rotating equipment specialist nearby

Warranty stateCovered under service contract

Business Context

Production loss if down 2 hrs$96K

Customer order risk3 outbound loads slip today

Safety constraintDo not continue if temp exceeds threshold

Contract SLA exposureHigh

Stage 5: Feature Serving

Predictive and operational features hydrate in milliseconds

Redis Feature Form serves health, failure, first-time-fix, parts, and technician features online from the Redis context layer. That means the decision path can use the same definitions the models were trained on, without fan-out or drift.

Redis Feature FormRedis Feature Store

downtime_probability_45m

Probability of outage in the next 45 minutes

0.890.4 ms

remote_resolution_likelihood

Chance a remote reset resolves the fault safely

0.180.3 ms

first_time_fix_score

Expected success for dispatching the best-matched technician with the likely part

0.930.4 ms

production_loss_exposure

Estimated economic downside if the line falls offline

$96K0.3 ms

Stage 6: Ranking

The decisioning stack ranks the next best maintenance action

The platform now has enough shared context to choose the best move for uptime, cost, and first-time-fix — not just trigger another alarm or open a generic ticket.

Redis SearchNBA RankerPolicy Engine

#1 Winner

DISPATCH

Dispatch specialist with bearing kit

Best uptime protection and first-time-fix probability

Send the level-3 technician now with the local bearing kit and shut the asset down before the safety threshold is crossed.

NBA score0.96

#2 Lower Cost

REMOTE

Try remote reset first

Lower immediate cost, poor success odds

Too risky for this failure pattern because it delays the higher-confidence intervention and could worsen downtime exposure.

NBA score0.54

#3 Escalate

ENGINEERING

Escalate to engineering review

Useful only if dispatch path fails

Important backup path, but not the best first action when the likely failure mode and repair path are already well understood.

NBA score0.46

Stage 7: Business Impact

The value is less downtime and higher first-time-fix

Redis helps the operator act on predictive signals with the right resolution path. That protects uptime, reduces repeated truck rolls, and raises first-time-fix instead of treating predictive maintenance like another alerting layer.

Maintenance Economics

Downtime avoidedUp to $96K exposure

First-time-fix impactHigher with parts + skills matched

Truck roll efficiencyFewer blind dispatches

Customer / SLA protectionOutbound loads preserved

Per-Alarm Outcome

alert only

Open ticket and wait

→

ranked action

Dispatch the right tech with the right part

Stage 8: Outcome

Same alarm. Different operating model.

Without Redis, the service team opens a ticket and starts chasing context manually. With Redis, the dispatcher gets the ranked maintenance play with the parts, skill fit, and business impact already assembled.

Alert-Driven Workflow

SERVOPS

Alarm detected, manual triage required

Current action

Open ticket

No ranked maintenance play

low

context

manual

routing

unclear

FTFR

Redis-Powered Service Brief

SERVOPS

Maintenance brief, ready now

Next best action

Dispatch specialist

Bearing kit pre-staged

Unified context assembled in Redis

First-time-fix confidence: 93%

Alarm state, service history, parts readiness, and technician fit all line up behind the same action.

93%

FTFR confidence

<20ms

decision time

ranked play

Stage 9: Architecture Recap

One live context layer for maintenance actioning

IoT, CMMS, ERP, and field service systems stay in place. RDI and Redis Feature Form make them operational. Redis RAM and Redis Flex serve the hot and warm service context. The decisioning stack turns that into the best next maintenance action before the asset falls offline.

Data Sources

IoT / SCADA

Asset telemetry, alarms, sensor drift

CMMS / EAM

Work orders, maintenance history, parts plans

ERP

Parts inventory, warranty, contracts, suppliers

FSM

Technician schedules, skills, routes

Kafka / Event Bus

Alarm streams, remote diagnostics, customer events

Ingest Layer

Redis Data Integration (RDI)

Synchronizes asset master, service history, work orders, contracts, and parts availability

Redis Feature Form

Serves failure risk, MTBF, first-time-fix, and dispatch propensity features

Unified Context Layer

Redis RAM

Hot asset state, active alarm windows, technician availability

Redis Flex

Warm failure history, maintenance records, manuals, and similar-case embeddings

Feature Store

Health score, downtime risk, warranty, and resolution features

Redis Context Retriever

Assembles the Job 360 — asset state, technician context, and SLA constraints — and exposes it as structured MCP tools for the decision engine

Decision Engine

Diagnostic Classifier

Remote reset, dispatch, parts order, or engineering escalation

NBA Ranker

Optimizes uptime, service cost, and first-time-fix

Policy Engine

Safety, contract SLA, warranty, and dispatch guardrails

Redis Search

Finds similar failures and successful resolution paths

Output Surfaces

Service Console

Ranked next best action for dispatcher

Technician App

Assignment, parts list, and guided procedure

Customer Portal

ETA, outage notification, and approval flow

Engineering Queue

Escalation with full context packet

↺

Learn: Alarm outcomes, first-time-fix results, technician notes, and parts usage feed Redis Streams or Kafka, then retrain resolution policy in Redis.

Decision Target

<20 ms

Surface

Dispatcher + tech app

Business Goal

Uptime + FTFR + cost