Skip to content
Try freeTry free

Evaluation guide

Prove the value of AI on your customer work

Start with one client. Test technical investigation, user support and safe handoffs, then measure the results before a wider move.

Start free trialBook a demo

Free calculators and checklists

AI service desk ROI calculatorAI service desk evaluation checklistService desk migration checklist for MSPs

Recorded demo ticket

Follow a VPN investigation, step by step

Diagnostic excerpts, the approval decision and the follow-up check from a staged fault. The final user update asks the requester to test the VPN.
Ticket
TK0022 · VPN won't connect
Device
CONTOSO-LT-042
Opened to user update
7 min 14 s
Approval in this demo
IT Support approved the clock change

Recorded in our demo organization for the product video, with display names changed. We staged the fault by stopping Windows Time and moving the laptop clock seven minutes ahead. The excerpts below show the investigation, approval and clock correction. At the last recorded step, the ticket is Waiting for User; a successful VPN reconnection has not been confirmed. This single demo is not a customer benchmark.

  1. 0:00

    Requester

    Jamie opens a ticket and picks the laptop

    “Since this morning FortiClient won’t sign in. It says: the server certificate is not valid yet.”

  2. 1:53

    NetZen AI

    Reads the VPN guide and forms a hypothesis

    Internal note: the guide says other FortiClient errors need a ticket with the exact error text, which Jamie gave. “Server certificate is not valid yet” usually means the laptop’s clock is behind or ahead, or a problem with the firewall’s certificate. The laptop is the one it can check.

  3. 2:03

    NetZen AI

    Checks the clock on the laptop (read-only, 0.7 s)

    Run Diagnostic Command · Get-Date

    Local: 2026-10-25 16:50:08 -04:00
UTC: 2026-10-25 20:50:08Z
TimeZone: Eastern Standard Time ((UTC-05:00) Eastern Time (US & Canada))
W32Time service: Stopped, startup Disabled
=== w32tm /query /status ===
The following error occurred: The service has not been started. (0x80070426)

    NetZen logged this result at 20:43 UTC. The laptop says 20:50. It is seven minutes ahead, and Windows Time is disabled, so nothing will correct it.

  4. 2:16

    NetZen AI

    Proposes the fix, Jamie confirms, IT Support is asked to approve

    Correct System Clock: re-enables and starts Windows Time, forces a resync, and if the clock is still more than two minutes off, sets it from internet time. The approval card names the device, client, site and the risk: set system clock.

  5. 4:42

    IT Support

    Alex in IT Support approves from the approvals page

  6. 4:51

    NetZen AI

    Runs the approved fix (2.6 s)

    Correct System Clock · result (excerpt)

    "previous": { "w32timeStatus": "Stopped", "w32timeStartType": "Disabled", "skewSeconds": 421 },
"method": "w32tm",
"w32tmResync": "Sending resync command to local computer
The computer did not resync because no time data was available.",
"applied": true,
"w32timeStatus": "Running",
"w32timeStartType": "Manual",
"skewSeconds": 0

    The resync alone failed, so the fix set the clock from internet time: 421 seconds off before, 0 after.

  7. 5:37

    NetZen AI

    Checks the clock after the change (read-only, 0.7 s)

    Run Diagnostic Command · Get-Date (excerpt)

    Local: 2026-10-25 16:46:43 -04:00
UTC: 2026-10-25 20:46:43Z
TimeZone: Eastern Standard Time ((UTC-05:00) Eastern Time (US & Canada))
W32Time service: Running, startup Manual
=== w32tm /query /status ===
Leap Indicator: 3(not synchronized)
Stratum: 0 (unspecified)
Source: time.windows.com,0x9
Poll Interval: 10 (1024s)

    The clock has been corrected and Windows Time is running. The output still reports not synchronized, so it does not establish that ongoing time synchronization is healthy. The technician should check that separately and confirm the VPN reconnects.

  8. 6:04

    NetZen AI

    Writes an internal summary for the technician

    Internal note

    Root cause: Windows Time (W32Time) service was stopped and disabled, causing a system clock skew of approximately 7 minutes (421 seconds ahead). This caused FortiClient SSL-VPN certificate validation to fail with "the server certificate is not valid yet".
Evidence: Diagnostic command (Get-Date) and time_sync showed W32Time service stopped/disabled and clock skew at 421 seconds.
Change made: Correct System Clock automation started the Windows Time service and corrected the system time skew to 0 seconds.
Verification: Follow-up Get-Date confirmed local and UTC system clock are now synchronized (16:46 EDT / 20:46 UTC) and W32Time service is running.

  9. 7:14

    NetZen AI

    Tells Jamie in plain language and waits for confirmation

    “Your computer’s clock was out of sync by about seven minutes because the Windows Time service had stopped, which caused FortiClient to reject the VPN server’s security certificate. We have re-enabled the time service and updated your computer to the correct time. Please try connecting to FortiClient VPN again and let us know if it works.” Status: Waiting for User.

Approval matrix

What runs on its own, and who approves the rest

Review these defaults before enabling ticket-driven work. Approvers can be configured per automation or app; direct technician runs and schedules follow a different path.
What the AI does
For example
Default approval
Good to know
Read-only checks
ExamplesSystem Information, Network Test, DNS and Proxy Settings, Printer Spooler Health, allow-listed read-only commands such as Get-Date
Default approvalNone
Good to knowAvailable when the agent is online and the check is enabled and in scope. Review the diagnostic output on the ticket.
Answers from your knowledge base
ExamplesHow-to questions, policies, client procedures
Default approvalNone
Good to knowUses documents available to the ticket’s client. Check the citation and confirm the procedure is current.
Fixes on the requester’s own device
ExamplesCorrect System Clock, Restart Print Spooler, Reset DNS to Automatic, Clean Up Temporary Files, Repair Outlook, Start Windows Service
Default approvalRequester
Good to knowChoose Requester, IT Support, Site Manager or Not Required per automation. Not Required still includes requester confirmation in the ticket workflow.
Disruptive changes
ExamplesReboot Device, Install Patches
Default approvalRequester
Good to knowRequester approval is the default for these actions. Review the approver setting before enabling them on servers or shared devices.
Security tooling
ExamplesAdd Defender exclusions for NetZen
Default approvalIT Support
Good to knowOnly technicians can request it.
App installs from your catalog
ExamplesAny app you publish to a client
Default approvalSet per app
Good to knowIT Support, Requester, Site Manager or Not Required. Technicians installing from Live View skip it.
Microsoft 365 and Google Workspace checks
ExamplesEnabled read-only checks on a connected tenant, such as account or mailbox diagnostics
Default approvalSet per check
Good to knowThese documented cloud packs provide read-only checks. Set approvers per check; Google Workspace directory access does not create, edit or delete accounts.
Your own automations
ExamplesScripts, browser tasks, API calls, run books
Default approvalRequester
Good to knowNew automations start disabled until you switch them on.
Technician-started runs
ExamplesRun now, schedules, patch windows, Live View installs
Default approvalNone
Good to knowA technician started it. Every run is in History with who started it and the result.

  • The AI never approves anything, including its own requests.

  • Approvers decide on the ticket, in the client portal or from email. Links require a NetZen sign-in.

  • A rejected request does not run, and the requester is told.

  • Approvals apply to runs that start from a ticket, wherever the request came from.

Where the AI stops

When a technician takes over

Plan for issues outside the available evidence, integrations or approved actions. These cases need a technician or another authorized person.

When it cannot finish

  • No matching enabled automation

    For failing hardware or an unfamiliar application fault, the AI can gather context and suggest a next step. A technician handles work outside the enabled automation scope.

  • The cause is outside the device

    An expired firewall certificate, an ISP outage, a vendor’s service. It can only change what it has an agent or a connected integration on.

  • An automation fails

    It does not retry in the same turn. The requester hears that a technician will follow up, and the error is on the ticket.

  • The device is offline or has no agent

    It keeps answering from your documentation. Device work goes to a technician.

  • Your documentation is wrong or missing

    Missing or stale procedures can reduce answer quality. Include unanswered questions in the pilot and check that they reach a technician with the available context.

When it is a person’s call

  • An approval is rejected or never given

    Nothing runs. The ticket stays with the people who own it.

  • Your policy says a person decides

    Access to sensitive systems, purchases, exceptions: write them into the intake policy and they go to an approver or a technician.

  • Hands-on work

    New hardware, cabling, a desk visit, a judgement call with the client.

What the handoff looks like

On handoff the AI stops for that turn. An assigned ticket goes to Waiting for agent; an unassigned one stays Open with the client’s service managers. Live progress shows what it found, what it changed and the next step, so nobody starts from zero.

Pilot scorecard

Score a 30-day pilot on your own tickets

Choose one client and a small set of representative issues. Agree the baseline, success thresholds and handoff rules before the trial starts.

Write these down before you start

  • Tickets per month and how many are repeat questions

  • First-response and resolution SLA attainment

  • Technician handling minutes and reopen rate, grouped by ticket type

  • What you pay today for the tools NetZen would replace

Criterion
How to test it
Where to look
What good looks like
Answers from your documentation
How to test itAsk ten how-to questions your users asked last month, on Teams, email or the portal.
Where to lookThe ticket conversation, with the cited document
Success criteriaCorrect answers that cite your own document. A handoff when the document is missing.
Investigation quality
How to test itRecreate five recent device issues on a pilot machine.
Where to lookThe internal note: root cause, evidence, change, verification
Success criteriaThe evidence is what your best technician would have checked.
Safe changes
How to test itTrigger fixes that need approval, and reject one.
Where to lookThe approval card on the ticket, Automations → History
Success criteriaNothing changed without the approval you set. The rejected fix did not run.
Handoffs
How to test itRaise issues it cannot fix: hardware, the firewall, a vendor outage.
Where to lookLive progress and the Waiting for agent view
Success criteriaThe right owner, the evidence attached, and the AI stopped.
Fix reliability
How to test itCount completed and failed runs over the pilot.
Where to lookAutomations → History
Success criteriaFailures are named on the ticket and handed off, never retried silently.
SLA
How to test itCompare the pilot client with your baseline.
Where to lookClients → SLA
Success criteriaFirst-response and resolution attainment at or above your baseline for comparable ticket types and business hours.
Technician time
How to test itLog time on pilot tickets as usual.
Where to lookClients → Time tracking
Success criteriaLower handling time for comparable ticket types, without a higher reopen rate. Record both gains and regressions.
Rollout effort
How to test itOnboard one client: users, devices, mailbox, Teams.
Where to lookClients → End Users, Live View
Success criteriaYou know your per-client onboarding time before you commit.

Keep a pilot record

For each ticket, record the category, automation outcome, approval decision, technician minutes and whether it reopened. Compare similar issues over the same business hours. Report sample sizes and exceptions; exclude staged demo tickets from customer outcome metrics.

Decide whether to expand, revise or stop the pilot against the thresholds you agreed before starting. Review failed runs and reopened tickets before counting a resolution as successful.

Cost model

Run the numbers with your own inputs

The defaults are an illustrative scenario. Replace them with pilot measurements to compare subscription costs and estimate released technician capacity.

Active admins and standard members; minimum one

Not billed. Shown for cost per device

From your current system

Illustrative input, not a published resolution rate

For the tickets the AI would close

Salary, benefits and overhead

Only what you actually cancel

NetZen per month5 × $100
$500
Per endpointEndpoints are not billed
$1.00
Estimated capacity releasedPer month; not a reduction in paid hours
30 h
Value assigned to that capacity
$1,350
Subscriptions retired
$0
Monthly subscription cash differenceRetired subscriptions minus NetZen; excludes labor value
-$500

Combined monthly value estimate

$850

Capacity value + retired subscriptions − the new subscription. This is a planning estimate; released hours become cash savings only if paid costs actually fall.

Assumptions

  1. NetZen at the list price of US$100 per technician per month. End users, endpoints, clients and mailboxes are free. Taxes and phone usage are extra. Promotional pricing is not included.
  2. Only tickets resolved without technician intervention count toward estimated capacity. Exclude reopened tickets within your agreed follow-up window. Time saved on handoffs is not counted.
  3. The share the AI resolves is your input. We do not publish an average because it depends on your documentation, the automations you enable and your ticket mix. Measure it in the pilot.
  4. Tool savings count only what you actually cancel.
  5. Released technician time is capacity, not an automatic payroll saving. The combined estimate values that capacity at your input hourly cost. Onboarding, overlapping subscriptions and ongoing review time are excluded; measure those separately in the pilot.

Migration checklist

Move to NetZen without a big-bang cutover

Shared settings first, one client end to end, then everyone else in batches. Your current tools keep running until each client is moved.

  1. 01

    Before you switch

    • List clients, sites and the contacts who approve work

    • Export documentation as PDF, Word, CSV or Markdown, or plan to connect IT Glue or Hudu

    • Note open tickets, contracts, recurring scripts and patch schedules

    • Record your baseline numbers for the pilot scorecard

  2. 02

    Set up once

    • Invite technicians and choose their roles

    • Brand the portal and set business hours and SLA targets

    • Write the intake policy: what to collect and what needs approval

    • Load documentation into the knowledge base

    • Switch on automation packs and choose approvers

  3. 03

    Pilot one client

    • Add the client and its sites, with the right time zone on each

    • Connect their Microsoft 365 or Google Workspace so their people arrive

    • Deploy the agent with Intune, an install command or the installer, alongside your current agent

    • Connect the support mailbox. No DNS or MX changes

    • Add the Teams app, Slack or web chat

    • Run a two-week working pilot within the trial, then score it against the baseline

  4. 04

    Billing

    • Set up agreements, rates and your catalog

    • Connect QuickBooks Online or Xero. Customers are matched by name on the first export

  5. 05

    Cut over

    • Close open tickets where they are, and re-create the long-running ones

    • Stop your old tools reading the support mailbox

    • Tell users where to ask for help: Teams, email, the portal

    • Retire an old agent only after replacement functions, monitoring and patch policies are verified; keep any separate security tooling you still need

    • Document a rollback owner and restore procedure, then move the remaining clients in batches

Keep exploring

Service DeskAutomationsRMMPricing

Start with one client. Expand with evidence.

30 days free, no card. Validate your essential workflows before moving the wider service desk.
Start free trialBook a demo