Witina

For managed service providers

Every network you're on the hook for, on one screen.

One console for your whole book of business — a single pane of glass that doesn't just show you every client, it tells you which one 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. One organization, one login, one bill — however many clients you carry.

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 by design

Per-client gateways, overlapping IP ranges, and credentials that never leave the client's own network.

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 spanning-tree root that moved. 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 — your daily workflow, not an admin screen. 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 an icon and a word, never colour alone — a screen of tiles shouldn't be a traffic light.

Worst-first isn't a vibe, it's a rule

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 on purpose: one critical is a worse morning than three low ones, and sorting by count would bury it. The last key makes the order total, so a refresh can never reshuffle the board under your cursor.

  1. health
  2. worst severity
  3. incident count
  4. devices unreachable
  5. 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.

Lifecycle is an input, 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 poll them.
  • Devices unreachable — as a share of the fleet, warning then critical.
  • Gateways offline — a gateway that was phoning home has stopped. Some of them is a warning; all of them 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 something we poll it for keeps erroring. 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.
No refresh, no reload. A warehouse loses power and the board re-sorts itself: a failing collector flags the client first, then two devices go unreachable, then a third takes it past 50% — critical, and top of the list.

The customer record

A client is a first-class thing, not a folder

Each customer gets a page: their sites, their gateways and when each last checked in, their open incidents, their runbook, and every state number rolled up from the same source the dashboard reads — 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 — it's your vocabulary, and the editor only ever offers what 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 deliberately points at your systems of record instead of duplicating them — a stale copy of your PSA is worse than no copy.
Quick actions where you are
Jump into the client's context, issue a provisioning token for a new site, invite their admin, suspend. Anything you can't do right now is disabled with the reason — never offered and then failed.

Onboarding

New client to monitored network, same afternoon

Onboarding is one form, not a runbook of nine steps you can half-finish.

  1. 01

    Type the client's name

    One submit creates the customer, their first site, their access boundary and their admin team, and mints the provisioning token — in a single transaction, so you never end up with half a client.

  2. 02

    Deploy the gateway

    Appliance, VM, or a container on something already at the site. It takes the token, dials out, and needs no inbound port, no VPN and no firewall change on the client's side.

  3. 03

    Watch it fill in

    Discovery is passive first — LLDP/CDP, DHCP, mDNS — so onboarding a client's network doesn't set off the IDS you're also being paid to respect. Devices, links and topology populate themselves.

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.

Multi-tenancy

One console. Networks that never touch each other.

Every client runs their own gateway on their own network. The console federates the view; it never becomes a shared path between two customers.

YOUR CONSOLE One book of business TLS out CLIENT A · 10.0.0.0/24 Gateway Their credentials — encrypted, on site CLIENT B · 10.0.0.0/24 Gateway Their credentials — encrypted, on site CLIENT C · 192.168.1.0/24 Gateway Their credentials — encrypted, on site

Clients A and B both run 10.0.0.0/24. That's fine — each is reached through its own gateway, so overlapping address space is a non-event instead of a re-addressing project you have to sell.

Their credentials, on their side

You never build a vault of forty clients' enable passwords in someone else's cloud. A credential is relayed to that client's gateway and encrypted there, with the key sealed to a TPM, split with the cloud, or in a local file — your policy, per gateway. Our database has no column for the secret.

How that works, in detail →

Commercial roles aren't infrastructure roles

Reading the customer book is its own permission, deliberately not 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 — the same console you use, with their slice of it. You decide what they can see and change.

Redundancy per site

Deploy a second gateway at a site that matters and management work spreads across both, with standby takeover — so one dead VM at a client isn't a blind spot you find out about during an outage.

Change management

The discipline you'd want if it were your network

The riskiest thing an MSP does is change a client's config at 9pm on a Tuesday. Every change here is planned, approved, 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 config is captured before the change and restored if it misbehaves. "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 — over standards like LLDP/CDP, SNMP and SSH rather than one vendor's API. And when something does break, the faults the platform knows come with a named cause and a fix, not a red dot: an unexpected spanning-tree root, a duplex mismatch, a guard violation. A focused set today, deliberately growing.

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, telling us moves it up.

Next up

Which endpoint is eating the bandwidth

Data transfer per endpoint, tracked across switch ports and access points — so "the internet is slow at the Denver office" becomes a device, a port, and a number, without a span port, a probe, or a flow collector at every site. You already know where every endpoint is attached; this makes that attachment quantitative.

A client portal in your name

White-label the client-facing side: your branding, your domain, your logo — showing each client exactly the slice of their network you choose. The scoped-access model underneath it already works; what's coming is making it look like it belongs to you, not to us.

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. The document that justifies the retainer, produced from the data you're already collecting.

Ticketing that goes both ways

An incident here opening a ticket in the system your techs already live in, and closing it when the network recovers. Until then the customer runbook links out to your tools on purpose — pointing at your system of record beats keeping a second copy that drifts.

Alerts that fix themselves

For faults with a known remedy, a proposed change ready for one-click approval — built from the same audited, reversible change machinery you'd use by hand. Fewer 2am calls that only ever needed one command.

Listed here rather than above, because nothing on this page's feature list is a plan. If one of these is the thing that would make us a fit, tell us — early MSPs shape what we build first.

One plan for the whole book

$899/mo, including 400 monitored devices across 100 customer networks. Past that, $0.51 per device and $2.99 per customer — so client number 101 costs three dollars, not a new contract. One organization, one bill, no per-client minimum and no per-seat charge for your techs.

Every other plan on our pricing page is shaped for one company with a few big sites: lots of devices, very few separate networks. Yours 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 networks and cuts the per-network rate to a third of what the Business plan charges.

Worked through: 40 clients averaging 8 devices each is 320 devices and 40 networks — inside the included allowance, so $899 flat. A hundred clients at the same size lands near $1,100, about $11 per client per month. Every number is published →

Talk to a human

A walkthrough on your own gear beats a demo on ours. Bring one messy client site.

Talk to us about your book →

Or skip us entirely — sign up and pick the MSP plan yourself. The offer stands either way.

MSP questions worth asking

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. One login, one board, one bill — and 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 identical address space in ten different networks never collides. Overlapping ranges were a design assumption, not a workaround.

Do you store my clients' device passwords? +

No. They're relayed to the gateway on that client's network and kept encrypted there. Our cloud stores a credential's name and type and has no field for the secret — which also means a breach of us is not a breach of forty of your clients. You can verify it by running the self-hosted edition and watching the traffic.

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, APs, firewalls, config and topology. 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. There's no agent buried in their config, and the client can be handed their gateway and carry on. Making the exit easy is part of the pitch, for them and for you.

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 — that's a better evaluation than any demo we could give you.

Want to kick the tires with nothing sent to us first? Run it yourself →