Simple Service
ITSM on Microsoft 365, without the ConnectWise tax.
For MSP COOs, help-desk leads, and IT directors at managed services and internal IT shops.
ConnectWise and Autotask charge several times what a modern stack costs, for features most technicians never open. Simple Service is a help desk built on Microsoft identity: tickets with SLA policies and running numbers per tenant, clients and assets, a knowledge base, a Teams surface with adaptive cards and an approval flow, and a signed cross-product intake so every other product in the portfolio raises tickets in one place. The agent side proposes resolutions and evaluates them against guardrails; executing one against a customer system needs a named person to approve it, and that path is switched off until the delegated-access model is in place.
How to get Simple Service
Available on requestRunning in production and taking new customers. There is no self-serve trial or purchase on this one yet, so access is set up with us directly.
Where this stands
- Availability
- Available on request
What it costs
No published price yet. Pricing is set before this product opens.
Routes that are not open
- Direct trial with Simple Intelligence Not open yet
- Direct subscription from Simple Intelligence Not open yet
- Microsoft Marketplace Not published yet
- Sponsored subscription for member companies Not open yet
The PSA is the most expensive software an MSP never fully uses.
A ticketing system arrives with a quoting module, a project module, a procurement module, and a marketing module, and the technicians use the queue. The bill is per seat, the seats are everyone, and the parts nobody opens are the parts that make the contract hard to leave. Meanwhile the actual work happens in Teams, and gets pasted back into the ticket afterwards by whoever remembers.
A queue that sits where the work already happens.
Simple Service is tickets, clients, assets, SLA policies, and a knowledge base, reachable from a Teams card as well as a browser, with sign-in through the Microsoft account your technicians already have. Every other product in the portfolio raises its tickets into the same queue over a signed intake, so there is one help desk rather than one per product.
The agent proposes. Nothing executes without a person, and today nothing executes at all.
The resolution engine ranks candidate fixes and puts each one through guardrails before it could run: is the target inside this tenant and this client, has this candidate already run, is every verb in the plan one the product can actually perform, how wide is the blast radius, and is there a rollback. That path is switched off in production until the delegated-access model is in place, and this page would rather say that than imply a robot is already touching your customers' devices.
What works today, and what does not.
Simple Service runs in production on Azure with authenticated multi-tenant access, and access is arranged with us rather than self-served. The help desk itself is working software. The automated-resolution path is built and gated, and it is honestly not running yet.
Working today
- Tickets with a human-friendly running number scoped per tenant, statuses through the lifecycle, priorities, assignment, comments, and a channel recorded on the ticket
- SLA policies per priority with separate first-response and full-resolution targets and a business-hours setting, and a due time written onto the ticket
- Clients, assets across hardware, software, licence, contract, and virtual, and a knowledge base with search
- A Microsoft Teams surface: adaptive cards, ticket cards, an approval flow, and inbound handling
- Signed cross-product ticket intake, so every other SIG product raises tickets here over an HMAC-signed request with a replay window and a per-product secret, deduplicated on the source product's own idempotency key
- An MCP server with six tools where each call writes an audit row, including the failures
- Entitlements, a marketplace fulfilment path, and per-tenant isolation with assigned-only visibility
- Resolution proposals and predictive alerts generated from deterministic rules when the model paths are switched off, each carrying its provenance columns
Not yet
- Automated resolution does not execute. The engine proposes candidates and evaluates them against the guardrails, but the executor refuses to run any candidate while the feature flag is off, and it is off in production until the delegated-access model for customer tenants is finished. Treat the resolution panel as a recommendation surface, not as automation.
- There is no Intune or Graph inventory sync. An asset record has a field for the matching Intune device id, which is a place to put one, not a job that fetches them. Assets are maintained by people today.
- Acting inside a downstream customer tenant needs that tenant's own administrator consent, and until it is granted an attempted action records a consent error rather than doing anything. The delegated model that would carry an operator's just-in-time role into the customer tenant is specified and not yet built.
- There is no Simple Time integration for billable ticket work. Hours worked on a ticket do not cross into Simple Time, and any claim you have read otherwise, including on this site until today, was wrong.
- Self-serve signup is not open. Access is arranged with us.
- The Azure Marketplace offer is planned rather than published, so this cannot be bought through a Microsoft agreement yet.
- A Copilot surface is planned. Today this is a web application with a Teams surface alongside it.
Verified against the product on 2026-08-20.
The teams this was built for.
Running a help desk without paying for six modules you do not open
Tickets, clients, assets, SLA policies, and a knowledge base, with sign-in through Microsoft identity and no separate user directory to reconcile. The parts that are missing are the parts a service desk does not use daily, which is the point rather than an oversight.
Working the queue from Teams
Tickets surface as adaptive cards, and approvals have their own flow, so the conversation about a ticket and the record of it are in the same place. The channel a ticket arrived on is kept on the ticket, so nobody has to reconstruct where it came from.
One help desk for every product the business runs
Other products raise tickets into this queue over a signed request rather than by emailing a shared mailbox. Duplicate submissions collapse on the sending product's idempotency key, and the originating tenant and reporter survive on the ticket so somebody can be answered.
Reviewing what an agent would have done, before letting it do anything
Resolution candidates are visible with their guardrail verdict and their blast radius, which is derived from the plan rather than read from a field the model wrote. That is a useful review artifact in its own right while the execution path stays switched off.
From a request arriving to a ticket that closes.
Sign in with the Microsoft work account
Multi-tenant Entra ID sign-in, with the tenant on the token scoping every later query. Technicians use the account they already have, and leavers lose access when your directory says so rather than when somebody remembers to deprovision a second system.
Tickets arrive on a channel you can see
Through the web application, from Teams, or over the signed intake that peer products use. The channel is recorded on the ticket, and cross-product tickets keep the source product, the reporting user, and the tenant they came from.
The SLA clock starts from a policy, not a guess
An SLA policy for the priority sets a first-response target and a resolution target, with a business-hours flag, and the due time is written onto the ticket so it can be queried rather than recalculated on every screen.
The agent offers candidates, ranked
For an incident, the resolution engine proposes candidates with a confidence value and reasoning attached. With the model path switched off it proposes from deterministic rules, which is a narrower but predictable answer rather than nothing.
A person decides, and the guardrails decide whether they are allowed to
Before anything could execute, five checks run: tenant and client scope, whether this candidate already ran, whether every verb is one the product can perform, how wide the blast radius is, and whether a rollback exists. Anything wider than a single user or device requires administrative approval, and a tenant-wide action requires an explicit click rather than an approval inferred from a chat message.
What it does, and what it refuses to do.
A queue with the boring parts done properly
Ticket numbers run per tenant so two customers do not share a sequence. Status, priority, assignment, comments, and the arrival channel are all first-class columns rather than tags. SLA targets separate first response from resolution, because a desk that hits one and misses the other has a specific problem and a single number hides it.
Blast radius is derived, not believed
The candidate row does carry a declared blast radius, and the guardrails deliberately do not trust it, because it was written by a model reading ticket text a customer controls. The approval tier is computed from the plan's own steps instead. Without that, a plan could declare itself harmless next to a device-wipe step and route around the approval it needed.
Rollback is a requirement, not a field
A reversible action must carry a rollback plan to pass the guardrails, and a rollback must itself be reversible or it is a second destructive action using a reassuring word. Actions that cannot be undone are allowed to have no rollback plan, and in exchange they need elevated approval to run at all.
One help desk for the portfolio, over a signed edge
The cross-product intake verifies an HMAC over the timestamp and the raw body, rejects anything outside a five-minute window so a captured request cannot be replayed indefinitely, and binds the secret to the sending product so a forged sender fails verification. Repeated deliveries collapse on the sender's idempotency key.
An agent surface that records its failures too
Six MCP tools cover creating a ticket, moving its status, listing open work, checking SLA state, reading predictive alerts, and evaluating a resolution candidate against the guardrails. That last one reports a verdict and never executes, because the transport carries no user identity and execution requires a named person. Each call writes an audit row whether it succeeded or failed.
Where the tickets live, and who can act on them.
Postgres, tenant scoped in the query layer
Tickets, assets, and audit records are durable business records, so this is a persistent store. Every domain table carries a tenant id, and client-scoped records carry a client id as well, so an MSP's customers are separated inside the MSP's own workspace rather than only from other MSPs.
Two tenant boundaries, not one
The workspace tenant is the MSP. The client tenant is their customer. Anything that would act inside a customer's Microsoft environment authenticates against that customer's directory, not the workspace's, which is why it needs that customer's own administrator consent and fails with a recorded consent error until they give it.
No standing key to other people's tenants
The intended model is that an operator's own just-in-time delegated role carries into the customer tenant for the duration of an action, rather than the platform holding a permanent credential that can reach every customer. That model is specified and not yet built, which is a large part of why the execution path is off.
Runs on Azure, in the SIG subscription
Azure Container Apps behind Front Door, secrets in Key Vault reached through a managed identity, and model calls routed through Azure AI Foundry rather than a vendor SDK, so prompt traffic stays inside the Azure boundary.
What it connects to, and what is waiting on consent.
A name here is a system this product is built to work with, not a promise that the connection is live in your tenant. Where a connector carries a status label, that label is the current state. Anything that needs its own vendor registration, its own consent, or its own approval says so, and nothing on this page can be taken as available until it is confirmed for your tenant.
Microsoft
Across the portfolio
For your own systems
Not connected today
Reading data from an external system is not a way to sign in. Customer identity stays with Microsoft Entra ID, and no data source on this list authenticates a person.
Where each of these claims comes from.
How access works right now.
- How access starts
- A conversation first. We scope the evaluation with you and provision the tenant ourselves.
- Evaluation length
- Agreed when the evaluation is scoped, up to 45 days for a standard evaluation. A longer guided pilot is approved case by case.
- Payment details
- None collected to begin an evaluation.
What service leaders ask first.
Does it automatically fix tickets?
No, and anyone selling you that should be asked what happens when it is wrong. The engine proposes ranked candidates and runs them through guardrails, and the executor refuses to run any of them while the feature is switched off, which it is in production. When it is switched on, an action wider than one user or one device will still need a named person to approve it.
Does it pull our asset inventory from Intune?
Not today. An asset record has a field for the matching Intune device id, which is somewhere to put one rather than a job that fetches them. Assets are maintained by people. Earlier copy on this site said otherwise and it was wrong.
What would it take to let it act inside our customers' tenants?
Each customer tenant grants its own administrator consent, and until that happens an attempted action records a consent error and does nothing. The model we intend is that an operator's own just-in-time delegated role carries into the customer tenant for the duration of the action, rather than the platform holding a standing credential that reaches every customer. That is specified and not yet built.
Does ticket time flow into billing?
Not yet. There is no time entry handoff from a ticket to Simple Time. If billable ticket work is a requirement rather than a nice-to-have, say so early, because today it would be a manual step.
How does it compare to ConnectWise or Autotask?
It is smaller on purpose. You get the queue, the SLA policies, the clients and assets, the knowledge base, and a Teams surface. You do not get quoting, procurement, or a marketing module. If the modules you never open are what keeps you on your current contract, this is the wrong product. If they are what you resent paying for, it is worth a conversation.
Can other systems raise tickets here?
Yes, over a signed intake. The request carries an HMAC over the timestamp and body, is rejected outside a five-minute window, uses a secret bound to the sending system, and collapses repeat deliveries on the sender's idempotency key. That is how the rest of the portfolio raises tickets, and it is available for your systems too.
Can we buy it through our Microsoft agreement?
Not yet. The Azure Marketplace offer is planned rather than published, so there is no transactable listing. Access today is arranged directly.
Ten questions before you replace your PSA.
A short checklist for service leads weighing a platform move. It runs in the page, stores nothing, and prints if you want to take it into a meeting.
Before you replace your PSA.
None of these need a product to answer. Most service desks find that the honest answers explain the renewal quote better than the feature comparison does.
Nothing here is stored or sent. Tick boxes to work through it, or print the page and take it into the meeting.
What it connects to across the portfolio.
Simple Service is the support layer of SimpleOS, and the single help desk of record for the portfolio. Every other product raises its tickets here over a signed intake rather than each keeping a queue of its own.
How to start
-
Available on request Open
Running in production and taking new customers. There is no self-serve trial or purchase on this one yet, so access is set up with us directly.
Request access -
Direct trial with Simple Intelligence Not open yet
This product has no self-serve trial yet. Ask us and a person will set access up.
-
Direct subscription from Simple Intelligence Not open yet
There is no direct checkout for this product yet. Where a trial exists it converts to a paid subscription inside the product.
-
Microsoft Marketplace Not published yet
There is no transactable listing for this product yet, so it cannot be bought against a Microsoft agreement today.
-
Sponsored subscription for member companies Not open yet
The member sponsorship program is not open for this product yet.
Questions about evaluation length, extensions, or sponsored access are answered on the get started page.
Bring last month's ticket volume and your PSA invoice.
Those two things settle most of the question faster than a demo does. If the modules you are paying for are ones you use, we will say so.