01 / A question worth asking
Start with the service experience.
Where does work stall or leave the system?
Choose one frequent request and one important incident. Follow each from the employee’s first contact through fulfillment or resolution. Ask the people involved where they repeat information, wait for a decision, or work around the process.
- Bring evidence
- A sample request, its approval history, the queues it crossed, and feedback from the requester.
- A useful first move
- Fix the clearest point of friction before redesigning the whole catalog.
02 / A question worth asking
Make ownership visible.
Who owns the service—and who can change it?
Distinguish process ownership, service ownership, platform administration, and delivery responsibilities. A named owner needs the authority and time to make decisions, not just a field populated in a record.
- Bring evidence
- Named decision-makers, an escalation route, and an agreed review cadence.
- A useful first move
- Resolve one recurring decision that currently falls between teams.
03 / A question worth asking
Test the CMDB against a decision.
Can the data answer a question your team actually needs?
Pick a question such as which service a change could affect. Trace the relationships and validate them with the service owner. For CSDM work, agree the service-model scope and terminology before expanding the model across the organization.
- Bring evidence
- A service example, its key relationships, the source of each record, and the person responsible for exceptions.
- A useful first move
- Improve the data needed for that use case before pursuing record count as a measure of maturity.
04 / A question worth asking
Follow discovery through its lifecycle.
What happens when discovered information changes?
Discovery is a source of evidence, not the whole management process. Review identification, reconciliation, duplicates, stale records, and retirement. Compare ServiceNow Discovery, Ivanti Neurons, Configuration Manager, or other sources according to the role each plays in your environment.
- Bring evidence
- Source priorities, sample duplicates, stale-record handling, and documented ownership.
- A useful first move
- Choose one source or class and close the gap between discovery and trusted service data.
05 / A question worth asking
Inspect automation at its boundaries.
What happens when the next system is unavailable?
Review a workflow that crosses an integration. Check field mapping, approval rules, retries, failure visibility, and who handles an exception. Include identity and HR handoffs when onboarding or offboarding depends on multiple teams.
- Bring evidence
- A successful transaction, a failed one, and the documented recovery path.
- A useful first move
- Make exceptions visible and recoverable before increasing automation volume.
06 / A question worth asking
Prepare knowledge and ownership for AI.
Can you trust the information an assistant would use?
Start with a small, useful self-service scenario. Review source quality, access boundaries, handoff to a person, and how an incorrect answer will be reported and corrected. Agree the product capabilities and licensing before making the assistant part of a service promise.
- Bring evidence
- Reviewed knowledge, a clear escalation path, scenario-based tests, and a named owner.
- A useful first move
- Pilot a bounded use case with a defined review process.
07 / A question worth asking
Measure an outcome, then choose the next ascent.
What would your stakeholders notice if the change worked?
Agree a baseline and an outcome that reflect the work: fewer handoffs, a more reliable impact assessment, clearer ownership, or improved request completion. Review that evidence with service and product owners when deciding what to do next.
- Bring evidence
- A baseline, an accountable owner, a review date, and a short improvement backlog.
- A useful first move
- Choose a small number of priorities that your team can deliver and sustain.