THE PROBLEM
Context is scattered
A technician opens the PSA, the RMM, IT Glue, Teams and a remote tool to work one incident — and re-establishes the same context every time they come back to it.
One
AI service desk for MSPs · formerly MSPOne OS
Your technicians don't have a knowledge problem. They have a tab problem.
One puts one ticket in one window — the PSA record, the runbook, the endpoint data, the customer's call, similar tickets and an AI agent that can act on all of it. Your PSA stays the system of record. Nothing the AI proposes reaches a customer without a technician approving it.
Works with your PSA
Technician approval gate
Your model, your infrastructure
Full measurement layer
THE SHIFT
One workspace per ticket
Everything needed to resolve it is already on the page when the ticket opens — including the transcript of the call it arrived on.
THE CONTROL
AI that has to ask
Reads run freely. Every write stops, shows exactly what it would send, and waits for a person. That boundary is not a setting.
THE BUSINESS CASE
Where the margin actually goes
Handle time is not mostly spent fixing things. It is spent finding things, re-reading things, and writing down what was done. One targets the three of those directly, and instruments all of them so you can see whether it worked.
Finding things
Documentation, similar resolved tickets and the client's endpoint data are retrieved for the ticket before anyone asks. Your knowledge base stops being something people mean to search.
Re-reading things
Ask what a ticket is, what has been tried and what is outstanding, and get an answer grounded in the actual record — with the lookups shown, so it is evidence rather than an opinion.
Writing it down
Notes, time entries and customer updates are drafted from what actually happened on the ticket and the call, then approved in a click. The entry your invoice depends on stops being written from memory at 5pm.
Every one of those claims is measurable inside the product rather than in a slide. One keeps an append-only ledger of every interaction — who, which ticket, how long it took, how long somebody waited, and how it ended — so "did this change anything" is a report rather than an opinion.
GOVERNANCE
The question your clients will ask about AI
Not "is it clever". It is what can it do to my systems without a human deciding — and most answers to that are a policy document. One answers it structurally.
01
Reads are free, writes stop
Every tool declares whether it changes anything, once, in its own definition. A write returns its arguments and no result until a technician answers.
02
Auto-approve does not exist
It is not a setting an administrator can turn on, and a crafted request is normalised back. A settings table cannot weaken the product's only safety boundary.
03
A refusal is a first-class outcome
Declines are counted apart from errors everywhere in the reporting. A technician saying no is the control working, and a dashboard that called it a fault would train people to click through.
04
Your model, your infrastructure
Any OpenAI-compatible endpoint, including one you host. Per-tenant security groups decide which staff may send which client's ticket to which model.
Two things we tell you before you buy
Connecting an outside AI agent bypasses the gate. If you point One at an agent service that does its own tool use, that service's guardrails apply instead of ours. The product says so on the screen where you connect one, rather than leaving you to find out.
Integration maturity differs by vendor. ConnectWise Manage has been corrected against live servers. Several other adapters are built from published documentation and get verified against your instance during onboarding. We would rather tell you that now than during your first escalation.
WHAT YOUR TEAM GETS
Five areas, one product
The workspace
One ticket, a streaming conversation, and context panels that can be hidden entirely. Documentation, similar tickets, environment data, correspondence, timeline and the live call transcript.
The resolution agent
Give it a goal and watch it work: read the ticket, find the runbook, check the endpoints, propose a fix. Every step visible, every write gated, stoppable at any point.
Dispatch
The unassigned queue beside the technician roster, and a button that hands a ticket over. The PSA is written first, the offer is declinable, and a decline puts the ticket back.
Calls on the ticket
Transcription from your PBX, or from the technician's own machine for teams on Teams, Zoom or a softphone. The audio never leaves that machine — only the text does.
Escalation as a process
Your runbook, not ours: move the board, hand it to the senior queue, page the on-call rota through their own API, tell the account manager — in your order, with each tier doing something different.
Administration
Per-tenant credentials, encrypted at rest. SAML single sign-on with Entra ID or Duo. An audit log that records that a secret changed and never its value.
MEASUREMENT
Numbers that survive a QBR
A separate management area, readable by service delivery leadership without handing them the credentials to a customer's PSA. It reports percentiles, not averages — because a mean response time sits wherever the long tail drags it, and a team can halve it by answering easy tickets faster while every customer who actually waited waits just as long.
The median says what a typical customer experienced. The p90 says what the unlucky tenth did. The gap between them is a specific, fixable problem that an average hides entirely.
Overview
Headline figures for the period, each against the period before it.
Live board
What people say, whether they are signed in, and what they have actually done — never resolved into one number.
Response times
Every wait, split into what people wait for and what the software costs.
Reliability
Which vendors and tools are failing, how often, and what a technician saw when they did.
Activity ledger
The raw grain everything else came from, filterable and read-only.
CSV export
The same rows, for a board pack or a client QBR deck.
IT FITS WHAT YOU ALREADY RUN
No rip and replace
One is a layer on top of your stack, not a migration off it. Your PSA remains the system of record for every ticket, note, time entry and closure.
PSA
ConnectWise Manage
Datto Autotask
NinjaOne
RMM
ConnectWise Automate
NinjaOne
DOCUMENTATION
IT Glue
Your own vector store or RAG
endpoint
AI & TOOLING
Any OpenAI-compatible model
Any MCP
server
SAML SSO
Running more than one RMM after an acquisition is handled explicitly: several servers of the same vendor can be connected, and each client is routed to the one that actually holds them.
DELIVERED AS A SERVICE
You are buying an outcome, not a download
Str8In implements One against your systems, verifies every adapter against your own instances, and stays on it. There is no version of this where you are handed credentials and a wiki.
1
Assess
Your PSA, RMM, documentation platform, phone system and escalation runbook — and where your handle time actually goes today.
2
Connect
Credentials, identity mapping so each client resolves across all three platforms, single sign-on, and the model — hosted by you or by us.
3
Pilot
A small group of technicians on real tickets, with the measurement layer running from day one so the before and after are the same numbers.
4
Operate
Rollout, your escalation policy encoded, and ongoing adapter and model work as vendors change their APIs — which they will.
Multi-tenant from the ground up
Every setting, credential and ticket belongs to one MSP. Nothing crosses between them — including in background jobs, which is where that usually goes wrong.
It degrades, it does not break
A vendor outage takes out one panel with a reason attached, not the workspace. Every empty state says which kind of empty it is.
Documented properly
A user manual for your technicians and a technical manual for whoever owns the integration — both shipped, both current.
STRAIGHT ANSWERS
What owners ask first
Does this replace our PSA?
No, and it is designed not to. Your PSA stays the system of record — every note, time entry, status change, escalation and closure is written back to it, so the rest of your business sees no change in where the truth lives.
Can the AI touch a customer's system on its own?
No. It can read freely; every write stops and shows a technician exactly what it would send, in full, before anything happens. The one exception — connecting an outside agent service — is stated on the screen that does it.
Does our clients' data go to a third-party AI?
Only if you choose one. One speaks to any OpenAI-compatible endpoint, so you can run the model yourself and keep ticket content inside your own infrastructure. Security groups control which staff may use which model.
What happens when a vendor changes their API?
That is part of the service. Adapters are ours to maintain, and the product reports vendor failures with the vendor's own wording so the fix starts from a fact rather than a support ticket.
How do we know it worked?
The measurement layer runs from the pilot onward, so the before and after are the same figures from the same ledger — response and resolution percentiles, dispatch times, how much of the work the AI touched, and how often technicians declined what it proposed.
What does it cost?
It depends on seat count, which systems you run and whether you host the model. We will quote against your actual stack after the assessment rather than publish a number that would be wrong for most MSPs.
Bring one real ticket. We'll work it in front of you.
A walkthrough on your own stack beats a demo on ours. Thirty minutes, your PSA, and an honest answer about which parts of this are ready for your environment today.