A lot of DEX pilots go like this. The vendor installs the agent on fifty laptops, mostly belonging to the IT team. Everyone looks at the dashboards for a month. The dashboards are nice. The pilot gets extended, then extended again, and eventually it fades out without anyone deciding anything.
That isn’t the vendor’s fault, or yours. It’s what happens when a pilot doesn’t start with a question. Set one up like this and it ends with an answer instead.
Write the decision down first
Before anything gets installed, write one sentence: “At the end of this pilot we will decide whether to ___.” Buy it, replace the current tool, roll it out to one region, whatever it is.
Then write the three or four things that would make the answer yes. Be specific. “Better visibility” doesn’t count. “Tickets for our top three problems drop by a third on pilot devices” does.
Pick the problems from your tickets
Choose three to five problems that already cost you time and that you’d expect a DEX tool to help with. Pull the ticket counts for them over the last three months, so you have a baseline before the pilot begins. If you haven’t done that exercise before, we wrote up how in Before You Automate Anything, Read Your Tickets.
Use real devices, not IT’s laptops
IT’s own machines are the best-maintained devices in the company, used by the people least likely to raise a ticket. They’re a fine first ring. They’re a poor pilot.
Pick a group that looks like the rest of the fleet: one site, two or three departments, a mix of laptop models including some old ones, and people who work from home. A few hundred devices if you can manage it. Keep them clean of other DEX agents, so you’re measuring one thing at a time. Your current tool keeps running on the rest of the fleet while you compare.
Weeks one and two: measure, don’t fix
Let the agent collect data before switching anything on. Check that what it shows matches what you already know. If it says the Birmingham office has the worst Wi-Fi and everyone in Birmingham has been saying so for a year, good. If it surprises you, find out whether the surprise is real before going further.
Weeks three to six: switch the fixes on
Turn on fixes for your chosen problems. If you can, do it for half the pilot group and leave the other half as a comparison. Then track:
- Tickets for those specific problems, compared with your baseline and with the comparison half
- Whether the problems come back on the same devices
- What it took your own team to change an automation or build a new one, without the vendor in the room
- What the employees in the pilot noticed, if anything. Ask them.
Test the things demos skip
Demos show the good path. A pilot is your chance to try the rest:
- Who can approve an automation, and can you restrict that?
- How do you undo something that went wrong?
- Can you find, in a few minutes, everything that ran on one laptop last Tuesday?
- What happens on a laptop that’s offline?
- If you have Macs, does the tool do the same things there?
End it on the date you set
When the six weeks are up, write one page: what you set out to decide, what you measured, what happened, and the decision. If the answer is no, that’s a perfectly good result. An extended pilot with no decision is the only real failure.
If you’re comparing Nanoheal with what you have now, our switching page lists the questions we’d put to any DEX tool, with our answers, and the automation assessment will tell you how much of your ticket list we cover before the pilot starts.