Google Workspace Administration

The standing work that keeps a tenant matching the organisation it serves. New starters provisioned to the agreed convention and the right organisational unit. Leavers suspended, their mail delegated and their files transferred before anything is deleted. Groups, aliases and delegated access kept current as roles change. Licence count reviewed so you stop paying for people who left. Security settings and sharing policy reviewed periodically rather than set once. Storage housekeeping before it becomes urgent. None of it is difficult; all of it stops happening the moment nobody owns it.

Support is reactive — you contact us because something is wrong: mail not delivering, a user locked out, access broken, a leaver's files unreachable. Administration is proactive: the standing work that stops most of those calls happening in the first place. Most organisations need some of both. A useful signal is that if you find yourself raising the same category of problem every quarter, the answer is usually not faster support but administration that is currently missing.

Possibly not, and we would rather say so. If someone's job genuinely includes Workspace administration and they have the time, in-house is the fastest arrangement and we are not going to beat it. The question worth asking honestly is whether the periodic work is actually being done — when was the licence count last reviewed against the staff list, when was the connected-apps list last examined, is there a written leaver process. Where the answer is that it happens when someone remembers, that is not in-house administration; it is an intention.

Accounts belonging to people who left. They persist because deleting one feels irreversible and nobody owns the decision, so each becomes both a licence you are paying for and a credential that still works. The second most common is the mover problem — someone changes role, gains the new access and keeps the old, and over several years accumulates access to almost everything without anyone granting it deliberately.

Only the administrative access you grant, and that is a decision you make rather than a condition of the service. Some clients grant a delegated admin role so we can act quickly; some grant access only when there is a specific task; some keep everything in-house and use us for review and advice. All three work. The super-admin accounts remain yours throughout, and every change that removes access or alters policy is yours to approve.

The sequence matters more than the individual steps. Suspend the account first, which stops access immediately without destroying anything. Delegate or forward their mail to a named successor for a defined period. Transfer their Drive files to their manager or into the relevant Shared Drive. Remove them from groups, aliases and any delegated access. Only then delete or archive, and only once the transfers are verified. Doing it in the wrong order is how correspondence gets lost, and deleting first is the mistake that cannot be undone after the recovery window closes.

Yes, and it is a large share of what we do. The first piece of work is usually documenting what is actually configured — organisational units, groups, admin roles, sharing policy, connected applications, dormant accounts. That audit is frequently the most valuable part of the engagement, because it turns a system nobody fully understands into one with a written description.

Scoped and quoted separately from licences, based on user count and how much of the work you want handled rather than advised on. We quote it as an explicit line rather than folding it into a licence rate, so you can see what it costs and decide whether it is worth it. The requirement call and the quote are free.