At a glance
- Challenge
- Software delivery takes days because fulfilment is manual, licence availability is never checked and there is no deployment feedback loop.
- Approach
- Wire the ServiceNow catalogue to Intune deployment with entitlement validation before approval and an automatic write-back to the CMDB and licence allocation.
- Primary KPI
- Average fulfilment turnaround time from approved request to confirmed successful deployment.
- Impact
- Employees productive on day one, service-desk effort removed and licence reuse enforced before any purchase is raised.
01
Executive Summary
Software fulfilment is one of the few IT processes where the business measures the outcome in hours and the delivery function measures it in tickets. A new joiner requests a design tool on Monday, the request queues behind an approval nobody has chased, a technician manually checks a spreadsheet for spare licences, someone raises a purchase requisition to be safe, and the software arrives on Thursday. The licence that was already sitting unused on a leaver's account is never found.
This playbook describes a representative automated pipeline built on ServiceNow and Microsoft Intune. The important design decision is where the licence check sits: before approval, not after. Validating entitlement availability while the request is still in flight is what turns fulfilment from a procurement trigger into a reuse mechanism.
The second design decision is the feedback loop. Intune reports installation success back into ServiceNow, which updates the CMDB and the licence allocation record automatically. Without that write-back the pipeline is fast but the asset data drifts, and within two quarters the allocation record is fiction.
02
Business Challenge
Manual fulfilment fails in three predictable places. Approvals sit unattended because the request does not tell the approver what it costs or whether a licence already exists. Availability is checked against a spreadsheet or not at all, so purchasing becomes the default path and reharvesting never happens. And deployment success is confirmed by the user replying to a ticket, which means the asset record is updated late, inaccurately, or never.
The compliance consequence is quieter but larger. Without a policy gate in the request path, restricted software — anything with a per-core metric, an export-control constraint or a specific product-use right — is installed by the same self-service route as a PDF reader. The first time anyone notices is during an audit or a security review.
03
Typical Symptoms
Organisations that need this playbook usually recognise several of the following.
- Fulfilment turnaround is measured in days and reported as an average that hides a long tail.
- Technicians check licence availability in a spreadsheet maintained outside the SAM platform.
- Purchase requisitions are raised for software that already sits unused on leaver accounts.
- Approvals stall because the request form shows no cost, no entitlement position and no alternative.
- Deployment success is confirmed by the requester closing the ticket, not by Intune reporting back.
- The CMDB and the licence allocation record diverge from what is actually installed within a quarter.
- Restricted or per-core licensed software is available through the same self-service path as free tools.
- There is no reporting on first-time deployment success, so recurring package failures go unnoticed.
04
Business Risks
Business risks by domain, with the risk and its impact
| Domain | Risk | Impact if unaddressed |
|---|
| Operational |
Manual availability checks against a spreadsheet outside the SAM platform |
Fulfilment slows to the speed of a human lookup, and the check is skipped under pressure — which is precisely when duplicate purchasing happens. |
| Commercial |
Purchase raised by default rather than reuse checked first |
Licences already owned and unassigned are never reharvested, so spend grows with headcount even where the entitlement pool has capacity. |
| Compliance |
Restricted software fulfilled through the standard self-service path |
Per-core, export-controlled or use-right-constrained products are deployed without the specific approval the contract requires, creating exposure that surfaces only at audit. |
| Technology |
No deployment write-back from Intune to ServiceNow |
The CMDB and licence allocation records drift from reality, and every downstream reclaim, renewal and compliance report inherits the error. |
05
Operating Workflow and Reference Architecture
Operating workflow
11 stages, each producing a defined output. This workflow is specific to this
playbook; the category lifecycle on the
Software Value index is an overview of how the playbooks relate,
not how any one of them runs.
↔ Wide diagram — scroll horizontally, or use the
arrow keys once it has focus. A text description is available to screen readers.
Illustrative fulfilment workflow. The entitlement check sits before approval by design — validating availability while the request is in flight is what converts fulfilment into a reuse mechanism. Outcomes are not guaranteed.
Reference architecture
The systems, data and controls the workflow above runs on.
↔ Wide diagram — scroll horizontally, or use the
arrow keys once it has focus. A text description is available to screen readers.
Illustrative reference architecture. ServiceNow and Intune are used as the worked example; the same pattern applies to any ITSM and endpoint management pairing provided the deployment status callback exists.
06
Implementation Approach
A representative implementation sequences in 5 phases. Duration and overlap
vary with estate size, data quality and the number of source systems in scope.
Phase 1
Catalogue and policy foundation
Define what can be requested, by whom, and under what conditions. A catalogue without policy is a faster route to the same governance problem.
- Standard catalogue design. Build catalogue items per product and edition rather than a single free-text 'software request', so entitlement and cost can be resolved automatically.
- Request form design. Capture business justification, cost centre and intended use, and show the requester the cost and any approved alternative before submission.
- Software policy encoding. Classify products as self-service, approval-required or restricted, with the restriction reason recorded — per-core metric, export control, specific use right.
- Approval routing design. Route to line manager and, above a value threshold, to cost-centre owner, with the entitlement position visible in the approval notification.
Business value
Demand arrives structured and classified, which is the precondition for every automated check downstream.
Phase 2
Entitlement validation integration
Connect the catalogue to the entitlement pool so availability is a system answer, not a technician's lookup.
- Entitlement pool integration. Expose available, allocated and reclaimable counts per product to ServiceNow so the request can be validated in flight.
- Reservation logic. Reserve a licence at approval so two simultaneous requests cannot consume the same unit, with reservation expiry if deployment does not complete.
- Reharvest-first rule. Check the reclaimable pool — unassigned, leaver-held and inactive allocations — before any purchase path is offered.
- Purchase path. Where no licence is available, trigger an explicit procurement task with the shortfall quantity, rather than allowing a silent buy.
Business value
Reuse becomes the default and purchasing becomes an explicit, evidenced decision with a named approver.
Phase 3
Intune deployment automation
Automate delivery through the endpoint management channel that already governs the estate.
- Application packaging. Package Win32, MSI and Store applications with detection rules that reliably report success, since the callback is only as good as the detection logic.
- Assignment automation. Drive Intune assignment from the approved request — user group or device group as appropriate to the licence metric.
- Status callback. Return Intune installation status to the ServiceNow request record, and hold the request open until deployment is confirmed rather than closing at assignment.
- Retry and failure routing. Define retry behaviour and route persistent failures to a named queue with the device and error detail attached.
Business value
Delivery time collapses to the endpoint check-in interval, and failures become visible tickets instead of silent non-installs.
Phase 4
Write-back and record integrity
Close the loop. Without automatic write-back the pipeline is fast and the data is wrong.
- CMDB update. Update the CI installed-software relationship on confirmed deployment, with the request number retained as the source reference.
- Allocation posting. Post the licence allocation against user, device and cost centre so chargeback and reclaim have an accurate base.
- Reclaim on leaver and mover. Trigger allocation release from the joiner-mover-leaver process so the reclaimable pool stays real.
- Reconciliation check. Periodically reconcile allocations against discovered installations and route divergence to the exception queue.
Business value
The allocation record stays true to the estate, so reharvesting, renewal sizing and compliance reporting all rest on the same trusted base.
Phase 5
Measurement and continuous improvement
Report the pipeline's own performance and use it to remove the remaining manual touchpoints.
- SLA and turnaround reporting. Report median and 90th-percentile turnaround, not the mean, since the mean hides the tail that users actually experience.
- Automation rate tracking. Measure the share of requests fulfilled with zero manual touch and drive the exceptions to root cause.
- Package quality review. Track first-time deployment success per package and remediate the recurring failures.
- Reuse reporting. Report licences reused versus purchased as a standing figure — it is the clearest evidence of the pipeline's commercial value.
Business value
The pipeline improves against measured evidence, and the reuse figure gives finance a concrete number for what the automation is worth.
07
Technology Components
ServiceNow and Intune are used as the representative worked example because the pairing is common in enterprise estates and the deployment callback is well defined. The pattern transfers to any ITSM and endpoint management pairing that can report deployment status. Products are named as examples, not recommendations.
ITSM and workflow
- ServiceNow Service Catalogue
- ServiceNow Flow Designer
- ServiceNow CMDB
- Approval workflows
- Virtual Agent / self-service portal
Endpoint management
- Microsoft Intune
- Win32 app packaging
- Intune Graph API
- Entra ID user and device groups
- Autopilot provisioning
Licence and asset
- SAM entitlement and allocation store
- Reclaim and reharvest pool
- Software policy and use-right rules
- Joiner-mover-leaver integration
Reporting
- ServiceNow Performance Analytics
- Power BI
- Fulfilment SLA dashboard
08
Governance Considerations
Governance should be proportionate. The six areas below are the minimum set that has to be
explicit for this capability to hold up under internal review.
Ownership
A named fulfilment process owner accountable for SLA and automation rate; catalogue item owners per product family; a software policy owner accountable for the restriction classification.
Decision rights
Line manager approves need; cost-centre owner approves spend above threshold; the software policy owner is the only route to approving a restricted-software exception.
Policies
Software request policy, restricted-software policy, reharvest-before-purchase policy, and a joiner-mover-leaver policy that includes licence release.
Approvals
Manager approval on every request; cost-centre approval above a defined value; explicit procurement approval whenever the entitlement pool cannot satisfy the request.
Evidence
Full request audit trail — justification, entitlement position at approval, approver, deployment status and allocation posting — retained per the records policy.
Controls
Entitlement reservation to prevent double-allocation, policy gate on restricted products, deployment confirmation before request closure, and periodic allocation-to-install reconciliation.
09
Success Metrics
Primary KPI
Fulfilment turnaround time
Elapsed time from approved request to confirmed successful deployment, measured from the Intune status callback rather than from ticket closure.
< 4 hours median
Operational KPIs
90th-percentile turnaround
< 24 hours
The tail users actually experience, not the mean.
Requests within SLA
≥ 95%
Fulfilled inside the agreed target for their category.
Automation rate
≥ 85%
Requests fulfilled with zero manual touchpoints.
Manual touchpoints per request
< 0.2 average
Human interventions per fulfilled request.
First-time deployment success
≥ 95%
Installations succeeding without retry or intervention.
Failed deployment rate
< 3%
Assignments that never reach a successful install state.
Governance KPIs
Approval cycle time
< 8 hours median
Time from submission to approval decision.
Rejection rate
Tracked with reason codes
Requests declined, analysed for catalogue gaps.
Restricted-request compliance
100% through policy gate
Restricted products routed for specific approval.
Allocation-to-install variance
< 2%
Divergence between allocation records and discovered installs.
Value KPIs
Licences reused vs purchased
Tracked as a ratio
Requests satisfied from the reclaim pool.
User satisfaction
Measured per fulfilled request
Post-fulfilment survey score.
Fulfilment backlog
Zero standing backlog
Open requests past their SLA target.
Indicative targets
Every target above is an indicative KPI for a typical enterprise, intended to support
planning discussions. Baselines should be measured in the first operating cycle and targets
set from them. These are not benchmarks, commitments or achieved client results.
10
Positive Business Impact
Employees productive on day one
A new joiner's toolset is assigned and installed before their first check-in, rather than arriving midway through the first week.
Service-desk effort removed
Manual availability lookups, spreadsheet updates and chase emails disappear from the queue, releasing technician time to work that needs judgement.
Compliance controls applied consistently
The policy gate applies to every request, every time, including the urgent ones — which is exactly when manual processes are bypassed.
Licence reuse enforced before purchase
The reclaim pool is checked before any procurement path opens, so headcount growth stops automatically translating into licence growth.
Asset records that stay true
Automatic write-back keeps the CMDB and allocation record aligned to the estate, so reclaim and renewal decisions rest on current data.
No standing fulfilment backlog
With automation carrying the volume, the queue clears within SLA rather than accumulating a tail that gets escalated at quarter end.
Outcomes depend on estate, contracts, data quality and organisational context, and are not guaranteed.
11
Related Playbooks
Playbooks commonly delivered alongside, before or after this one.
Important — please read
This playbook describes a typical implementation approach and a representative operating
model. It is illustrative guidance, not a statement of results. Any figures, targets or
ranges shown are illustrative and are intended to support planning discussions rather than
to predict or promise an outcome. Outcomes are not guaranteed and depend on the estate,
contracts, data quality and organisational context of each engagement.
No client names, client data, engagement detail or confidential delivery material is
disclosed anywhere in this library. Technology named in these pages appears only as an
illustrative example of a capability category and does not imply a partnership,
certification or recommendation.
