onITnow Service Framework — Companion Guide

Service by service

The seven, in detail

Every service gets the same treatment: what it's for, a situation you'll recognise, what's included, where it deliberately stops, and who it hands to next.

Direction · Strategic & advisory

Horizon

Answers one question: where do we want our service management capabilities to be — and why?

A situation you'll recognise

The board signs off on doubling headcount within eighteen months. Everyone models the hiring, the office space and the licences. Nobody asks what it does to the service desk, the joiner process or the tooling — until month fourteen, when it's an emergency. Horizon asks in month one.

What's included

Strategic direction — a long-term service management vision, aligned to business strategy rather than to tool limitations
Capability roadmap — high-level and multi-year, with prioritisation guidance based on business impact and maturity
Maturity assessments & health checks — objective reads on maturity, organisational readiness, process alignment and tool effectiveness
Trend & innovation analysis — vendor roadmaps, AI and automation, compliance shifts, evolving practice. Relevance over hype
Advisory & decision support — scenario exploration, impact analysis, recommendations for leadership

Where it stops

No KPI definition or performance frameworks — that's Pilot
No backlog ownership or governance activity — Pilot
No project initiation or execution — Spark
No functional or technical design work — Spark, Engine, Flow
No operational improvement steering

How it's delivered

Periodic strategic sessions — quarterly or half-yearly — plus assessment-driven engagements and roadmap reviews. Deliverables are narrative: vision statements, strategic recommendations, maturity insights. Directional, not an operational task list.

↔ PilotHorizon defines where to go; Pilot governs and translates that into controlled execution.

↔ SparkStrategic initiatives identified in Horizon may be realised as Spark projects.

↔ EcosystemKeeps every service evolving consistently and intentionally rather than opportunistically.

You'd call Horizon when growth or transformation demands direction, leadership needs insight rather than operational detail, maturity must be assessed objectively — or you want strategic control without anyone taking over your operation.

Governance · Proactive control

Pilot

Governing service management leadership. onITnow designs, specifies and controls — you stay formally accountable.

A situation you'll recognise

Three teams each have an improvement list. Each assumes one of the others is prioritising. Nothing is formally owned, so the loudest request wins and the important one waits a year. Pilot owns the single governed backlog, and decides what becomes a project, a ticket, or a no.

What's included

Design & control — service management structure, roles, responsibilities, interfaces, governance principles and guardrails
Process ownership at specification level — objectives, scope, flows, rules, quality and compliance requirements, consistency across the lifecycle
KPI & performance framework design — the KPIs, the dashboards, the reporting structures, the evaluation criteria
Lifecycle & adoption governance — platform lifecycle, adoption strategy, alignment between tooling, process and maturity
Backlog & roadmap ownership — prioritisation, alignment to business objectives, coordination of change demand, decision preparation

Where it stops

No operational execution of any kind
Designs how performance is measured — but doesn't do the day-to-day monitoring or operational reporting (that's Crew)
No incident handling — Anchor
No functional maintenance — Engine; no integration work — Flow
No project delivery — Spark; no vendor operational management

Two modes

Pilot — onITnow acts as the governing Service Manager
Co-pilot — onITnow is sparring partner to your existing Service Manager

In both, Pilot provides decision support, never unilateral decision authority.

Execution routes

Roadmap items go to Spark (projects)
…or Engine (functional maintenance)
…or Flow (integration work)
…or Crew (capacity & expertise)

↔ HorizonHorizon sets direction; Pilot turns it into governed priorities, backlog structure and execution control.

↔ SparkPilot decides which improvements need project delivery; Spark delivers them against agreed acceptance criteria.

↔ AnchorPilot defines escalation models and guardrails; Anchor applies them during intake and coordination.

↔ EnginePilot sets the boundaries for functional maintenance; Engine executes within them.

↔ FlowPilot defines integration priorities; Flow executes maintenance and correction within scope.

↔ CrewPilot defines what and why; Crew executes without taking on governance or decision authority.

You'd call Pilot when governance or consistency is missing, roles are unclear, complexity is outgrowing the current setup, or improvement needs direction instead of ad-hoc effort — and you want executive control without an operational takeover.

Change · Project-based delivery

Spark

Everything new, complex or structural — designed, built, tested, accepted and formally handed over.

A situation you'll recognise

The decision is made: the ageing tool goes, a new platform comes in. That is not a ticket. It's design, configuration, migration, integrations, testing, training and a handover — and it has to happen without the daily operation grinding to a halt. Spark runs it as a scoped project; operations carry on.

What's included

Platform & solution implementation — initial setup, new products or modules, environment configuration
Process design & implementation — workflows, templates, forms, process logic aligned to best practice such as ITIL
Configuration & customisation — functional and advanced configuration, roles, permissions, structural setup
Integrations & automations — design and build of new integrations and data flows to external systems
Data & reporting — migration where applicable, reports and dashboards, data quality validation
Testing & acceptance — functional testing, UAT support, resolution of findings, formal acceptance support
Documentation & knowledge transfer — solution, configuration, process and operational documentation
Training & enablement — end-user, key-user and administrator instruction as scoped

Where it stops

No day-to-day ticket handling — Anchor
No recurring functional maintenance — Engine
No minor configuration changes after acceptance — Engine
No operational incident support — Anchor
No ongoing optimisation outside the agreed project scope

How a Spark engagement works

Project-based, delivered as fixed scope / fixed price or time & materials
Scoped upfront through a proposal covering scope, deliverables, assumptions and boundaries
Explicitly covers work outside regular operations

Every project ends with a handover

Configuration and solution transfer, documentation, runbooks where applicable
Agreement on ownership, responsibilities and next steps
Then into Engine, Anchor, Flow or Crew depending on your setup

↔ HorizonHorizon names the strategic themes; Spark turns selected ones into scoped projects with tangible deliverables.

↔ PilotPilot governs the backlog and decides what becomes controlled change; Spark delivers within scope and timeline.

↔ AnchorAnchor routes work to Spark when it needs project delivery, and picks up support coordination afterwards.

↔ EngineSpark delivers new or structural functionality; Engine maintains and optimises it once it's live.

↔ FlowSpark builds new integrations; Flow keeps them working once they're in production.

↔ CrewCrew can supply specialist capacity inside a Spark project; Spark keeps delivery control and acceptance.

You'd call Spark when you're implementing a new platform or product, changing a process fundamentally, building complex integrations, executing a Horizon roadmap item — or delivering any high-impact change that shouldn't be improvised inside daily operations.

Operations · Reliability & support

Anchor

One front door for anything platform-related. Anchor registers, classifies, routes, chases the vendor and keeps you informed.

A situation you'll recognise

08:40. The self-service portal won't load. Is it the vendor? The integration? Something someone changed on Friday? Without Anchor, three people start three parallel investigations and one of them opens a vendor ticket that nobody chases. With Anchor, it's reported once, classified once, and someone whose job it is follows the vendor until it's closed.

Included, not invoiced. Anchor is always included and free of charge when onITnow provides your service management platform licences. It's part of the standard model and can't be separated from licence delivery. Work that Anchor routes onward to Engine, Flow, Spark or Crew may need its own agreement, subscription or project scope.

What's included

Central intake — a single entry point for platform incidents, platform-related requests, and issues concerning other onITnow services you consume
Registration & classification — incident registration, initial classification and routing, impact assessment against standard SLA definitions
Reactive incident coordination — availability issues, defects and bugs, performance degradation, vendor-side outages, and integration incidents (reported here, corrected by Flow)
Request intake for other services — changes for Engine, integration incidents for Flow, project work for Spark, capacity for Crew — with proper classification, clean handover and ongoing communication
End-to-end vendor coordination — logging tickets with software vendors, tracking progress, actively following up and escalating, and translating technical vendor-speak into something you can actually act on

Where it stops

No functional configuration changes — Engine
No implementation of fixes or improvements — Engine or Spark
No data corrections or workflow modifications — Engine
No user guidance or "how-to" questions
No proactive monitoring — Anchor responds to what's reported; it doesn't detect incidents before you do

SLA & execution model

Standard SLAs, identical for every customer
Commitments cover response time, initial assessment, coordination and communication
They do not guarantee resolution times for vendor defects, platform outages, third-party dependencies, or work executed by other service modules
Anchor is fully reactive by design

What we need from you

Complete incident information: impact, urgency, affected users or processes, screenshots, error messages, reproduction steps, business context
Approval of business decisions and granting of required access
Confirmation of whether routed work should proceed under Engine, Flow, Spark or Crew

↔ EngineAnchor does intake, classification and communication; Engine executes the approved functional or technical work.

↔ FlowAnchor receives and coordinates integration incidents; Flow does the technical analysis and correction.

↔ SparkAnchor routes work to Spark when it exceeds operational support — and Spark hands finished solutions back for support coordination.

↔ CrewAnchor may identify a capacity need; Crew supplies it while Anchor keeps intake and coordination.

↔ PilotPilot defines governance principles and escalation routes; Anchor operates inside them.

You'd rely on Anchor when platform incidents occur, vendor defects or outages hit operations, requests need routing to the right service — or you simply want vendor follow-up to stop being your problem.

Operations · Management, maintenance & optimisation

Engine

The daily run, done properly: recurring configuration and functional maintenance through a controlled, request-based model.

A situation you'll recognise

HR wants one extra field on the onboarding form, and a rule that routes contractors differently. Small. Sensible. And exactly the kind of change that, done ad-hoc by whoever has admin rights, quietly breaks a report three weeks later. Engine takes it as a defined request type and delivers it within an agreed lead time — without collateral damage.

What's included

Functional maintenance & configuration — workflows, templates, forms, automation rules and action sequences, request models
Functional improvements within existing design boundaries, plus optimisation of what's already configured
Technical upkeep — maintaining existing configurations, safeguarding technical consistency, ensuring changes don't damage what already works
Ticket-based execution — you submit requests in your own service management tool; together we define which qualify as standard Engine requests; approved requests are delivered within agreed lead times
Standardisation & efficiency — identifying repeatable request types so delivery gets faster and friction drops over time

Where it stops

No project-based implementations — Spark
No fundamental process redesign or structural rebuild — Spark
No new integrations or automations — Spark to build, Flow to maintain
No platform incidents or vendor defects — Anchor
No strategic or architectural decision-making — Horizon and Pilot
No proactive monitoring or roadmap activity

The deal, in three lines

You stay in controlYou decide what to request, and when.

onITnow executesAgainst predefined standards and agreed scope.

Duties stay separateIntake and coordination via Anchor; execution via Engine.

↔ AnchorAnchor restores stability; Engine restores functionality. Anchor takes intake, coordination and routing; Engine does the work.

↔ SparkRequests beyond Engine scope — fundamental change, structural redesign, new functionality, anything complex or non-standard — transfer to Spark to be scoped as projects.

↔ FlowEngine handles functional requests; Flow handles integration-specific fixes, monitoring and maintenance.

↔ CrewWhen more capacity or specialist expertise is needed, execution can be delivered through Crew under the same scope and governance.

You'd use Engine when you need recurring configuration changes handled predictably, want functional maintenance to be a known quantity rather than a favour — and want daily operations stable without change turning into improvisation.

Operations · Managed connections & automation

Flow

Keeps agreed live integrations working as the technical world around them changes — and notices the change before it breaks something.

A situation you'll recognise

Your identity provider deprecates an API version. Nothing looks wrong. Then new joiners quietly stop syncing, and you find out when a manager asks why their new hire has no account on day one. Flow's job is to see that change coming, assess it, and adapt the integration — so the failure never reaches the service desk.

What's included

The agreed integration landscape — connections between the service management platform and identity & access systems (Entra ID / Azure AD, SCIM), HR systems, monitoring tools, discovery tools and other service management platforms. Only integrations delivered or managed by onITnow are in scope
Change detection & impact anticipation — spotting API, endpoint, authentication and payload changes, shifts in exchanged data, structures, mappings or synchronisation behaviour, and assessing what they'll do to your integrations
Maintenance of live integrations — adapting endpoints, API calls, authentication settings, payload formats, mappings and transformations when interfaces change; maintaining compatibility after version upgrades; preventing quality drifting downward over time
Incident resolution & correction — technical analysis of synchronisation and interface errors, correction of mappings and transformations, restoration of reliable data exchange

Where it stops

No design or initial build of new integrations — Spark
No one-off scripts or custom API development
No structural redesign of integrations — Spark
No functional configuration inside the platform — Engine
No changes to processes, workflows, forms, templates, roles, permissions, business rules, data ownership or user-facing behaviour
No changes to what data means, when it's created, who approves it, or how it drives decisions

Rule of thumb. If the purpose is to keep an agreed data exchange working after a technical interface change — it's Flow. If the purpose is to change what the business process does, how users work, which data is functionally required, or how the platform behaves — it isn't.

Who watches what

onITnow detects and anticipates changes in the APIs, endpoints, data structures and interfaces of the solutions it delivers or manages for you
You detect and communicate changes in customer-owned applications, APIs, endpoints, data sources, authentication mechanisms and data structures — in time for us to assess the impact

When assumptions break

Uncommunicated customer-side changes can still be corrected through Flow when they relate to keeping an agreed integration alive
But issues caused by unsupported systems, missing access, unavailable documentation, or functional customer-side changes fall outside standard Flow assumptions — those get coordinated via Anchor

↔ AnchorAnchor takes intake, communication and coordination; Flow does the technical execution and correction.

↔ EngineEngine covers functional work inside the platform; Flow covers technical integration continuity — endpoints, mappings, authentication, payloads, recovery.

↔ SparkSpark designs and builds new integrations; Flow operates them once live, adapting as connected interfaces evolve.

You'd depend on Flow when stable data synchronisation is operationally critical, interface changes need to be caught before they disrupt anything, and integration failures need resolving without escalating into a project every time.

Capacity · Professional expertise

Crew

Certified people who work as part of your team, inside your processes and governance — without taking ownership of any of it.

A situation you'll recognise

Your service manager is out for three months, and the reporting specialist you were going to hire is still a job advert. The work doesn't pause. Crew puts a named professional into the seat — following your processes, your priorities and your governance — and takes them back out again when you no longer need them.

What's included

Operational execution — functional and technical application management, process execution (incident, change, request), day-to-day support under existing governance
Improvement execution — supporting Spark projects, executing backlog items defined by Pilot, assisting optimisation within Engine or Flow scope
Specialist expertise — integration specialists, reporting and dashboard specialists, service management professionals, platform and process specialists
A flexible engagement model — temporary or long-term, full-time or part-time, scaled up or down as demand moves

Where it stops

No strategic decision-making — Horizon
No service management governance — Pilot
No roadmap or backlog ownership — Pilot
No defining of scope, priorities or success criteria — Crew executes improvements, it doesn't shape them
Crew may support KPI monitoring or reporting when explicitly assigned, but never defines KPIs or governance frameworks

The line that matters: Pilot decides what and why. Crew executes how and when, within your operation. Direction always comes from Pilot, Spark, Engine or Flow — never from Crew itself.

↔ PilotPilot governs; Crew executes.

↔ SparkSpark designs and delivers projects; Crew may supply execution capacity inside them.

↔ EngineEngine defines the standard operational work; Crew provides the hands to do it.

↔ FlowFlow defines the integration work; Crew may execute under Flow's direction.

You'd use Crew when internal capacity falls short, specialist expertise is missing, support is needed temporarily or structurally — or execution has to scale without changing who owns what.

If you need…	Start with	Why
Strategic direction and long-term maturity	Horizon	Defines the future direction and the strategic capability roadmap.
Governance, control and clear accountability	Pilot	Creates the steering layer, backlog control and decision-support model.
New implementation or major change	Spark	Delivers scoped project change and a formal handover to operations.
Incident coordination and vendor follow-up	Anchor	Provides intake, routing, communication and escalation.
Recurring configuration and functional maintenance	Engine	Executes predictable request-based work within agreed boundaries.
Reliable integrations and data exchange	Flow	Maintains and monitors agreed live integrations.
Additional people or specialist expertise	Crew	Provides capacity without changing ownership or governance.

Activity / responsibility	Horizon	Pilot	Spark	Anchor	Engine	Flow	Crew
Direction
Long-term service strategy	●	–	–	–	–	–	–
Strategic roadmap (multi-year)	●	spec	–	–	–	–	–
Maturity assessments / health checks	●	–	–	–	–	–	–
Trend & innovation analysis (AI, compliance, vendor roadmap)	●	–	–	–	–	–	–
Governance
Governance & guardrails	–	●	–	–	–	–	–
Service management design	–	●	–	–	–	–	–
Backlog & improvement roadmap ownership	–	●	–	–	–	–	–
KPI & dashboard design	–	●	–	–	–	–	–
KPI monitoring & reporting	–	–	–	–	–	–	exec
Change
Project-based implementations	–	spec	●	–	–	–	exec
New processes / fundamental changes	–	spec	●	–	–	–	exec
New integrations & automations	–	spec	●	–	–	–	exec
Operations
Day-to-day incident intake & coordination	–	–	–	●	–	–	–
Vendor coordination & escalation	–	–	–	●	–	–	–
Functional configuration changes	–	–	–	–	●	–	exec
Workflow / form / template updates	–	–	–	–	●	–	exec
Integration monitoring	–	–	–	–	–	●	–
Integration maintenance & fixes	–	–	–	–	–	●	exec
Capacity
Operational execution	–	–	exec	–	exec	exec	●
Specialist or additional capacity	–	–	–	–	–	–	●

The whole framework, in seven lines

Four layers, one direction of travel

Layer 1 · Direction

Layer 2 · Governance

Layer 3 · Change

Layer 4 · Operations

Running alongside · Capacity

The seven, in detail

Horizon

What's included

Where it stops

How it's delivered

Pilot

What's included

Where it stops

Two modes

Execution routes

Spark

What's included

Where it stops

How a Spark engagement works

Every project ends with a handover

Anchor

What's included

Where it stops

SLA & execution model

What we need from you

Engine

What's included

Where it stops

The deal, in three lines

Flow

What's included

Where it stops

Who watches what

When assumptions break

Crew

What's included

Where it stops

Pick the sentence that sounds most like this month

Or work back from the need

Who is responsible for what