SuperOps

SuperOps is configurable PSA-RMM software for teams that want to standardize service-desk and endpoint work. Its January 5, 2026 automation guide documents event triggers, time triggers, and runbooks. Event triggers can set ticket properties, assign a technician, add a reply template, or attach a runbook; time triggers scan tickets every 30 minutes. [S1]

It is best suited to MSPs or internal IT teams that already have trustworthy ticket taxonomy, client boundaries, standard operating procedures, and named owners for dispatch and exceptions. It is a poor fit for an organisation looking to let AI or automation make unsupervised production changes before it has tested rule accuracy, write permissions, client effects, and recovery.

The main trade-off is action scope. SuperOps' current MCP documentation says a connected AI client can be granted read or write access across tickets, assets, client records, documentation, billing, and configuration-related information. It also says these scopes govern access independently of the connecting user's individual role. That makes deliberate scope design and a test tenant material controls, rather than setup details. [S4]

Best for: teams automating bounded ticket routing, recurring maintenance, runbook attachment, and technician documentation with accountable operational owners.

Not for: teams that cannot define safe rules, review exceptions, limit client and system access, or recover promptly from a mistaken update, script, patch, deletion, or client communication.

Route and prepare qualifying service tickets

• Trigger: A ticket meets a configured event or time condition.
• Inputs: Ticket fields, client, requester, priority, category, SLA, the approved automation rule, and a defined exception queue.
• Output: Updated ticket properties, technician assignment, reply template, or attached runbook.
• Human checkpoint: A dispatch or service-desk owner tests the rule, reviews its matches and misses, owns exception handling, and controls rule changes.
• Success measures: correct assignment, SLA attainment, duplicate rate, missed-ticket rate, reassignment rate, exception age, and technician rework.

SuperOps documents the ticket actions and an every-30-minute scan for time triggers. Its public material does not establish that a buyer's classifications, SLA rules, client contracts, or escalation design will produce safe matches. [S1]

Create recurring preventive-maintenance tickets

• Trigger: A scheduled one-time or recurring maintenance interval arrives.
• Inputs: Client details, ticket template, priority and other ticket properties, calendar conditions, and staffing rules.
• Output: A scheduled maintenance ticket that the team can identify by source.
• Human checkpoint: The dispatch owner confirms client scope, cadence, staffing, duplicates, and completion evidence before relying on the schedule.
• Success measures: on-time completion, duplicate ticket rate, missed-maintenance rate, client-impact incidents, utilisation, and reopened-ticket rate.

SuperOps' January 5, 2026 scheduler guide describes periodic or one-time tickets, including client details and ticket properties. [S2]

Attach an approved runbook to recurring issues

• Trigger: A known issue or ticket pattern matches a rule, or a technician selects a runbook.
• Inputs: The approved runbook, task templates, ticket context, client constraints, and a technician with the appropriate access.
• Output: A task sequence and documented execution path for a recurring issue.
• Human checkpoint: The technician verifies prerequisites, client context, evidence of completion, and any exception before a consequential action or closure.
• Success measures: adherence to the approved process, first-time resolution, escalation rate, reopen rate, completion time, and post-change incident rate.

SuperOps describes runbooks as SOP automation and documents manual or event-trigger attachment to tickets. A runbook is not proof that its tasks are valid for every client, asset state, or service agreement. [S1]

Draft and review ticket worklogs with Monica

• Trigger: A technician selects a ticket reply for conversion to a worklog, or an administrator reviews accumulated worklogs.
• Inputs: The selected plain-text reply or ticket worklog history.
• Output: A proposed structured worklog or summary of work completed on the ticket.
• Human checkpoint: The technician checks, edits, accepts, or resets the proposal before it becomes an operational or billing record.
• Success measures: factual accuracy, edit rate, missing-detail rate, time to completed record, audit usefulness, and billing-dispute rate.

SuperOps' October 7, 2025 guide says Monica formats selected replies into worklogs and provides worklog summaries; it documents review, editing, and reset steps. Treat its statement that this reduces effort as a vendor claim and independently measure documentation quality. [S3]

Connect a supervised AI client through MCP

• Trigger: An administrator configures an MCP-capable AI client for a defined operational use case.
• Inputs: An approved AI client, administrator setup, OAuth credentials, an MCP endpoint, enabled modules, and explicit read-only, read-write, or disabled module scopes.
• Output: A supervised connection that can query, and when granted, change supported ticket or asset records.
• Human checkpoint: An administrator limits scopes, reviews test actions and logs, approves any write use case, and maintains a disablement and recovery procedure.
• Success measures: scope violations, inappropriate action rate, unapproved write rate, audit completeness, recovery time, and access-review completion.

SuperOps documents MCP access to ticket, asset, client, documentation, knowledge, billing, and other modules. Its guidance says write access can create or update tickets, add replies or notes, and soft-delete or restore tickets and assets. It also warns that MCP scope can apply regardless of the individual user's role. [S4]

A conservative operating model is: a request, alert, or scheduled date creates or identifies a ticket → a configured rule applies only the bounded action it is allowed to take → a technician follows the relevant runbook and verifies the asset and client context → a named owner resolves exceptions and authorizes material work → the team retains worklogs, approvals, and evidence under its own operating rules.

The product documentation establishes that ticket changes, scheduling, runbooks, and AI-assisted worklogs exist. It does not establish the buyer's safe automation boundary, real tenant configurations, script or patch controls, client approvals, audit retention, emergency disablement, data export, or recovery behaviour. Validate those details in the proposed edition, tenant, and contract.

MCP merits a separate control boundary. Start with read-only access to an isolated test tenant. Enable a single low-impact write action only after verifying which module data the AI client can reach, how its actions are attributed, what overrides role permissions, how it is disabled, and how affected records are recovered. Never rely on an AI client to decide whether its own action was appropriate. [S4]

Verified facts from public primary sources

• SuperOps documents event triggers, time triggers, and runbooks. The published event-trigger actions include property setting, technician assignment, reply templates, and runbook attachment; time triggers scan every 30 minutes. [S1]
• The ticket scheduler documentation says buyers can create one-time or periodic tickets, provide client details and ticket properties, and identify scheduled tickets by source. [S2]
• The worklog guide documents Monica formatting a chosen ticket reply into a worklog, with user review, edit, and reset controls, plus worklog summaries. [S3]
• SuperOps documents MCP read and write scopes across multiple modules. It says ticket writes include create, update, replies, notes, soft deletion, and restoration, and says MCP scopes govern access independently of user roles. [S4]
• Its security page states SOC 2 Type II, GDPR, ISO 27001, and HIPAA compliance and describes AWS hosting, AES-256 at rest, HTTPS in transit, SAML, MFA, role-based access, IP allowlisting, and seven-day backups. These remain vendor-published security statements, not a substitute for buyer-specific assurance evidence. [S5]

Pricing and commercial model

SuperOps publishes endpoint-based IT-team pricing. On the page accessed for this research, the displayed Prime plan starts at $1.50 per endpoint per month at a 100-endpoint minimum, with lower listed rates at higher endpoint counts. The page asks buyers to select subscription term and device count. Confirm current price, currency, geography, MSP versus internal-IT packaging, included modules, AI credits, implementation, support, commitments, overages, renewal, cancellation, and export in a written proposal. [S6]

Material unknowns and failure modes

• Public sources do not establish the buyer's actual module entitlements, deployment timeline, implementation responsibility, training, service levels, support coverage, regional availability, contract minimums, cancellation, or exit assistance.
• The public security page does not by itself provide the buyer's applicable reports, scope, exceptions, DPA, subprocessors, model or AI-data terms, hosting location, retention, deletion, backup restoration, support access, incident commitments, or export rights.
• Bad ticket data, stale client records, overly broad conditions, missing approvals, copied runbooks, and poor exception routing can turn correct product behaviour into the wrong operational result.
• Broad or improperly tested MCP scopes could expose client, asset, billing, documentation, or ticket data and enable inappropriate writes. The buyer must validate action attribution, logs, permission interaction, emergency disablement, restoration, and credential rotation. [S4]

Start with one client-safe workflow: for example, classify and assign a single low-risk ticket category, schedule a recurring internal maintenance reminder, or use Monica only for technician-reviewed worklogs. Name a service-desk owner, define the allowed ticket and client scope, freeze the trigger conditions, set a manual fallback, and prohibit scripts, patches, remote actions, deletion, billing changes, and client-facing replies during the first phase.

Build a representative test set with normal work and adverse cases: incomplete tickets, wrong client or asset, ambiguous priority, duplicate alerts, after-hours requests, SLA-edge conditions, revoked user access, conflicting instructions, unavailable technicians, misleading ticket text, and a case that should never be automated. Compare automated output with normal dispatch and technician work before expansion.

Measure correct routing or schedule creation, SLA attainment, missed and duplicate work, exception age, manual rework, worklog accuracy and edit rate, unauthorised or inappropriate actions, client-impacting errors, time to disable a rule, time to restore a changed record, and completeness of logs and exports. Stop or narrow the pilot after an incorrect client or asset action, missed critical ticket, untraceable write, failure to disable or restore, sensitive-data exposure, unapproved client communication, or inability to demonstrate the agreed permission boundary.

• Atera: compare all-in-one MSP operations on automation depth, endpoint and ticket controls, AI permissions, tenant isolation, and commercial model.
• NinjaOne: compare endpoint-centric IT operations on scripting, patching, approvals, access boundaries, and supportability.
• Rewst: compare MSP workflow automation on integration breadth, multi-tenant design, workflow governance, and the buyer's existing PSA-RMM stack.

1. Which modules, automations, AI features, credits, integrations, APIs, and MCP functions are included in our edition and region?
2. What can each role and each MCP scope read, write, delete, restore, export, share, retain, or disable, and where do scopes override individual permissions?
3. How are ticket rules, runbooks, scripts, schedules, outputs, approvals, changes, exceptions, and AI actions versioned, attributed, logged, reviewed, and exported?
4. Which assurance reports and terms apply to our service: SOC 2 and ISO scope, DPA, subprocessors, AI-data use, hosting, retention, backup restoration, residency, support access, and incident response?
5. What prevents an automation or connected AI client from acting on the wrong client, asset, ticket, or instruction, and how is a faulty action stopped and repaired?
6. What are the endpoint, technician, client, feature, AI-credit, implementation, support, renewal, cancellation, data-export, and migration terms?