Structuring clients, sites and departments

The client/site/department model is the structure everything else inherits. Getting it approximately right at the start saves considerable rework, because reports, exports, dashboards, access scoping and contract reconciliation all read from it.

A client is a billing relationship. If you invoice it separately, it is a client. Service providers usually have one client per customer organisation. Internal IT teams generally have one client representing the business, and occasionally several if subsidiaries are billed apart.

A site is a location. Branch offices, factories, clinics, campuses — anywhere endpoint behaviour differs because the local conditions differ. Sites are the right granularity for "why is this office slower than the others" questions, and the natural unit for field work. Remote staff are usually best handled as a single logical "Remote" site per client rather than as a site each.

A department cuts across sites and answers ownership questions: who this machine belongs to, whose budget it lands on. If you do internal chargeback, departments are what make that possible; if you do not, keep them coarse rather than mirroring an org chart that will be reorganised next year.

Two structural mistakes are common enough to warn about. The first is creating a site per floor or per room — this produces a tree that is tedious to navigate and reports nobody reads. The second is putting everything in one default site with the intention of splitting later; the split is straightforward but reassigning historical context is not, and the reporting you produce in the meantime is less useful than it should be.

Assign the client and site at enrolment time using the install token rather than fixing them up afterwards. A token is issued against a specific client and site, so the agent lands in the right place at first contact and its earliest inventory and health records are already correctly attributed.