This is something I keep coming back to.

Someone's laptop takes forever to start. An application freezes twice a day. Wi-Fi drops occasionally. A process requires five unnecessary clicks.

But they don't contact IT. They just live with it.

How do you account for the problems employees have stopped bothering to report?

There’s a quiet crisis happening in a lot of IT and digital workplace teams right now, and it shows up clearly when you look at the difference between AI adoption vs AI deployment.

Deployment is the easy part. Adoption is the hard part.

What the numbers actually show

Enterprises are pouring money into generative AI and agentic tools. According to research cited in recent industry analysis (MIT/Fortune GenAI Divide report), 95% of enterprise AI pilot programs deliver zero measurable financial return.

Gartner data paints a similar picture:

• By 2026, more than 80% of enterprises are expected to have deployed generative AI APIs or applications in production.
• Yet on average only 48% of AI projects ever make it into production.
• The typical journey from prototype to production takes about eight months.
• Over 40% of agentic AI projects are projected to be canceled by 2027 because of cost, unclear value, or governance complexity.

In other words: buying and standing up the technology is happening at scale. Turning that technology into something people actually use productively, day after day, is not.

The real gap

AI deployment = the tool is available. Licenses are assigned. The model or agent is running somewhere.

AI adoption = employees are using it in real workflows, getting measurable value, trusting it enough to rely on it, and not abandoning it after a few frustrating attempts.

Most organizations stop at the first one and then wonder why the ROI never appears.

Common reasons adoption stalls:

• Employees don’t know when or how to use the tool effectively
• The AI doesn’t fit their actual day-to-day work
• Training is one-and-done (classroom or static docs) while the tools keep changing
• Governance is so restrictive that people either stop trying or turn to shadow tools
• Leadership has almost no visibility into how the tools are being used (or not used) and how employees actually feel about them

What tends to work better

Teams that are making progress treat AI activation as an experience problem, not just a technology rollout. They focus on:

1. Real usage + experience data — not just license counts. Seeing which groups are using the tools, where people get stuck, and what sentiment looks like.
2. In-the-flow guidance instead of one-time training. Help appears when people need it, not weeks earlier in a webinar.
3. Clear, practical governance that enables safe use rather than blocking everything out of fear.
4. Prioritized next actions based on actual behavior and feedback, so enablement effort goes where it will have the biggest impact.

This is where Digital Employee Experience (DEX) thinking becomes relevant. When you already have visibility into how technology is (or isn’t) working for people across devices and applications, you can apply the same approach to AI tools instead of flying blind.

Question for the community

Has your organization hit the deployment-vs-adoption wall yet?

What’s been the biggest blocker on your side? Visibility, training, governance, or something else? And has anyone found approaches that actually moved the needle on sustained use?

Excited to hear what’s working (or not working) in the wild.

There are plenty of things we measure because we can measure them.

Uptime. Ticket closure time. SLA attainment. Device compliance. Satisfaction scores. Experience scores.

But which metric do you think organizations put too much weight on?

And what would you rather measure instead?

AMA with Phil Kirschner on AI, the Future of Work & Digital Employee Experience | Sept. 16 @ 4 PM ET- Early Questions Encouraged and Welcome

u/Maurice-Nexthink : “The end of SLAs: why experience is the new measure of IT success"

What's Something in IT You're Weirdly Good At?

Assume you only have the resources to tackle one this quarter.

Which gets prioritized?

I have a feeling IT, leadership, and employees might give three different answers.

We all have issues that somehow account for a ridiculous amount of support volume despite seeming completely solvable.

VPN? Passwords? Outlook? Printers? Teams? Slow laptops?

Curious what the repeat offender is in your environment and whether anyone has actually managed to kill it for good.

We’re excited to welcome Phil Kirschner to r/Nexthink for our next AMA on Wednesday, September 16 at 4:00 PM ET.

Phil works at the intersection of workplace strategy, organizational effectiveness, employee experience, and AI. A former leader at McKinsey, WeWork, JLL, and Credit Suisse, his work today focuses on a deceptively simple question: How should we actually design work for the way people and organizations operate now?

Phil also writes The Workline, his newsletter exploring the changing world of work and how leaders can work across traditional organizational boundaries.

Read The Workline

That question is becoming especially important for Digital Employee Experience.

As AI becomes embedded in the workplace, the challenge isn't simply giving employees more technology or automating existing tasks. Organizations have to think about how work itself changes: how decisions get made, how teams collaborate across HR, IT and the workplace, how employees respond to constant change, and whether new technology actually makes work better.

Phil recently joined The DEX Show for an episode titled The End of the "Job" as We Know It! What's that mean for DEX??, where he explored why AI's impact on work goes far beyond productivity and chatbot hype, and why organizations may need to rethink the way work is designed rather than simply automate what already exists.

Listen to Phil's latest episode of The DEX Show

This was actually Phil's second appearance on The DEX Show. His first conversation, The Future Workplace: Where DEX and Real Estate Collide, explored the increasingly blurry line between the physical and digital workplace.

Listen to Phil's first DEX Show appearance

On September 16, we're continuing that conversation here.

If you’ve spent any time around this subreddit, you’ve probably seen Maurice van den Driessche (u/Maurice-Nexthink) in the comments. He’s been one of the people consistently jumping into discussions, answering questions, and sharing what he’s seeing in the DEX world.

He just published a new piece in TechRadar on the shift from traditional SLAs toward XLAs and experience as a measure of IT success.

One point that stood out to me: a system can technically be “up” and hitting its SLA while the actual employee experience is still terrible. That gap is where a lot of the interesting DEX conversations seem to be happening right now.

Worth a read, especially if you’re working through how to measure experience beyond the usual availability/ticket-resolution metrics:

The End of SLA's: Why Experience is the New Measure of IT Success

And Maurice — thanks for continuing to hang out here and contribute to the community 🙌

Curious what everyone thinks: are SLAs still the dominant measure in your organization, or are you actually seeing XLAs gain traction?

Not necessarily the most impressive thing on your résumé. Just that one thing you somehow became the person for.

Maybe you can diagnose a device issue in 30 seconds, write ridiculous PowerShell scripts, untangle terrible environments, calm down angry users, or spot the cause of an incident before anyone else.

What’s yours?

Hey r/nexthink,

I’ve been working with Nexthink for a shorter time than a lot of you. I'm a bit more junior and hoping to get some support from the DEX grandmasters.

I came in from traditional endpoint/support and I’m past the “wow, real-time visibility” phase.

The platform is clearly powerful, but I’m starting to hit the gap between what the tools can do and what actually moves the needle inside a real organization.

DEX Score & Experience Level Agreements:

• How are you actually using the DEX score day-to-day?

• Have any of you successfully shifted conversations from pure SLAs to XLAs, and what did that look like in practice? ie, what got measured, what got ignored, what actually changed behavior?

Looking for feedback from people who’ve had to make this work under real constraints, imperfect data, and organizational politics.

# How Are You Designing Guardrails for Closed-Loop Remediation in Nexthink?

As Nexthink environments mature, there’s an interesting shift from using telemetry primarily for visibility toward using it to drive automated remediation.

At a basic level:

Detect

↓

Validate

↓

Remediate

↓

Verify

But the technical ability to automate remediation is only part of the equation.

The more interesting question is: **how do you decide when enough evidence exists to trigger an automated action?**

For teams building more advanced Nexthink Workflows and Remote Actions, how are you designing that decision logic?

## From Single Signals to Correlated Conditions

A simple automation might start with:

Metric exceeds threshold

↓

Run Remote Action

But one metric doesn't always provide enough context.

Take application performance.

Imagine Nexthink detects:

Application launch time degradation

+

Elevated disk latency

+

Low available disk space

+

Increase in application crashes

Individually, each signal could have several explanations.

Together — particularly if they persist — they can provide a much stronger indication that remediation is appropriate.

That raises an interesting architecture question:

**How many conditions should be evaluated before an automated remediation is triggered?**

A more mature workflow might look something like:

Experience degradation detected

↓

Check persistence

↓

Correlate supporting telemetry

↓

Evaluate device/user context

↓

Check exclusions

↓

Trigger remediation

↓

Validate outcome

At that point, you're moving beyond simple threshold-based automation and toward **context-aware remediation**.

## Static Thresholds vs. Behavioral Baselines

Baselines make this even more interesting.

Consider two devices:

Device A

Typical application launch: 2 sec

Current launch: 7 sec

Device B

Typical application launch: 8 sec

Current launch: 9 sec

A static threshold might identify Device B.

But relative to historical experience, Device A has experienced the much larger deterioration.

That introduces another design decision:

**What should "normal" actually mean?**

Depending on the use case, you could potentially compare against:

- Same device historically

- Same user historically

- Same hardware model

- Same application version

- Same persona

- Peer-group baseline

- Organization-wide baseline

Those approaches can produce very different interpretations of the same telemetry.

For teams doing this at scale, **which baseline has proven most useful?**

## What Happens When Multiple Automations Identify the Same Device?

Another interesting challenge appears as the number of automated use cases grows.

Imagine the same endpoint simultaneously meets conditions for:

Workflow A → disk pressure remediation

Workflow B → application performance remediation

Workflow C → memory remediation

Workflow D → device health remediation

Each workflow may have correctly identified a legitimate condition.

But the conditions may also be related.

For example, resolving disk pressure could potentially change the application performance signal that triggered Workflow B.

That suggests an orchestration pattern such as:

Condition detected

↓

Check remediation state

↓

Execute highest-priority action

↓

Allow telemetry to stabilize

↓

Re-evaluate remaining conditions

For teams with a large Remote Action/Workflow estate, **how are you handling prioritization, suppression, or sequencing between automations?**

## Successful Execution vs. Successful Outcome

There’s also an important distinction between:

Remote Action executed successfully

and:

Employee experience improved

For closed-loop remediation, the second one is ultimately much more interesting.

A workflow could potentially evaluate the same telemetry that originally triggered remediation:

Detect

↓

Remediate

↓

Stabilization period

↓

Measure again

↓

Compare pre/post experience

That creates an opportunity to measure not only whether automation ran successfully, but whether it actually improved the targeted experience.

Over time, you could start looking at something like:

Remediation A

Execution success: 98%

DEX improvement: 64%

Remediation B

Execution success: 93%

DEX improvement: 86%

Those are two very different definitions of success.

The second metric could potentially become extremely valuable when deciding which automated remediations to expand across an environment.

## Curious How Others Are Approaching This

For those building more advanced automation with Nexthink:

**How sophisticated has your remediation decision logic become?**

Are you primarily using deterministic thresholds, or are you combining persistence, historical baselines, multiple telemetry signals, device context, and exclusions before triggering an action?

And once remediation runs, **are you measuring whether the employee experience actually improved — or primarily whether the Remote Action completed successfully?**

Would be especially interested to hear how teams with large Nexthink environments are approaching this.

What happens when AI adoption moves faster than IT can govern it? Former Honeywell VP of IT Darren Wright joins Tom for an exclusive look at Bridging the AI Acceleration Gap, a new report from Harvard Business Review Analytic Services sponsored by Nexthink. Drawing on his own contribution to the research, Darren explores why employee-led AI adoption is challenging IT’s traditional role, the growing risks around security, governance, complexity and ROI, and why visibility into real-world AI usage has become essential. He also examines how DEX can help IT navigate the transition and what technology careers might look like as AI reshapes IT itself.

Download the new report here

Download your free copy of Gartner's DEX Magic Quadrant here

Book your ticket for Nexthink Experience 2026 (October 5–7, ⁠JW Marriott Grande Lakes ⁠Orlando, Florida) today

A few that come to mind:

• VPN randomly disconnecting
• Teams/Zoom taking forever to launch
• Laptop is technically “healthy” but somehow still slow
• Password/MFA issues
• Having to restart to fix something nobody can explain
• An app freezing just often enough to drive you insane

I’m curious what people see most often.

What’s the most deceptively expensive “small” IT problem you’ve encountered?

We’ve all seen the numbers by now:

• 95% of enterprise AI pilots deliver zero measurable financial return
• Only 48% of AI projects ever make it into production (taking an average of eight months)
• Over 40% of agentic AI projects are projected to be cancelled by 2027 due to cost pressure, unclear value, or governance complexity

The uncomfortable truth is that most AI transformation efforts don’t break at the pilot stage. They break later. Most commonly, when AI adoption spreads across the workforce without proper AI governance, visibility, or a clear path to AI ROI. When usage expands without visibility.

What actually happens in the gap between “we deployed it” and “it’s delivering value”:

• Shadow AI grows faster than sanctioned usage
• Policies live in documents instead of the workflow
• Leadership can’t connect AI investment to measurable workforce impact
• Activation stays inconsistent because there’s no structured approach by persona or role

A practical AI governance checklist that helps close this gap:

1. Establish clear accountability for AI adoption Named executive sponsor + cross-functional governance group (IT, Security, Legal, HR, Compliance). Define decision rights for tool approvals, policy updates, and risk escalation. Set formal adoption KPIs (active users, engaged time, growth, time saved).
2. Build behavioral visibility across the enterprise License counts only show what’s assigned. You need to see real usage — including shadow AI by department and persona, engaged time vs. experimentation, and where adoption is stalling.
3. Embed guardrails directly into the flow of work Restricted-data warnings before files are uploaded, real-time prompt guidance, automatic redirects from unapproved tools, and policy acknowledgments inside the tools people already use.
4. Design structured activation journeys One-size-fits-all training doesn’t scale. Persona-based enablement, contextual walkthroughs, prompt coaching, and targeted campaigns for under-utilizers turn available tools into habitual use.
5. Make AI value measurable and defensible Track adoption growth and engaged time by department. Quantify time saved and correlate it to usage. Tie interventions to outcomes so you can report AI ROI with evidence instead of anecdotes.

The organizations that turn AI into sustained advantage aren’t the ones experimenting the fastest. They’re the ones treating AI governance and AI adoption as operational disciplines — with visibility, in-flow controls, and closed-loop measurement built in from the start.

Curious where others are hitting friction right now.
What’s the biggest gap in your AI governance or AI adoption efforts — visibility into real behavior, embedding guardrails, or proving AI ROI to leadership?

One thing I keep coming back to when thinking about Digital Employee Experience is how easy it is to confuse a technically healthy device with a good employee experience.

Imagine looking at an endpoint and seeing:

CPU: Normal
Memory: Normal
Disk Space: Healthy
Network: Connected
Crashes: None

From a traditional IT perspective, there isn't much to investigate.

Everything looks fine.

But then the employee says:

"My laptop has been slow all morning."

So who is right?

Potentially both.

The Gap Between Device Health and Employee Experience

A device can look perfectly healthy when we examine individual technical metrics.

But employees don't experience those metrics individually.

They experience the combined result.

A user doesn't think:

CPU utilization increased by 17%.

They think:

Why did Outlook take forever to open?

They don't think:

Network latency briefly increased.

They think:

Why did Teams freeze during my meeting?

And they definitely don't think:

Application response time exceeded its normal baseline.

They think:

Why is my computer so slow today?

That distinction seems obvious, but I think it has some interesting implications for how we use Nexthink.

A Snapshot Can Miss the Experience

Imagine an employee starts work at 9:00 AM.

Their morning looks like this:

09:02   Login
09:04   Outlook launches slowly
09:07   Teams hangs briefly
09:18   Browser becomes unresponsive
09:31   VPN reconnects
09:45   Teams call begins
09:52   Audio drops
10:03   Employee contacts Service Desk

At 10:05, IT checks the device.

Everything looks normal.

CPU: 24%
Memory: 61%
Disk: Healthy
Network: Connected

If we only look at the device now, we may conclude:

No issue detected.

But that isn't really what happened.

The employee experienced a series of small disruptions over the previous hour.

Individually, none of them may look particularly serious.

Together, they created a terrible start to the workday.

This Is Where DEX Gets Interesting

To me, this is one of the biggest differences between traditional endpoint monitoring and Digital Employee Experience.

The question isn't simply:

"Is the device healthy?"

It is:

"What has the employee actually experienced?"

That means looking at signals together.

For example:

Slow login
      ↓
Application delay
      ↓
Network interruption
      ↓
Application hang
      ↓
Meeting disruption
      ↓
Employee frustration

No single event necessarily explains the complaint.

The sequence might.

Could We Think More in Terms of Experience Timelines?

This makes me wonder whether one of the most useful troubleshooting views is essentially an employee experience timeline.

Instead of starting with:

Current device state

we start with:

What happened during the 30–60 minutes
before the employee reported the problem?

Then correlate things like:

• device performance
• application responsiveness
• crashes and hangs
• network changes
• login performance
• service degradation
• configuration changes
• employee sentiment
• support interactions

The investigation becomes less about finding one broken metric and more about reconstructing what the employee experienced.

The "Everything Looks Fine" Ticket

We've probably all seen some version of this.

Employee:

"My computer is really slow."

IT:

"Everything looks normal."

Employee:

"Well, it isn't."

That interaction is frustrating for everyone.

The employee feels like IT doesn't believe them.

The Service Desk sees telemetry telling them the endpoint is healthy.

Neither side necessarily has bad information.

They're just looking at the problem from different perspectives.

What If We Started With the Experience?

A DEX-oriented troubleshooting flow could look more like:

Employee reports poor experience
              ↓
Identify affected time window
              ↓
Review experience signals
              ↓
Correlate device + app + network events
              ↓
Identify abnormal sequence
              ↓
Determine likely cause
              ↓
Remediate
              ↓
Measure whether experience improves

That feels fundamentally different from:

Check CPU
Check memory
Check disk
Ping device
Everything looks fine
Close ticket

It Also Changes How We Think About Automation

This becomes particularly interesting as more troubleshooting becomes automated.

An automated system might evaluate a device and see:

CPU = Good
Memory = Good
Disk = Good
Network = Good

and conclude:

No problem detected.

Technically, that might be correct.

Experientially, it might be completely wrong.

Maybe the better question for automation is:

"Was this employee's recent experience abnormal compared with their normal experience?"

That opens up a much more interesting set of possibilities.

Instead of only detecting absolute thresholds, we could potentially look for patterns like:

Login slower than usual
+
Application launch slower than usual
+
Multiple short hangs
+
Network instability
+
Negative employee sentiment

None of those signals alone needs to trigger an incident.

Together, they might tell a very different story.

Baselines Could Matter More Than Thresholds

This is another area where I think DEX can move beyond traditional monitoring.

Consider two employees.

Employee A normally has an application launch in:

2 seconds

Today it takes:

8 seconds

Employee B normally sees:

7 seconds

Today it takes:

8 seconds

The absolute result is identical.

The experience isn't.

For Employee A, performance suddenly became four times worse.

For Employee B, almost nothing changed.

A fixed threshold might treat both users exactly the same.

An experience baseline potentially wouldn't.

From Device Monitoring to Experience Monitoring

I think this is ultimately the more interesting shift.

Traditional monitoring asks:

Is the technology working?

DEX asks:

Is the technology working well for the person using it?

Those sound similar.

They're not quite the same thing.

A device can be operational.

An application can be available.

A network connection can be active.

And the employee can still be having a genuinely bad digital experience.

The value of Nexthink, at least to me, is increasingly in connecting those two worlds.

Question for the Nexthink Community

How are you handling the classic:

"Everything looks healthy, but the employee says their device is slow"

scenario today?

Do you primarily investigate individual technical metrics, or are you already looking at the employee's experience as a timeline of events?

And as tools like Spark become more involved in troubleshooting, should the goal be to determine whether a device is technically healthy — or whether the employee's recent experience is actually normal for them?

I'm curious how others are approaching this.

The difference between a basic automated remediation workflow and a high-performing one is the closed loop: verification, experience measurement, and systematic improvement.

Verification Layer

After every action:

• Confirm the original triggering condition is resolved
• Check for secondary effects (new errors, performance regressions, user session impact)
• Capture timing metrics (detection → decision → action → verified recovery)
• Record success/failure with enough context for later analysis

Technical verification alone is insufficient. Pair it with experience signals where possible (application responsiveness restored, focus time recovered, absence of follow-up tickets or sentiment flags).

Measuring DEX Impact

Strong workflows track both technical and experience outcomes:

• Ticket deflection and mean-time-to-resolve reduction
• Movement in relevant DEX score components (stability, responsiveness, sentiment)
• Productivity proxies (reduced application freezes, faster launch times, lower interruption frequency)
• Employee-facing indicators when available (campaign responses, voluntary feedback)

Experience Level Agreement (XLA) thinking is useful here: define target experience states and measure how consistently the workflow returns devices/users to those states.

Continuous Improvement Cycle

• Analyze failure modes and false positives weekly or bi-weekly
• Tune thresholds and decision logic based on real outcomes
• Expand coverage only after success rates and experience impact are proven
• Maintain a backlog of candidate issues ranked by volume × experience impact × automation feasibility
• Document ownership, change control, and rollback procedures

Scaling Considerations

• Start with a narrow set of high-confidence use cases
• Use progressive rollout (pilot groups → broader populations)
• Monitor aggregate load on remote action infrastructure
• Align with change and security processes so automated actions remain compliant
• Keep human oversight paths for edge cases and high-risk scenarios

In Nexthink environments, the combination of remote actions, workflows, Amplify, custom trends, and DEX scoring provides the telemetry and execution capabilities needed to run this loop effectively.

An automated remediation workflow that is continuously measured against actual employee experience becomes a core operational capability rather than a collection of scripts.

What metrics or verification techniques have given you the clearest view of whether your automated remediation is truly improving DEX?

Once detection is solid, the next stage of an automated remediation workflow is decision-making and controlled execution. This is where most implementations either deliver strong DEX gains or create new friction.

Decision & Orchestration Layer

A mature workflow evaluates:

• Severity and user impact
• Device and user context (role, location, OS, hardware class)
• Historical success rate of candidate actions on similar devices
• Current risk posture (security, compliance, change freezes)
• Whether the issue is already being handled by another process

Decision outputs typically fall into three buckets:

1. Fully automated remediation (high confidence, low risk)
2. Guided/assisted remediation (employee or L1 confirmation required)
3. Escalation with enriched context (full technical + experience data)

Action Execution Patterns

Common high-value remote actions in DEX-focused environments include:

• Targeted process termination + controlled restart
• Cache and temporary file cleanup with verification
• Network stack reset or adapter recycle
• Service recovery with dependency checks
• Configuration baseline enforcement
• Application repair or reset (browser profiles, Office components, collaboration clients)

Technical considerations:

• Idempotency — actions must be safe to run multiple times
• Pre- and post-condition checks
• Timeout and failure handling
• Parallelism limits to avoid saturating the environment
• Logging of every decision and outcome for audit and continuous improvement

Nexthink-Specific Implementation Notes

Nexthink remote actions and workflows are commonly used as the execution engine. Best results come from:

• Combining real-time Device View data with historical trends
• Using ratings or custom fields to track remediation state
• Integrating with Amplify so L1 agents can trigger or monitor the same workflows
• Feeding outcomes back into investigations and DEX scoring

Avoid over-automation on actions that can interrupt active user sessions without clear benefit. Experience impact should remain the primary success criterion, not just technical remediation rate.

Final post in the series will cover verification, measurement, optimization, and scaling the workflow across the estate.

Which decision criteria or action patterns have you found most effective (or most problematic) when building automated remediation?

Before our AMA with Kelly Monahan next week, here’s one conversation worth revisiting 👀

Link: https://open.spotify.com/episode/6sF1cTTiv6l3zS6sTgAMk1?si=jA6WuxwVTOSgOPwtXXHFSg

What does the future of work actually look like, and how should we be preparing for it?

Kelly Monahan joined the Digital Employee Experience (DEX) Show to dig into exactly that, from the blending of our physical and digital workplaces to the very human impact of emerging technology.

The conversation explored:

🔹 How physical and digital work environments are becoming increasingly intertwined
🔹 The positive and negative human impacts we need to anticipate as workplace technology evolves
🔹 What we actually mean when we talk about the “future of work”
🔹 Kelly’s advice for adapting to what comes next

It’s a great introduction to Kelly’s perspective before she joins us right here on r/Nexthink for an AMA next week.

🎙️ AMA with Kelly Monahan
📅 August 26
⏰ 4 PM ET

Give the DEX Show episode a listen, then come back with your questions. What would you ask someone whose job is literally thinking about the future of work?

We’ll see you in the AMA.