For managed service providers
Every network you're on the hook for, on one screen.
The board sorts your whole book of business so you know which client to open first. Devices, gateways, incidents and changes roll up per customer, and each client's device credentials stay encrypted on a gateway inside their network. Not yours, and not ours.
No credit card, and every client you carry lives under one organization.
One console
Every client's devices, gateways, incidents and changes in one place, not one browser tab per vendor dashboard.
Triaged for you
The board is ordered worst-first by a rule you can read, so the client having the worst morning is at the top.
Isolated per client
Each client gets their own gateway, their device passwords stay on their network, and two clients can use the same IP addresses.
You're the network team for a dozen networks you didn't design.
RMM covers the endpoints. PSA covers the tickets. The switches, APs and firewalls at forty sites are covered by a folder of bookmarks, four vendor cloud dashboards, and whoever remembers that site.
Nobody notices drift
A VLAN added by hand two years ago, firmware nobody's tracking, a switch under someone's desk that's now steering the whole network. It isn't a ticket until it's an outage, and then it's an outage at a site nobody has opened since install.
The client calls first
Per-vendor dashboards each know about their own gear at one site. None of them can tell you which of your clients is in trouble right now, so the escalation path starts with your phone ringing.
Every network is bespoke
Whatever the client bought, inherited, or had installed by the last guy. Standardising on one vendor's cloud isn't an option when you don't own the purchase order.
The portfolio dashboard
A board that tells you where to start
Turn on MSP mode and Customers becomes a top-level section of the console. It opens on the whole book: how many clients need attention, how many devices you're carrying and how many can't be reached, gateways online out of gateways deployed, and every open incident across every client, worst severity first.
Need attention
3
1 critical
Customers
28
across 41 sites
Devices
614
7 unreachable
Gateways
40/41
online
Open incidents
9
1 critical · 5 warning
Illustrative numbers. Health is always shown as an icon and a word, never colour alone.
How worst-first is decided
Customers sort by health, then by the severity of their worst open incident, then by how many they have, then by how much of the fleet is unreachable, then by name. Severity outranks count because one critical is a worse morning than three low ones, and sorting by count would bury it. Sorting by name last keeps the order fixed, so a refresh can never reshuffle the board under your cursor.
- health
- worst severity
- incident count
- devices unreachable
- name
And "needs attention" says why
A client is flagged by named rules, and the verdict is the worst rule that fired, never a later check quietly downgrading an earlier critical. Every flag carries its reason onto the card, so triage doesn't start with opening the customer to find out what's wrong.
A client's stage counts too, because "nothing set up yet" means something different for a prospect than for a client you've billed for a year.
- No gateways configured — the client has sites but nothing that can watch them.
- Devices unreachable — as a share of the fleet, warning then critical.
- Gateways offline — a gateway that was phoning home has stopped. Some offline is a warning; all offline is critical, because nothing is reaching that client at all.
- Gateway never checked in — shipped, never phoned home. Someone never plugged it in.
- Devices found, none under management — discovery worked, onboarding stalled.
- Failing collectors — the device answers, but some of the data we collect from it keeps failing. Monitored badly, which is easier to miss than not monitored at all.
- Nothing provisioned — an active customer with no sites, gateways or devices at all.
The customer record
A real record for every client
Each customer gets a page: their sites, their gateways and when each last checked in, their open incidents, their runbook, and every count taken from the same data the dashboard uses, so the board and the page can't tell you two different stories.
- Lifecycle
- Prospect → onboarding → active → suspended → offboarded, so a half-installed prospect isn't flagged like a live client. Rename the states or drop the ones you don't use; the editor only offers the states your organization actually has.
- Tier and account manager
- Bronze/silver/gold out of the box, or whatever you sell. Filter the whole board by tier or lifecycle when you want to look at just the gold accounts, or just the ones still onboarding.
- A runbook, not a CRM
- Free-form notes per customer: who to call, the maintenance window, the odd thing about their core switch, links out to the ticket, the wiki, the contract. It links to your systems of record instead of copying them, because a stale copy of your PSA is worse than none.
- Quick actions where you are
- Jump into the client's context, create the setup code for a new site's gateway, invite their admin, suspend. Anything you can't do right now is disabled, with the reason shown.
Onboarding
New client to monitored network, same afternoon
Onboarding a client takes one form and one gateway.
-
01
Type the client's name
One submit creates the customer, their first site, their access boundary, their admin team and the setup code for their gateway, all in one step, so you never end up with half a client.
-
02
Deploy the gateway
An appliance, a virtual machine, or a container on something already at the site. It signs in with the setup code and connects out, so there's no VPN to set up and nothing to change on the client's firewall.
-
03
Watch it fill in
Discovery starts by listening to what the client's devices already announce, so onboarding doesn't set off the security tools you're also being paid to look after. Devices, connections and the network map fill themselves in.
Already have clients in here?
Existing divisions convert in bulk. The picker ranks the likely candidates (it can tell which ones came in through the onboarding flow) and you confirm. Nothing is designated a paying customer on a guess, so your internal IT division never turns up on the board as a client. If a conversion partly fails, it tells you which ones and why, by name.
Client separation
One console. Networks that never touch each other.
Every client runs their own gateway on their own network. The console brings them together on your screen, but it never connects one client's network to another's.
Clients A and B use the same IP addresses. That's fine. Each is reached through its own gateway, so the overlap never matters, and you never have to sell a client on renumbering their network.
Their credentials, on their side
You never build a vault of forty clients' admin passwords in someone else's cloud. A password is passed to that client's gateway and encrypted there, and you choose how each gateway guards the key: locked to its hardware, split with our cloud, or kept in a local file. We don't store their passwords in our cloud.
How that works, in detail →Commercial roles aren't infrastructure roles
Reading the customer book is its own permission, separate from the one that manages sites and devices. An account manager can see the portfolio without touching a switch, and a field engineer with full infrastructure rights doesn't get your book of business.
Give the client a view, scoped to them
Invite a client's own admin straight from their page. They land in a team scoped to their network and nobody else's, in the same console you use. You decide what they can see and change.
Redundancy per site
Put a second gateway at a site that matters and they share the work; if one goes down, the other takes over. One dead VM at a client isn't a blind spot you find out about during an outage.
On their gear from the browser
Open a terminal or a device's web interface from the console, or a serial console through a console server. The session runs through that client's own gateway, which logs in with the stored credential, so the password never reaches your tech's browser.
Remote access, in the docs →Remote sessions on the record
Remote access is its own permission, so a tech limited to one client can only open sessions on that client's devices. Terminal sessions are recorded from what the device sends back, so a password typed at a hidden prompt is never captured. Opening and closing one goes in the activity log.
Technician VPN
Your techs on the client's network, through the gateway already there
Some jobs need the tech's own tools, like RDP to a server or the vendor's own management app. The Witina VPN app puts their computer on the client's network through the gateway at that site. There's nothing else to install at the client and no port to forward.
No firewall change at the client
The gateway and the app both connect outward, so neither side opens anything on its firewall. The connection then runs directly between the tech's computer and the gateway, and the traffic never passes through our cloud.
Access by policy, per client
Nobody connects until a policy names their team. A policy covers a client's sites, or the sites you pick, and caps a session at eight hours or less. Take a tech off the team and their sessions end.
Two clients with the same addresses
Each site also gets a stand-in address range for the session, so a client whose addresses match the tech's own office, or another client's on at the same time, is still reachable. Names on the client's network work too.
"Who was on our network at 2:14?"
Every connection through the VPN is recorded. Give Witina the time and port from the client's firewall log, and it names the session, the tech and the computer.
The app runs on Windows and Linux, with macOS coming soon, and keeps itself up to date. Techs turn sites on and off in the browser. How the VPN works →
Change management
The discipline you'd want if it were your network
The riskiest thing an MSP does is change a client's network settings at 9pm on a Tuesday. Plan the change and send it for approval, and it's snapshotted before it touches anything, verified after, and reversible.
Approvals, including theirs
Multi-level approval, so a change can wait on your senior engineer and on the client's sign-off before it goes anywhere near the gear.
Maintenance windows
Schedule into the window you agreed with that client, and let it run without anyone staying up to press the button.
Snapshot and roll back
The device's settings are backed up before the change and restored if it goes wrong, and any earlier backup in its history can be previewed and put back. "We can put it back" is a sentence you can say to a client and mean.
An audit trail you can hand over
Who changed what, when, on whose approval, with the diff. Useful in a post-incident review, and useful when a client asks what you've been doing.
It works across the gear your clients actually own: Cisco, Juniper, Arista, UniFi, Netgear, EdgeRouter and more, using the open standards network equipment already speaks rather than one vendor's software. When something does break, the problems Witina knows come with a named cause and a fix. A rogue device handing out addresses, for example, comes with the switch port it's plugged into.
The fix, drafted for you
When an incident's fix is a settings change, it comes ready-made, like turning on loop protection, guarding a port against a rogue switch, or shutting off a port an unknown device plugged into. Pick the suggested fix and it becomes a change with the steps filled in, which you send for approval and can roll back like any other. That means fewer 2am calls that only ever needed one command.
Coming soon
What we're building next
The MSP side of the product is where most of our attention goes. Here's what's next, and if your practice needs one of these sooner than the others, tell us and it moves up.
Next up
Which device is eating the bandwidth
How much data each device moves, tracked across switch ports and access points. "The internet is slow at the Denver office" turns into a named device on a known port with a number next to it, with nothing extra to install at each site. Witina already knows where every device is plugged in; this adds how much traffic it's moving.
A client portal in your name
White-label the client-facing side with your own branding and domain, showing each client the slice of their network you choose. The scoped access underneath already works; what's coming is making it look like yours.
Client-ready reporting, on a schedule
Monthly network health, inventory, incidents and the changes you made, generated per client and sent without anyone assembling it by hand. It's the document that justifies the retainer, built from data you're already collecting.
Ticketing that goes both ways
An incident here will open a ticket in the system your techs already live in, and close it when the network recovers. Until then, the customer runbook links out to your tools.
One plan for the whole book
One organization, one bill, however many clients you carry. The MSP plan is $899 a month and includes 400 monitored devices and 100 client networks, with 120 gateways and 100 team members. There's no per-client minimum, and taking on client number 101 costs $2.99 a month, not a new contract.
Most network tools are shaped for one company with a few big sites: lots of devices, very few separate networks. Your book is the opposite: every client is a network of its own, and most of them are small. So the MSP plan trades device headroom for a hundred client networks at a per-network rate sized for how MSPs actually grow.
Past the included 400, devices are $0.51 a month each, up to 4,000. Annual billing is $8,990, ten months for twelve. The plan is self-serve; the call is there if you want help sizing it or onboarding your first clients.
Talk to a human
We'll walk through the product on one of your real client sites. Bring a messy one.
Talk to us about your book →Or sign up and pick the MSP plan yourself.
MSP questions
Does every client need their own account? +
No. You have one organization and each client is a customer inside it, with their own sites, gateways, devices and access boundary. You sign in once and every client is on the same board, so there's no tab-switching between tenants to answer "who's down right now".
Two of my clients use the same IP range. Problem? +
No. Each client's devices are reached through that client's own gateway, so the same addresses in ten different networks never clash.
Do you store my clients' device passwords? +
No. They're relayed to the gateway on that client's network and kept encrypted there. We don't store them in our cloud, so a breach of us is not a breach of forty of your clients.
Can a client see their own network without seeing anyone else's? +
Yes. Invite their admin from their customer page and they land in a team scoped to their network only, with the permissions you grant, and access is checked per request against the scope they're acting in. Today that's our console with our branding; a portal in your own name is what we're building next.
Does this replace my PSA or RMM? +
No, and it shouldn't. This is the network layer your RMM doesn't cover: switches, access points, firewalls, their settings and how they connect. Your PSA stays the system of record for the relationship; the customer runbook links out to it rather than copying it, and two-way ticketing is on the roadmap.
What happens when I lose a client? +
Mark them offboarded, or remove the designation, which is non-destructive, so if they come back their history and settings are still there. Nothing of ours is left behind in their device settings, and the client can be handed their gateway and carry on.
Bring your messiest client site
The one you inherited, with the switch nobody has logged into since 2021. Point a gateway at it and see what comes back.