#service providers

##How it is structured

Three levels, and the middle one is the one that matters.

• Your practice - your technicians, your branding, your billing. One account.
• Client orgs - one per company you look after. Complete data separation. Its own devices, tickets, licences, patch rings and response windows.
• Devices and people - inside a client org, exactly as a single company would see them.

A technician works in a client org and moves between them without logging out. Nothing is shared across the boundary except your own staff list and your templates.

##The multi-client board

The default sort is by what needs attention, not alphabetically. A quiet client should not occupy the top of your morning.

That last line is a renewal conversation and a staffing decision in one sentence, which is the whole reason the board exists.

###Questions that cross clients

Some questions are about your practice rather than any one client: which clients are exposed to a given vulnerability, how many devices you manage in total, where your hours are going this month. Those run across every org you have access to, and the answer always names the client.

infotechbang exposure --patch KB5062553

# client org            devices affected   approved
# bluefin-logistics     31                 no
# acme-traders          18                 no
# northgate-legal       0                  n/a
# srinivas-clinics      6                  yes, pilot running

##Client isolation

Client data does not mix. A technician assigned to two orgs sees two orgs; a technician assigned to one sees one. There is no view that merges ticket content or device records across clients, and cross-client queries return counts and names rather than content.

Clients can be given a read-only login into their own org - useful when an office manager wants to see ticket status without calling you, and useful to you at renewal because the work becomes visible.

##Contract hours

Hours attach to work as it happens: time on a ticket, time on an approval, time on a project task. The board shows used against contracted, and flags the client before you are over rather than after.

Overage is flagged at 80% and again at 100%. The 80% notice is the one worth acting on, because it is still a conversation rather than an invoice dispute.

##Per-client response windows

Every client org carries its own windows, working hours and holiday calendar, because that is what the contracts say. A client paying for four-hour critical response is measured against four hours; one on next-business-day is not held to the same clock.

working hours   Mon-Sat 07:00-21:00  Asia/Kolkata
critical        4h       # contractual
high            8h
medium          1 working day
low             3 working days
holidays        client calendar (14 dates)

# breaches are reported per client and appear on their monthly report
# whether or not you choose to mention them

##White-label reports

A monthly report per client, generated from the same records your technicians worked from - not re-entered, not rounded, not written the night before the meeting.

• Devices managed, added and retired, with the replacement advisories
• Tickets raised, resolved, response times met and missed
• Patch posture: criticals outstanding, and how long they have been outstanding
• Licence position: over-use, unused seats, renewals in the next quarter
• Hours used against contract, itemised by ticket

Your logo, your colours, your sender address. Our name appears nowhere on it unless you put it there.

##Bringing clients across

You can run a client org in parallel with whatever you use today. The agent does not conflict with other monitoring agents, and a read-only pilot on one client is the usual way to start.

1. Create the client org and import the device list as manual assets if you have one.
2. Roll out the agent through whatever management you already have on that client.
3. Enter the licences and contract hours - an afternoon per client, typically.
4. Move intake last, once the inventory looks right.

Open ticket history can be imported as closed records so suggested fixes have something to learn from on day one. That import is the single highest-value hour in the migration.

##Limits