Skip to main content

Client Management use case

Client service portal software for MSPs

Client service portals give each managed services client a branded place to request services, approve their own people's requests and see status, while the provider runs one set of workflows behind every portal. Fulfillment reaches the right client's Active Directory, Microsoft 365 tenant and RMM, and tickets and time land in ConnectWise or Autotask.

Book a working session

Writes to your PSA Tickets and time entries land in ConnectWise or Autotask as the work happens.

How a client request reaches the right tenant

  1. Experience layer

    A branded portal for each client with its own service catalog, approvers and request history, and an admin view for the client's IT contact.

  2. Workflow layer

    Requests follow each client's approval rules, then provision in that client's directory, tenant and devices, with PSA tickets and time entries written as the work happens.

  3. Integration layer

    Writes tickets and time entries to ConnectWise or Autotask and provisions in each client's own Active Directory, Microsoft 365 tenant and Intune, kept separate per client.

    • ConnectWise
    • Autotask
    • Active Directory
    • Microsoft 365
    • Microsoft Intune

AI in client service portals

AI matches requests to each client's catalog and summarizes open work for reviews. Client approvals and changes to a client's catalog stay with people.

What AI does

  • Matches client requests to that client's catalog
  • Extracts details from emailed requests into structured forms
  • Summarizes open work for quarterly business reviews

Decided by people, not by AI

  • Client-side approvals for billable or access requests
  • Changes to a client's catalog or approval chain
  • Exceptions to contracted service levels

Fifty clients, fifty ways to ask

A client’s office manager emails the help desk: new hire Monday, needs an account, a laptop and the accounting software. A technician opens a ticket in ConnectWise, signs into that client’s Active Directory, then their Microsoft 365 tenant to assign a license, then the RMM to push the software. Then they log time, update the ticket and email the office manager back. The next request is from a different client, with a different tenant, different approvers and a different idea of what “standard laptop” means.

Every client expects its own experience. Building one by hand per client doesn’t scale. A generic portal satisfies no one. And when growth depends on technicians switching between consoles, each new client means another hire.

A portal per client, one set of workflows

Each client gets a portal with its own branding and its own catalog: only the services, software and hardware you’ve agreed to provide them. Their people sign in and pick “New user,” “Software request” or “Laptop replacement.”

The request follows that client’s rules. One client auto-approves standard software, while another wants their finance director to sign off on hardware over a set amount. Their approvers act from the portal or email.

Once approved, the workflow knows which client it’s working for. It creates the user in their Active Directory, assigns the license in their Microsoft 365 tenant, enrolls the device in their Intune and pushes software through the RMM. The ticket and time entry are written to the PSA as it goes. The client sees each step on their request page.

The client’s IT contact gets a view of everything their organization has open. You get the same data across every client, by service type and age, for reviews and SLA reporting.

Why it’s built once

The workflows are shared. “New user” is one workflow with per-client settings, not fifty copies. When Microsoft changes a licensing API or you improve a step, every client gets the change. That’s what lets the service desk grow its client count faster than its headcount.

Software requests are usually the first thing to automate end to end; see software provisioning. Device lifecycle management adds hardware ordering, setup and recovery per client.

What you can build next

Providers usually automate software first, then hardware, per client.

Questions about client service portals

Answered by Kinetic Data. Last updated .

  • Can one Kinetic environment serve many clients?

    Yes. Each client gets its own portal, catalog, approval rules and connected systems, kept separate from every other client. The provider maintains one set of workflows underneath, so a fix to a shared workflow reaches every client that uses it.

  • Do our technicians still work in the PSA?

    Yes. Tickets, status changes and time entries are written to ConnectWise or Autotask as the workflow runs, so billing and reporting work as they do today. Technicians open the PSA for the steps that need a person.

  • How long does it take to add a new client?

    It's a setup task, not a project: brand the portal, choose which services they get, set their approvers and connect their tenant and directory. How long it takes depends mostly on how standard their environment is.

  • Can clients see what we bill them for?

    Clients can see each request, its approvals and when it was completed. Whether time and cost are shown to them is a per-client setting, since billing itself stays in the PSA.

Bring one process. Leave with a plan to build it.

Two hours with our team, at no cost. Bring one process that crosses your systems. We map it with you, show what Kinetic would build, and send you a written plan afterward.

Book a working session