After go-live, someone still has to watch it.
Application managed services means a partner runs your business systems after they go live: monitoring, fixing, updating and improving them under one SLA. QServices runs the ERP, the integrations and the AI agents we build, with response times by priority and a monthly report you can hold us to.
One team for the ERP, the integrations and the agents, so nobody points at somebody else.
Application managed services (AMS) is an arrangement where an outside team takes ongoing responsibility for running business applications after they go live: watching them, fixing incidents, applying vendor updates, making small changes and reporting on all of it against agreed service levels. For AI agents it adds something new: checking that the agent's answers stay as good as the day it launched.
Google's SRE book defines an SLA as "an explicit or implicit contract with your users that includes consequences of meeting (or missing)" the targets. Ours names those consequences.Microsoft's own support terms are clear about what they don't cover. That gap is most of what goes wrong in a real system.
| Issue | Microsoft support | QServices managed services |
|---|---|---|
| The platform itself is down | Yes. Severity A gets a response in under an hour, 24x7, if you stay engaged around the clock | We spot it, escalate it to Microsoft and run the workaround |
| Custom code and extensions | Referred back to the partner | Yes. We wrote most of it, and we fix it |
| Integrations between systems | Only the Microsoft side of the connector | End to end, from your bank or web store to the ERP |
| Corrupted or wrong data | Not corrected | Traced, fixed and reconciled |
| Issues they can't reproduce in standard Dynamics | Capped at up to 4 hours of effort | Worked until closed |
| AI agent answer quality | Platform availability only | Measured monthly against a fixed test set |
| Twice-yearly ERP updates | Released on schedule | Tested in a sandbox before they reach you |
From Microsoft's Dynamics 365 and Power Platform support overview, October 2026.
Response and resolution are tracked separately, and the clock only pauses while we're waiting on you, with the pause logged. When it's unclear, the ticket goes in at the higher priority.
Targets are set per client. For comparison: Microsoft answers Severity A in under an hour, and PwC's published application management service lists P1 at 30 minutes and 4 hours.
Alerts go to a person, not an inbox. Power Automate's own admin analytics lag by about a day, so real-time alerts run through Application Insights and Log Analytics.
You get it in the first week of every month, and we walk through it with you.
An agent can be up all month and still get worse. These are the extra terms we put in writing for every agent we run.
| Measure | What we commit to | Why it matters |
|---|---|---|
| Quality floor | A minimum score on a fixed set of real cases; falling below it is a P2 | Catches an agent that has quietly got worse |
| Drift check | Monthly comparison against the launch baseline | Models and data change under you |
| Eval rerun | After every model, prompt, knowledge or connector change, and after Microsoft updates | The most common cause of new errors is a change |
| Override rate | Tracked and reported, with a review when it climbs | Shows whether your team still trusts it |
| Unsafe action | Treated as P1: wrong action on live data, data exposed or harmful output | The incidents that matter most get the fastest response |
| Stop and roll back | A tested way to switch the agent off and restore the last good version | So a bad day stays small |
Based on Microsoft Foundry observability guidance (continuous and scheduled evaluation, red teaming) and the NIST AI Risk Management Framework. Copilot Studio transcripts in Dataverse are deleted after 30 days by default, so we set retention and export them for audit.
For systems we built, the handover is already done. For systems someone else built, we start by learning them properly.
We list every system, integration, agent and alert, and document what nobody wrote down.
You set the priorities, response times and coverage hours that fit your business.
Alerts on every flow and agent, sent to the on-call engineer, with dashboards you can see too.
Incidents, updates and small changes, handled to the SLA.
Our own agents triage alerts and draft incident notes. An engineer decides what happens next.
We go through the report together and agree what to fix, improve or retire.
You get a fixed monthly fee after we've seen the estate. No per-ticket charges.
Priorities defined by business impact, separate response and resolution targets for each, coverage hours, when the clock pauses, how breaches are reported and what happens when they occur. For AI agents add a quality floor, a drift check and an eval rerun after every change.
Usually as a fixed monthly fee sized by the systems, integrations and agents covered, the coverage hours and a change allowance. Avoid per-ticket pricing: it rewards the provider for more incidents, not fewer.
Monitoring, incident fixes, testing vendor updates before they reach you, small changes, user and permission requests, and a monthly report. On Business Central that includes checking extensions before the April and October major updates.
Who answers a P1 at 2 a.m., how they find out something broke before you do, whether they fix integrations end to end, how they handle custom code they didn't write, and what the last three monthly reports for a similar client looked like.
Run both in parallel for a few weeks, get the outgoing provider's documentation, credentials and open tickets in writing, and have the new provider shadow incidents before taking them over. Plan around 60 days for a full estate.
Track run success rate, response time, tool failures and cost per run, and score the agent regularly against a fixed set of real cases. Microsoft's Foundry guidance suggests looking into any run success rate under 95%. Rerun the test set after every model or prompt change.
It's handled as an incident: stop or roll back the agent, fix the data it touched, find the cause, add the case to the test set and rerun the evals before switching it back on. A wrong action on live data is a P1.
Tell us what you run, and we'll show you what watching it properly looks like.
Facts on this page checked on 22 October 2026.
Founder and CEO
Chief Sales Officer
Join our live webinar on Sept 24 and see five
ways to automate meetings, approvals, and
document search with tools already in your
tenant.
