IT Service Management
Most ITSM projects fail after go-live, not during it.
Configuration is only the beginning. Aevis aligns technology, people and processes to sustain adoption. We deliver lasting operational value—not just implementation.
- Operating model agreed before configuration
- Configuration data kept true by process
- Post-go-live backlog reviewed on a cycle
10
capability areas under one contract
ITIL 4
aligned, without being ceremonial about it
100%
of engagements include life after go-live
The challenge
What usually brings a service-management conversation to us.
Rarely the absence of a platform. Far more often the presence of one that everybody has quietly learned to work around.
A platform people route around
The real work is agreed in chat and recorded in the tool afterwards, if at all. The record exists to satisfy reporting rather than to run anything, so it is always slightly wrong and everybody knows it.
A CMDB that stopped being true
Configuration data was populated once at implementation and has decayed ever since, because nothing in the day-to-day process depends on it being right. It is now audited rather than used.
A process nobody agreed to
The workflow was configured from a template or from the previous employer of whoever led the project. It describes an organisation that does not exist, so compliance with it is theatre.
No owner for the platform itself
Configuration changes are made by whoever has admin rights and time. There is no design authority, no release discipline for the platform, and no way to say why a field exists.
Reporting nobody acts on
Dashboards report ticket counts and closure times because those are what the tool measures by default. No decision has ever been changed by one, and service owners keep their own spreadsheets.
Skilled people doing routine fulfilment
Access requests, software installs and standard changes consume engineering attention because approval and fulfilment were never automated against measured volume.
Systems that hold the truth separately
Monitoring knows what broke, HR knows who joined, finance knows what it costs and endpoint tooling knows what is installed. None of them tell the service platform, so people re-key between them.
Change control that cannot be evidenced
Changes are approved in principle and executed in practice, and reconstructing which was which for an auditor takes a fortnight of somebody senior.
The service
The practice first, then the platform that serves it.
Aevis implements and operates the service-management platform that carries your IT work — incident, request, problem, change, and the asset and configuration data underneath all four. That includes the workflow design, the integrations into the systems that already hold the truth, the reporting a service owner can act on, and the automation that removes the parts nobody should be doing by hand.
What we treat as the actual deliverable is the operating model: who owns which record, what a change genuinely requires before it proceeds, how configuration data stays true without an annual audit, and which decisions are the platform’s to enforce rather than a person’s to remember. A platform configured to serve an agreed model survives contact with the organisation. One configured to a template does not, which is why so many of these programmes are re-run every four years.
The practice is deliberately built to sit alongside our managed services, workplace and security practices. A security finding, a workplace request and an infrastructure change all become records in the same platform under the same governance, actioned by teams that are accountable inside the same contract. Where you run those practices yourself, the platform is designed to serve your teams on exactly the same terms.
- Engagement type
- Implementation, managed platform operation, or advisory
- Coverage
- Incident, request, problem, change, asset, CMDB
- Operating hours
- Platform operation and support, by agreement
- Governance
- Design authority, release discipline and data-quality reporting
Capabilities
Core capabilities.
Ten capability areas, contracted together or individually. Each one is an operating responsibility with a named owner, not a module we switch on.
ITSM implementation
Platform design, configuration and rollout across incident, request, problem and change — sequenced so each practice goes live only once the one it depends on works.
- Target design produced from the agreed operating model, not from a template
- Configuration held in a controlled release path with environments that match
- Phased go-live by practice rather than a single switchover
- Hypercare with a defined exit rather than an open-ended settling period
Process and operating-model design
The practices, roles and decision rights the platform is configured to serve — written down, agreed by the people who have to live inside them, and revisited.
- Record ownership and decision rights defined per practice
- Change types, risk model and approval authority agreed before configuration
- Escalation and major-incident procedure rehearsed rather than documented only
- Deliberate divergence from ITIL recorded with its reason, so it survives a review
IT asset management
Hardware, software and licence position tracked through the full lifecycle, reconciled against what discovery and procurement each believe.
- Asset register reconciled against discovery, directory and purchase records
- Software licence position tracked against entitlement rather than installs
- Lease, warranty and refresh dates driving a forecast instead of a surprise
- Disposal and end-of-life closed in the record, not merely in the store room
CMDB and discovery
Configuration data populated by discovery and kept true because the day-to-day process depends on it — the only mechanism that has ever prevented drift.
- Discovery deployed and its coverage reported as a number, gaps included
- Service maps built to the depth decisions actually need, and no deeper
- Relationships maintained through change records rather than by periodic audit
- Data-quality measured and reported as a service metric with an owner
IT operations management
Event, alert and availability management joined to the service records they affect, so monitoring output becomes work rather than noise beside the work.
- Event correlation and de-duplication before an incident is ever raised
- Alerts bound to configuration items and to the services above them
- Availability and service-impact reporting derived from records, not assembled
- Automated incident creation with the enrichment a responder actually needs
Workflow automation
Approval, fulfilment and routine request handling automated against measured volume, starting with whatever consumes the most skilled attention.
- Automation candidates ranked by measured volume and handling time
- Approval routing derived from role and risk rather than from a named list
- Fulfilment integrated into the systems that actually provision
- Every automation re-checked after a platform release for whether it still fires
Governance, risk and compliance
Control evidence, policy workflow and audit-ready reporting carried in the platform, so an audit is a retrieval rather than a reconstruction.
- Controls mapped to the records that evidence them as work happens
- Policy exceptions time-limited, owned and visible rather than tacit
- Risk register connected to the services and assets it refers to
- Audit extracts produced from the platform rather than assembled for the auditor
Service catalogue and portal
A request experience people use because it is built from what they actually ask for, rather than from the organisation chart of the team fulfilling it.
- Catalogue shaped from real contact and request volume
- Forms that ask only what fulfilment genuinely needs to proceed
- Published expectations per item, and the actual performance against them
- Knowledge surfaced at the point of request rather than filed behind it
Integration and data quality
Connections to monitoring, HR, finance and endpoint tooling, with reconciliation — so the platform stops being a place people re-key what another system already knows.
- HR-driven joiner, mover and leaver rather than email-driven
- Monitoring, endpoint and cloud inventory feeding the configuration record
- Finance and procurement reconciliation for asset and licence position
- Integration failures alerted as incidents, not discovered as stale data
Adoption, reporting and continual improvement
Metrics chosen because a decision depends on them, and a backlog that continues to be worked after the implementation project has closed.
- Reporting designed backwards from the decisions it is meant to inform
- Adoption measured by whether the record matches reality, not by login count
- Improvement backlog owned, prioritised and reviewed on a fixed cycle
- Platform releases assessed for what they let you retire, not only what they add
Outcomes
What changes for the business.
Operational changes rather than promises. Each one is visible in a service review, and each is stated as something that can be checked.
One record of IT work both sides accept
The business, the delivery teams and the auditors read the same records. Nobody maintains a private spreadsheet because the platform is where the work actually happens.
Configuration data that stays true between audits
The CMDB is maintained through change records rather than through periodic reconstruction, and its quality is reported as a metric with an owner.
Routine work fulfilled without engineering attention
Approval and fulfilment for the highest-volume requests run without a person in the middle, which returns the deep-knowledge people to the work only they can do.
Service performance argued from measures
Reviews are held against agreed measures and the decisions they support, rather than against anecdote and whichever incident is most recent in memory.
Change control that evidences itself
What was approved, by whom, on what basis and what actually happened are one trail. An audit response becomes a retrieval rather than a fortnight of senior time.
A platform that survives its own go-live
Design authority, release discipline and a worked backlog mean the configuration keeps pace with the organisation instead of decaying until the next replacement programme.
Delivery
How an engagement runs.
The same eight stages every Aevis engagement uses. The weight here sits unusually early — the design stage is where an ITSM programme is won or lost, and unusually late, because this is the practice most often abandoned at go-live.
Discovery
The platform in place, its configuration and customisation debt, current practice as actually performed rather than as documented, volumes by record type, and who holds which decision today.
OutputCurrent-state baseline and a volume profile
Assessment
Where the documented process and the real process diverge, configuration-data quality measured rather than assumed, integration and automation gaps, and the reporting nobody uses.
OutputGap assessment with data quality quantified
Design
The operating model agreed first — record ownership, decision rights, change types and risk model — and only then the platform design that serves it, including what will deliberately not be configured.
OutputAgreed operating model and target platform design
Implementation
Configuration built in a controlled release path, discovery deployed and its coverage reported, integrations connected with reconciliation, catalogue and knowledge populated from real demand.
OutputConfigured platform with populated data and tested integrations
Transition
Practice-by-practice go-live rather than a single switchover, with the people who will work inside it trained on the agreed model, and hypercare that has a defined exit.
OutputSigned acceptance per practice, and hypercare exit
Operations
The platform is administered, releases are assessed and applied, integrations are monitored, data quality is measured, and the catalogue and knowledge base are maintained as demand shifts.
OutputPlatform operated against published targets
Governance
Design authority meets on a cycle to hold the configuration to the agreed model, and service reviews cover performance, data quality, adoption and the improvement backlog.
OutputDesign decisions recorded and a periodic service review
Continuous improvement
Automation extended against measured volume, customisation retired where a platform release now covers it, reporting revised as the decisions it serves change, and drift corrected before it compounds.
OutputTracked improvement backlog and a customisation-debt trend
Engagement models
The same sequence, contracted three ways. The split of responsibility is written down before the service starts.
Implementation project
A bounded programme to design the operating model and implement the platform to it, ending at a defined acceptance point with your team operating it. Advisory support afterwards is optional and separately scoped.
Managed platform operation
Aevis administers and develops the platform on an ongoing basis — releases, configuration, integrations, data quality and the improvement backlog — against agreed service levels.
Advisory and assessment
A short engagement to establish why the current platform is not working, quantify configuration-data quality and customisation debt, and produce a remediation sequence your team can execute.
Platforms
Platforms and technologies.
We work in the platform you have chosen or are choosing. These are the categories and representative products we operate across.
Service management platforms
- ServiceNow
- Jira Service Management
- Freshservice
- Ivanti Neurons
Discovery and configuration
- ServiceNow Discovery
- Device42
- Lansweeper
- Microsoft Configuration Manager
Monitoring and event
- Datadog
- Dynatrace
- Zabbix
- Splunk ITSI
Orchestration and automation
- ServiceNow Flow Designer
- Power Automate
- Ansible
- Terraform
Identity and directory
- Microsoft Entra ID
- Okta
- Active Directory
- SailPoint
Endpoint and asset sources
- Microsoft Intune
- Jamf Pro
- Tanium
- Snow Software
Reporting and analytics
- Power BI
- ServiceNow Performance Analytics
- Tableau
- Grafana
Collaboration integration
- Microsoft Teams
- Slack
- Google Workspace
- Zoom
Why Aevis
Why Aevis for service management.
Service-specific differentiation. These are the reasons this practice is structured the way it is, not general company claims.
The operating model is the deliverable
Record ownership, decision rights and what a change genuinely requires are agreed before anything is configured. A platform built to serve an agreed model survives contact with the organisation; one built to a template gets replaced in four years.
We work inside these platforms every day
Aevis runs managed services, workplace and security operations inside service-management platforms for clients. The configuration is designed by people who will have to live in it, which is a different discipline from configuring it for someone else to.
Configuration data kept true by process
Drift is not solved by auditing more often. It is solved by making the day-to-day process depend on the data being right, and by reporting quality as a metric with an owner.
We argue for configuring less
Customisation is debt that has to be re-tested at every platform release. The design stage says explicitly what will not be built, and the improvement backlog includes retiring customisation the vendor has since covered.
The engagement does not end at go-live
Every implementation includes a defined hypercare exit, a design authority and a worked improvement backlog — because the failure mode of this practice is abandonment, not misconfiguration.
Reporting designed backwards from decisions
We start from the decisions a service owner has to make and build the measures that inform them, rather than publishing whatever the platform counts by default.
No licence resale, no incentive to over-scope
Platform licences are contracted directly between you and the vendor. We have no margin in how many licences you hold, which is deliberate and is worth checking in any competing proposal.
Divergence recorded with its reason
Where the design departs from ITIL we write down why. That is what lets a future reviewer tell a considered decision from an accident, which is the difference between a model that can be maintained and one that gets rebuilt.
FAQ
Frequently asked questions.
Answers are written to the same discipline as the rest of the page: they describe what the service does and, where the honest answer is "no provider can", they say that instead.
Do you only work in ServiceNow?
No. ServiceNow is the platform we are asked for most often and the one we operate most, but the practice is platform-agnostic and we work in Jira Service Management, Freshservice and Ivanti as well. If you have not yet chosen, we will help you choose on the basis of your volumes and operating model rather than recommend the one we hold the most certifications in.
Do you resell platform licences?
No. Licences are contracted directly between you and the vendor. We have deliberately kept no margin in your licence count, because an implementation partner with an incentive to expand it is being asked to give impartial scoping advice while holding a reason not to.
Should we fix what we have or replace it?
In most assessments we run, the answer is fix. Replacement is genuinely warranted when the platform cannot support the operating model you need or its vendor position has changed; it is not warranted because the current configuration is bad, since a replacement configured by the same process produces the same result four years later.
How long does an implementation take?
It depends far more on how quickly decisions get made than on configuration effort. The design stage needs the people who hold decision rights in the room; where that is available, a core implementation across incident, request and change moves substantially faster than one waiting on an operating model to be agreed by correspondence. We give an indicative sequence at the end of discovery.
Is a CMDB actually worth the effort?
Only to the depth that a decision depends on it. We map services to the level at which impact assessment, change risk and incident triage genuinely change their answer, and no deeper. Most failed CMDB efforts failed because they were modelled to a depth nothing consumed, which meant nothing kept them true.
Do we have to adopt ITIL wholesale?
No, and we would argue against it. ITIL 4 is a source of well-tested patterns, not a compliance standard. We use what fits, we say plainly where the design departs from it, and we record why — so a future reviewer can tell a deliberate decision from an accident.
Can our own team run the platform afterwards?
Yes, and many clients do. The implementation model ends at a defined acceptance point with your team operating the platform, and the design authority and improvement backlog are handed over as working practices rather than as documents. Ongoing operation by Aevis is a separate choice, not a dependency the implementation creates.
Can you migrate historical records from our current tool?
Yes, though we usually recommend migrating less than clients first ask for. Open and recently-closed records and the asset and configuration data need to come across; several years of closed tickets rarely justify the reconciliation effort, and can be retained in the legacy system read-only for the retention period instead.
Do we have to buy your other services to make this work?
No. The platform is designed to serve whoever operates inside it, including entirely your own teams and third-party suppliers. Where Aevis also runs your infrastructure, workplace or security operations, the benefit is that those handovers happen inside one governance model — but that is an argument for taking more, never a condition of this working.
How is the service reported and governed?
Design authority meets on a fixed cycle to hold the configuration to the agreed model. The service review covers performance against agreed measures, configuration-data quality, adoption measured by whether the record matches reality, customisation debt, and the improvement backlog with owners and dates.
IT service management enquiry
Start with what people actually do.
The most useful first conversation is not about the platform. It is establishing where the documented process and the real process have diverged, and whether anybody currently owns the difference.
- Response
- One working day, Monday to Friday