Product roadmap
What we are building,
and how we decide.
Help MSPs see an issue in context, know who owns it, act with control, and check the result. This page shows where each part of that stands today, with honest status labels instead of promised dates.
Only items marked Shipped are available today. Last reviewed September 2026.
How we decide
Evidence first. Then the next step.
01
Start from real operator work.
Priorities come from the workflows MSP operators bring us: where context is missing, where ownership is unclear, and where technicians repeat work.
02
Measure the outcome, not the activity.
We judge a change by what happens to the work: how quickly an issue is owned, whether the fix holds, and how much technician time it takes. Where we do not have that evidence yet, we say so.
03
Integrate before we rebuild.
If a tool you already trust does the job, we connect to it first. A native option comes later, and only when partner demand and measured results support it.
Three goals, in order
Each goal builds on the one before it.
01
Reliable daily operations
An issue is detected, owned, acted on, checked afterward, and reopened if it comes back.
02
Connected, governed operations
Stable APIs, the integrations partners actually run, and AI assistance that stays inside the permissions you grant.
03
Enterprise-ready operations
Proven at larger scale with documented recovery and trust evidence.
Status labels. Shipped: running on production today. In verification: built, and being checked by someone who did not build it. Building: being worked on now. Planned: designed and sequenced. Exploring: evaluated only if operator evidence supports it.
Now
Making today's product dependable.
IN VERIFICATION
Launch readiness and security hardening
Every open high-priority security and reliability item is closed, or accepted in writing with the reason recorded, then rechecked by a reviewer who did not do the work.
IN VERIFICATION
Protecting the workflow you rely on
Automated tests pin how cases open, reopen when a problem returns, and confirm a fix by a later observation, so future changes cannot quietly break them.
BUILDING
Measuring outcomes honestly
Clear definitions for time to owner, time to verified resolution, how often fixes hold and technician minutes per case, with missing and excluded cases shown.
BUILDING
A written data governance statement
Where your data is stored, who processes it, how long it is kept, how it is deleted, and how you get it back if you leave.
BUILDING
Recovery you can check
Documented recovery objectives, proven by regular timed restore tests rather than by the existence of a backup.
Next
Completing the operating loop.
PLANNED
Connected asset context
One identity for each device across the agent, network polling, mobile management and manual records. Disagreements are shown, and a retired device keeps its history.
PLANNED
Network discovery per location
Find what is on each customer network from an agent you already manage, feeding the same asset records and alerting.
PLANNED
Versioned, reviewed automation
Every script run tied to the exact version that ran, optional second-person approval, and staged rollouts that stop when health checks fail.
PLANNED
Policy you can preview and roll back
Policy changes become revisions. Devices that drift from their baseline open a case, and each device shows which rule applied and why.
PLANNED
Change records and maintenance windows
A record of each planned change with a preview of what it touches and a way to roll it back.
PLANNED
Verified third-party application updates
An application update is marked complete only after the next inventory confirms the new version.
Later
Connecting more of your stack, with the same controls.
PLANNED
Integrations from partners' real stacks
The next integrations are chosen from the tools design partners actually run.
PLANNED
Stable, documented APIs and events
A versioned API with scoped service accounts, signed webhooks you can replay, and full data export.
PLANNED
Governed AI assistance
AI that prepares actions within limits you set. Each action needs approval, and nothing acts unattended unless you grant it.
PLANNED
Verified offboarding
An offboarding workflow across accounts and devices that finishes only when each step is confirmed.
PLANNED
Outcome reports
Show a customer how quickly work was owned and resolved, and how often it stayed resolved.
PLANNED
Governed mailbox response
Act on reported phishing across the affected mailboxes with each action approved, and each mailbox confirmed by a fresh read rather than by the action's return code.
EXPLORING
Technician apps for phones
Native phone apps for technicians, built on the same stable API as every other integration.
Items here depend on the ones above them. We do not attach dates, and the order can change when partners show us a more pressing need.
Shipped
Recently shipped.
Improvements now running on production. This list updates itself when a release reaches production.
SEP 2026
Fix Outlook search from the script library
A ready-made script repairs Windows Search when Outlook search returns nothing or only old mail.
SEP 2026
Clear reasons when a deploy finds nothing
When a patch deploy matches no devices, the message says why, for example that devices are waiting for a reboot.
SEP 2026
Retries that know when to stop
An update that fails three times on a device is no longer retried automatically, and the Patching page names it. Technicians can still retry by hand.
SEP 2026
Reboot-aware patching
Updates that are installed and waiting for a reboot are recognized and no longer redeployed. The Patching page shows them as waiting for reboot and offers Reboot to finish.
SEP 2026
SNMP alert rules
Raise alerts from polled network metrics on a numeric threshold or a status keyword. Alerts clear themselves when the value returns to normal.
SEP 2026
Alert rules from a log line
Any syslog line can start a new alert rule already filled in with its customer, host and message.
SEP 2026
Fixes confirmed by a later observation
A resolved case is confirmed only when a later check-in finds the problem still cleared. Silence is never mistaken for proof.
What the numbers mean. Each entry is tied to the release version that carries it, and it is listed only once production is running that version. The month shown is the month that release reached production. Nothing here is written ahead of a deploy.
Design partners
Help shape what ships next.
The items marked Planned and Exploring are where operator input changes the most. Bring a real workflow, show us where it breaks down, and we will tell you what we decided and why. Your feedback informs priorities; it does not guarantee a feature or a date.
See where it stands for your workflow.
We will walk through what is available today, what is still on the roadmap, and whether an evaluation makes sense.
This roadmap shows direction and current status, not delivery commitments. An item is called Shipped only when it is running on production.
