Your customers get a portal too
Co-managed IT, done properly: a customer's IT lead gets a scoped login of their own, into their tenant, at the access level you set. You keep the master view, the write gates, and the audit trail.
Prefer email? Get in touch and we run onboarding with you.
What's included
Scoped seats
Access is granted per area, per tenant: hand a customer's IT lead directory and devices, keep security and billing to yourself. A seat is a policy you define, not a stripped-down second product.
Read-only or hands-on, per area
Each area a seat can see is independently read-only or full. An IT lead who should look but not touch gets exactly that. Write level is enforced on the server: a mutating request without full access is refused, whatever the client asks for.
Their branding
Each tenant's portal carries the customer's own name and logo: their console, not a generic MSP shell with someone else's badge on it.
Server-side isolation
A customer seat can never see another customer's name, data, or existence. The tenant roster itself is filtered in the API, not hidden client-side. There is no cross-tenant scope for a customer seat to reach.
Invites and lifecycle
Invite a customer admin by email (any domain) into exactly the seat you defined. When the relationship changes, suspend the account or revoke its sessions immediately; a disabled seat is refused at sign-in.
Everything audited
Customer-seat actions land in the same per-tenant, tamper-evident audit log you already see: one hash-chained trail per customer, whoever held the keyboard. Shared responsibility without a shared blind spot.
MSP-only surfaces (the cross-tenant book view, tenant onboarding, and console administration) are never available to customer seats. Feedback from MSPs and their customers shapes how the scoped seat experience evolves.
Co-managed IT
Give your co-managed customers a console of their own
They get a scoped, branded seat on their tenant; you keep the master view, the write gates, and one audit trail across both of you.