Desktop and laptop energy is one of the few IT savings you can measure before and after with real numbers. The hard part is not the technology — it is the business case, the IT buy-in and the policy design.
If you are looking to cut both cost and carbon, desktops and laptops are an unusually good place to start. Unlike most sustainability work, this one is measurable: you can capture what your machines consume today, change how they behave, and measure the difference. Very few IT initiatives give you a before-and-after number that finance will accept without argument.
The work itself is not technically difficult. What makes these programmes fail is everything around the technology — the business case, the IT department’s willingness to deploy another agent, and policies that survive contact with people who work unusual hours. Here are the five things that actually determine whether it works.
Having decided to focus on energy, it is tempting to think you can get there by persuading people to shut down when they leave. This takes a lot of effort, and the effect decays. You may get some initial success, but over months most people drift back to what they did before, and the savings go with them.
The other tempting shortcut is the power management built into Windows itself. It exists and it works, but it is limited and inflexible. It does not cope well with the range of working patterns across a large organisation, and it gives you no central reporting, so you cannot prove what it saved.
Neither approach is wrong, exactly. They are just too weak to carry a programme on their own. If you want savings that are flexible, manageable and provable, you need central policy and central measurement.
You need two audiences to say yes: senior management and IT. Start with senior management, because the argument is simpler.
Insist that whatever you deploy can run in monitoring mode first — thirty days is usually enough — before any policy is enforced. That gives you an accurate baseline of what your machines currently consume, broken down by department and machine type. Everything after that is a genuine before-and-after comparison rather than a projection.
This matters more than it sounds. A business case built on vendor averages invites an argument about the averages. A business case built on thirty days of your own telemetry does not. It also tells you where the savings actually are, which is rarely evenly spread — a handful of departments usually account for most of the waste.
It is easy to treat IT buy-in as a formality. It is not. Plenty of power management projects have died because the IT team quietly declined to deploy the agent, and without deployment there is no programme.
Look at it from their side. They already have a long list of software to install and support. Another agent that delivers them nothing but extra work is an easy thing to deprioritise indefinitely. So make the benefits to IT explicit:
Once you have your stakeholders, identify the different kinds of user you actually have. A one-size-fits-all policy will not deliver the savings you modelled, and it will generate enough friction that people work around it.
Some teams run around the clock. Others leave long-running jobs going overnight by design. In a hospital, a machine that sleeps at the wrong moment is not an inconvenience — it is a safety problem. Shift patterns, on-call rotas, laboratory equipment and shared workstations all need different treatment.
So talk to every affected group and design policies around their real working hours. The flexibility is not a concession; it is what stops people disabling the thing. A policy people can live with saves more energy than a stricter one they circumvent.
The last consideration is user engagement, which is usually handled well during rollout and then forgotten entirely.
Ideally you want people taking the energy-saving action themselves — shutting down when they leave — with the central policy there as a backstop rather than the primary mechanism. A machine the user switched off saves more than one the policy put to sleep, and it saves it sooner.
One approach that works is making it visible and mildly competitive: score people on how often they shut down without the policy having to intervene, and recognise the best performers. It costs almost nothing, and it converts an invisible background policy into something people can see themselves doing well at.
To be clear about the boundary: CerteroX ITAM is not a PC power management product. It does not ship a power policy engine, and you should not buy it expecting one.
What it does provide is most of the surrounding evidence and control that a power programme depends on:
Put differently: if you run a power management programme, CerteroX ITAM is where you get a trustworthy device population, evidence of what is actually being used, and the ability to wake machines for maintenance. The power policy itself comes from elsewhere.
None of the five steps above is difficult in isolation. Broken down, this is a few weeks of stakeholder conversations, thirty days of measurement, and a policy design exercise. The programmes that fail almost never fail on the technology.
With sustainability reporting back near the top of the agenda, it is a good moment to look seriously at what device energy is costing you — in money and in carbon — and at how much of that you can measure rather than estimate.
Other posts covering the same ground.
Manual IT operations do not scale. A practical look at where automation pays back first — incident response, patching, provisioning and backup — and how to adopt it without creating isolated pockets of scripting.
Digital transformation is a philosophy with business intelligence at its heart, not a project with a completion date. Why it has no endpoint, what has to be true of your data before you can start, and what happens to organisations that decline.
The Certero AI Assistant lets authorised users ask plain-English questions of live asset, software and licence data. It is off until an administrator enables it, and it can never return data the person asking is not already entitled to see.
Everything argued above is checkable. Name the publisher, the billing account or the platform you would argue with, and the session is built around it — the reasoning attached, not a summary slide.
No gated download at the end of it.