Your EHR support model is undermining everything (and you don’t even know it)

Imagine this: a clinician files a ticket to fix a broken EHR (electronic health record) quick phrase. The issue is affecting hundreds of providers, but after three weeks, the only update is a cryptic message that someone, somewhere is "looking into it." Meanwhile, users grow frustrated, workarounds proliferate, and trust in the system erodes. Sound familiar?

We’ve spent years applying human-centered design to clinical workflows, patient experiences, and even EHR interfaces. But somehow, when it comes to the systems that sustain those experiences, like Application Management Services (AMS), we revert to old habits. Tickets, service-level agreements (SLAs), and reactive fixes rule the day. It’s time to change that.

AMS has traditionally been seen as a post-go-live necessity: a cost center meant to "keep the lights on." But when designed well, AMS can be so much more. It can become a strategic enabler of clinician satisfaction, operational efficiency, and innovation. In other words, it can be human-centered. And if it’s not designed with people in mind, AMS can actively erode the value of every other technology investment you’ve made.

The case for human-centered AMS

Support models are often built around SLAs, not actual human experiences. After a go-live, internal teams are typically stretched thin. They’re managing support tickets, tackling new builds, and responding to endless emails about what the system "should" do. This is when AMS partners often enter the picture; but without thoughtful design, these partnerships can fall into the same traps. Ticket backlogs grow. Issues that are urgent, but not considered critical, languish. Enhancement requests sit untouched because no one is sure who has the authority to move them forward. Clinician frustration festers as feedback disappears into a black hole. This isn’t just bad service. It’s bad design. And it’s avoidable.

Fast resolution of support tickets may seem like a success. But when speed masks superficial fixes, it can be even more damaging than delays. Meeting SLA deadlines may look good on paper, but if the root causes aren’t addressed, and generic solutions are applied instead of client-specific fixes, real problems persist. Too often, AMS teams push standard builds or workflows instead of understanding the client’s unique context. A better approach is to tailor solutions by first learning what makes each customer distinct, then building standards around them, not forcing them to conform to those of the AMS team.

What would AMS look like if it were designed like a great clinical workflow or digital patient journey? It would start with governance that includes clinical voices in regular decision-making, alongside IT and operations leaders. Prioritization would be shaped not just by business needs, but by frontline pain points. Support analysts wouldn’t just close tickets; they’d ask thoughtful questions about workflows, root causes, and what users are actually trying to accomplish. Every enhancement request or bug fix wouldn’t just be addressed but documented and folded into a larger strategy for ongoing system improvement. Most importantly, AMS would lighten the load on internal teams, not add to it, allowing them to focus on strategic initiatives instead of triage.

From reactive support to strategic momentum

When designed this way, AMS shifts from maintenance mode to momentum. We’ve seen support models generate surprising value when they start surfacing patterns rather than simply responding to noise. For example, a spike in help desk calls from nurses revealed confusion about new documentation requirements, prompting a streamlined workflow that cut charting time significantly. A rash of physician complaints about template usability led to a co-design session that overhauled note entry and dramatically improved satisfaction. Even manual reporting workarounds discovered through routine ticket reviews led to the development of new dashboards that eliminated hours of unnecessary labor. In each case, the AMS function wasn’t just putting out fires; it was detecting the smoke before anyone else noticed.

Redefining what success looks like

Of course, none of this is measurable if we’re only tracking traditional AMS metrics. Too often, organizations rely on data points like ticket resolution time, number of issues closed, and SLA compliance. While useful, these indicators miss the bigger picture. A human-centered AMS model requires a different lens. Are clinicians more satisfied with how the system supports their work? Are workflows improving incrementally over time? Are support teams focusing on the issues that matter, or just the ones that make the most noise? These are harder questions to answer, but they speak directly to outcomes that affect both quality of care and financial performance.

If you’re not sure whether your AMS model is working for your people, consider a quick diagnostic. Do your clinicians know how to get tech help? And when they do, does it actually help? Are your analysts still dealing with the same problems today that they faced a year ago? Is there a working feedback loop between support teams and end users? Can you name at least one meaningful workflow improvement in the last three months that came from an AMS insight? If not, it might be time to rethink your approach.

In recent podcast conversations, we explored what it would look like for technology support to feel "invisible and invaluable." Invisible, because users don’t have to think about it; things just work. Invaluable, because when support is needed, it’s intelligent, seamless, and rooted in an understanding of the user’s needs. That kind of experience only happens when support is designed as part of the overall user journey, not as a siloed function that operates in the background.

We design patient experiences with intention. We design digital front doors with empathy. We design clinical workflows to reduce clicks, friction, and burnout. It’s time we design support the same way. AMS, when done right, is not just a necessary function. It’s a lever for transformation. And it’s long past time we treated it that way.