Every UAE operator we work with is running a version of the same story. Sensors were installed as part of a modernisation programme two or three years ago. Telemetry flows into a dashboard on a wall in the operations centre. Nobody watches the wall. When an incident happens, someone reconstructs what the sensors already saw — from timestamps in a data lake, at 2am, three hours after the equipment stopped. The investment is real. The operational value is not.
The instinct is to add more visualisation or another AI layer. The instinct produces another dashboard nobody watches. What produces operational value is closing the loop: telemetry that becomes a ticket, a ticket that routes to a named owner, an owner that opens a runbook, a runbook that closes with evidence. B11 does that work on a fixed scope in 8–12 weeks. Anything short of the closed loop is a dashboard, not operations — and we will not ship the dashboard-only version.
Six streams,
ending in the loop closed.
Telemetry audit and anomaly design front-load weeks 1–3. ITSM integration and rule tuning overlap through weeks 3–9. Runbooks, dashboards, and handover close weeks 9–12.
Telemetry audit
Sensor and gateway estate inventoried. Data completeness measured against expected. Latency and reliability baselined per sensor class. Estate map signed before Phase 2.
Anomaly rules & baseline
Alert conditions defined per asset class, baselined against 4–8 weeks of actual telemetry, tuned for precision on your operating envelope — not shipped with vendor defaults.
ITSM integration
Bidirectional integration with your ITSM — ticket creation with enrichment, closure feedback to the anomaly rule, correlation to suppress alert storms. Not outbound-only.
Signal-to-owner routing
Routing rules by asset criticality, time-of-day, and business impact. Named owner groups per rule class. Escalation logic wired against agreed response SLAs.
Runbooks & dashboards
Runbook per alert class — trigger, steps, evidence artefacts, closure criteria. Dashboards for the operations team and executive sponsor — the ones actually consulted, not the ones filed to satisfy the SOW.
Validation & handover
End-to-end loop rehearsed on live telemetry with the on-call team. False-positive rate measured against baseline. 30/60/90-day check-ins scheduled.
Twelve weeks maximum.
Eight minimum. Four phases.
Phase count is fixed. Duration flexes with sensor estate size, ITSM integration complexity, and the number of asset classes requiring distinct rule sets. Milestones are signed gates — not aspirations.
Platforms scored,
not on demo dashboards.
Every engagement runs a six-criteria scorecard in weeks 1–2. Each candidate platform scored 1–5 against your sensor estate and ITSM. Signed by the operations lead before Phase 2 begins.
From dashboards on walls
to tickets closed with evidence.
A typical pre-engagement state has sensors installed, telemetry flowing into a dashboard nobody watches, alerts firing into a Slack channel that scrolls faster than anyone reads, and manual tickets created after the fact by whoever reconstructed the incident. The engagement closes the loop.
Reference pattern. Some engagements retain a specialist SCADA or historian layer alongside the closed-loop, particularly in utility or industrial estates. What always changes is that telemetry stops being data at rest and starts being work in progress.
An industrial facility,
response time halved.
Representative pattern for a UAE industrial or manufacturing operator of this scale — 2,000+ sensor estate, existing ITSM in place, response times exceeding SLA. Ranges reflect target outcomes NexITC underwrites in scope for this class of engagement. N=1 — illustrative composite, not a specific client.
Five artifacts,
each with signed acceptance.
Every deliverable has documented acceptance criteria signed at engagement kickoff. Nothing more, nothing less.
Telemetry Integration Layer
Sensor and gateway estate connected to the platform with data completeness measured against expected. Not a demo pipeline — an operational one.
Anomaly Detection Rules
Alert conditions defined per asset class, baselined against 4–8 weeks of your telemetry, tuned for precision on your operating envelope.
ITSM Ticket Automation
Bidirectional integration — creation with enrichment, closure feedback, correlation to suppress storms. Named owner routing wired.
Operations Dashboards
The ones actually consulted by the operations team and executive sponsor, not the ones filed to satisfy the SOW.
Response Runbooks
Runbook per alert class — trigger, steps, evidence artefacts, closure criteria — rehearsed with the on-call team on live telemetry before handover. The document that closes the loop, not the one that gets forwarded on incident and reopened three days later without changes.
Six outcome metrics,
measured pre and post.
Success is not "the platform is live." It is measured against six specific outcomes captured in a baseline report at engagement start and re-measured at post-handover steady state.
Honest scoping.
B11 is a fit when specific conditions are met. It is not a fit when other conditions are. We say so before the scope conversation, not after the commercial commitment.
Sensors installed, gateways reporting, data reaching a lake or platform. If the estate is proposed but not deployed, sequence a sensor rollout first — B11 does not install hardware.
Whatever your team already runs. B11 integrates; it does not replace. If no ITSM exists, that decision precedes the closed-loop discussion.
Signs off anomaly rules, routing logic, and runbooks. Typically 30% time commitment through the engagement. The on-call team's day-job knowledge is what makes runbooks work.
Someone who can commit response-time targets and defend them against workload teams. Without that seat filled, alert routing is optimised for wrong incentives.
The people who will actually receive routed tickets. If ownership is diffuse, we scope B11 around the well-owned asset classes rather than pretending the routing works everywhere.
B11 does not install hardware. Sensor rollout is a separate discipline — sequence that first, then B11 becomes the operational layer on top.
That's B12 OT/IoT Security Hardening Build™ — segmentation, safety-interlock preservation, edge incident playbooks. B11 addresses operational integration; B12 addresses the security overlay.
That's B16 Digital Twin Operations Blueprint™ — architecture, AI models, spatial visualisation. B11 is the operational-response discipline; B16 is the analytical foundation.
That's C1 OpsCommand™ — sensible as the next engagement after B11, or immediately if a closed loop is already in place.
Fixed fee.
Milestone-based.
Total engagement fee agreed in the scope statement. Not time-and-materials. Not day rate. Every engagement is preceded by a scope conversation to ensure fit before commitment.
Five, most asked.
Q_01What does "closed-loop" actually mean in operational terms?
Four specific things happen every time a monitored condition triggers. Anomaly detection recognises the signal against tuned rules. A ticket is created in your ITSM with the enrichment the responder needs. The ticket routes to a named owner group based on asset criticality and time-of-day. The owner opens a runbook keyed to the specific alert class and closes with evidence.
Anything short of that four-step loop is a dashboard, not operations — and B11 refuses to ship the dashboard-only version.
Q_02Is this predictive maintenance?
Q_03Which IoT platform do you build on?
Q_04How do you handle false positives?
Q_05What comes after the build?
One name
on the engagement letter.
A named Practice Lead is accountable for delivery, commercial outcomes, and the client relationship throughout the engagement. Not a project manager who disappears after kickoff. Not a partner who nods at the SOW and vanishes.
Practice Lead — IoT
Present at every phase gate, every scope decision, every difficult conversation. Available for 30/60/90-day post-handover check-ins as part of the engagement.
Including scope amendments.
Signs off all 5 deliverables.
With executive sponsor.
Authorised to negotiate.
CEO within 24 hours.
30/60/90-day check-ins.
Prior. Peer. Next.
Ops Scorecard™
2-week IT operations baseline that surfaces whether the operational response layer is ready to receive IoT-generated tickets. Sensible if MTTR and repeat-incident discipline aren't already established.
OT/IoT Security Hardening Build™
Peer build for the security side of the OT/IoT boundary — segmentation, safety-interlock preservation, edge incident playbooks. Often paired B11 + B12 for a full IoT operations + security rollout.
OpsCommand™
Managed IT operations. Runs the closed-loop continuously — rule tuning, runbook evolution, ticket-to-resolution measurement, and quarterly reliability releases.
Thirty minutes.
No slide deck.
A structured 30-minute scope conversation with the Practice Lead. You describe the sensor estate, the alert volume, and where operational response breaks down today. We describe whether B11 is the right engagement — and if not, what is.