Nine modules, one data model, one console

The platform agent runs on every managed endpoint, server and supported appliance, reporting health and inventory continuously and accepting work when there is work to do. Patch policies are defined per client and per device group, with maintenance windows and rings so a bad update reaches your test group before it reaches a trading floor.

Because the agent is the same connection used by scripting, inventory and remote access, a technician never has to ask whether a second tool is also installed and healthy on the machine in front of them.

Tickets arrive by email, through the client portal, from a monitor or from a security event, and land in queues you define. Service level targets are attached to the contract rather than typed into each ticket, so response and resolution clocks start correctly and escalate without anyone watching them.

Time capture, work notes, approvals and client communication live on the ticket, and the ticket is linked to the devices it concerns. Reporting comes from the same records the technicians work in, which is why the numbers reconcile.

Availability and performance checks run against devices, services, websites and network paths, with thresholds that can differ per client because a four hundred millisecond response time means something different to a law firm than to a warehouse.

Alerts are correlated before they are raised. A failed hypervisor produces one incident with the affected guests attached, not thirty notifications that bury the one that mattered, and a monitor that fires outside an agreed window is held rather than paging someone at two in the morning.

Scripts are first-class objects in the platform: versioned, reviewed, parameterized and scoped to the clients and device groups allowed to run them. A dry run reports what would change before anything is applied, and every execution records the operator, the approval and the output.

This is also where the scripting agent does its work. It drafts, it tests in a sandbox and it proposes, while the technician keeps the decision about what actually runs on a client machine.

Hardware, installed software, licenses, warranty dates, network addresses and configuration are collected by the agent and kept current without anyone maintaining a spreadsheet. Changes are tracked over time, so the question of when a machine gained an administrator account has an answer.

Because inventory is the same record the service desk and the SIEM read, an asset report is also a contract document and a security context. There is one list, and it is the list the technicians already trust.

Attended and unattended sessions run over the existing agent connection, authorized by the platform identity layer. A session can require a ticket, a client approval or a second factor, depending on the client and the machine, and the rule is set once rather than remembered by each technician.

Sessions are recorded against the ticket that justified them, with file transfers and elevation logged, which turns remote support from a trust exercise into something you can show a client during an audit.

Phones and tablets enroll into the same tenant as the desktops, carrying configuration profiles for mail, network, certificates and restrictions. Applications are delivered and removed centrally, and compliance checks report the devices that have drifted away from the policy their client agreed to.

When a device is lost or a member of staff leaves, the response is a policy action in the console rather than a support call to a separate vendor.

Logs and security events from endpoints, servers, network devices, identity providers and the platform itself are collected into one place and correlated against inventory and change history. An unusual administrator login is read alongside the ticket that approved the change, which is the difference between an alert and an answer.

Detections, dashboards and retention are yours to tune. Because you own the storage, keeping a year of events is an infrastructure decision rather than a pricing negotiation.

One directory covers technicians, client contacts and the agents themselves. Roles decide which tenants a person can see, which scripts they can run, which machines they can connect to and which approvals they can give, and those decisions are enforced in every module rather than configured nine times.

Joiners, movers and leavers are handled once. When a technician changes team, their access across monitoring, tickets, scripts, sessions and security data changes with them.