Keep Client Admin Contacts Current Without Guessing Who Can Authorise IT Requests

For a small managed service provider, the person recorded as a client's administrator is often the person an engineer asks to approve important work. That makes the contact register part of the MSP's operational control system, not simply an address book. If a customer changes finance manager, leaves the company or appoints a new office coordinator, the provider must know whether the change concerns notifications, authority to request ordinary support, the ability to approve spending, or permission to authorise access and infrastructure changes. A well-run contact update preserves each of those distinctions and avoids letting a familiar email signature become authority for a consequential action.

The danger is most obvious when a message asks the helpdesk to remove an existing contact and replace them immediately. It may be a legitimate handover, but it may also be a misunderstanding, a compromised mailbox or an instruction from someone without the appropriate standing. The right response is not to distrust every client message. It is to use the previously agreed verification route, identify the exact roles being transferred and confirm that the next technician can find the new arrangement. This article describes a practical approach for a UK MSP supporting several small organisations, without assuming a universal contract or granting privileges merely because a CRM record was edited.

Separate four different client contact responsibilities

A general support contact may report faults, while a service owner approves changes, a billing contact receives invoices and an emergency contact answers during a major incident. One employee can legitimately hold several responsibilities, but each should be separately identified in the client agreement or approved register. A request to change the person receiving monthly reports does not necessarily give the replacement power to approve a privileged account or an expensive infrastructure project. Likewise, removing someone from a mailing list does not revoke their identity-provider access.

Write the role in practical terms: what kind of request the person can submit, which changes they can approve, and which communication should reach them. Avoid vague labels such as 'main contact' when they are used to make security decisions. If the client's process uses spending thresholds or multiple approvers, preserve those existing rules without inventing new ones. The helpdesk should be able to distinguish a contact for information from a decision-maker with actual authority.

Identify the exact change and the request's provenance

Record the client, old contact, proposed contact, effective date, affected roles and source of the instruction. A person asking to be copied on all future tickets may only need a communication preference, while somebody requesting approval rights for a new office manager needs an authority decision. The ticket should quote the approved change precisely enough that another technician can understand it, but should not reproduce unnecessary personal data. Check the relevant existing register before assuming the old contact is still current or that the new person has never been recorded.

Confirm whether the instruction is temporary. A manager covering leave may need a finite responsibility rather than an indefinite replacement. For a business restructuring several teams, there may be multiple simultaneous contact changes. Treat each authority role explicitly; a single broad update risks erasing responsibilities that were not intended to change.

Verify a sensitive replacement through an established channel

A change to who can approve privileged access is itself security-sensitive. An email appearing to come from the current approver may be legitimate, but its display name and signature are not sufficient assurance if the request affects consequential authority. Use the verification method agreed with the client, such as an existing authenticated service request process or a confirmed authorised contact. If the original approver has left, use the documented escalation or contingency contact rather than relying solely on the proposed replacement's assertion.

Record who verified the instruction and what evidence was accepted, without storing passwords, one-time codes or sensitive identity documents in ordinary tickets. Where evidence is contradictory, leave the authority change pending with a named escalation. Business continuity matters, but bypassing verification to meet a ticket target can create a much larger incident.

Keep contract scope and technical permissions distinct

Changing a client contact is an administrative governance action. It does not automatically create, disable or elevate a Microsoft 365 user, change a firewall administrator or assign shared mailbox permissions. If system access must be altered as part of the same personnel change, raise linked starter, mover, leaver or access requests under the relevant approval and technical controls. Keep the references connected so the organisation can confirm the whole transition without collapsing separate authorisations into one CRM update.

Conversely, an employee account that has been disabled may still appear as the contract contact in support records. The identity team and service manager need to coordinate changes, but the technical account state does not necessarily determine who legally represents the business for a purchase or service change. Document the authoritative business instruction rather than guessing from directory membership.

Update every operational place where the role is used

Small MSPs commonly hold contacts in a CRM, ticketing application, password-protected client runbook, emergency escalation sheet and supplier portal. Determine which record is authoritative and which systems copy or cache the information. Update the intended fields consistently and verify that frontline staff can see the new contact in their normal workflow. A successful CRM save is not proof that the emergency number in a local runbook has changed.

Do not erase historical approver details from old tickets. They may be required to explain decisions made while that person was authorised. Instead preserve the effective dates and ensure current instructions clearly identify the new role holder. Where external suppliers have their own authorised contact register, confirm which party is responsible for notifying them and whether their acceptance is still pending.

Reassess in-flight tickets and waiting approvals

Review open incidents, procurement requests and changes that depend on the contact being replaced. Some previous approvals remain valid, while new decisions may need the new authorised person. Avoid automatically cancelling every task or assuming all old approvals are invalid. Identify the specific requests with a genuine dependency and pass them to the correct owner for a proportionate decision.

For an urgent incident, confirm who should receive status updates and who can authorise disruptive recovery work. A contact changed at noon can leave the evening on-call team using an obsolete escalation route if the handover is not explicit. Test the relevant path through a permitted contact confirmation, without generating false emergency alerts.

Use effective dates and review triggers carefully

Some contact changes take effect immediately after authorised confirmation; others relate to a planned employee transition or supplier handover. State the actual start date, fallback during the transition and who can resolve ambiguity. An old contact may remain valid for invoicing while a new contact handles daily operations. A temporary cover arrangement should have a review point and responsible business owner so it does not become an unexplained permanent authority.

Where multiple clients have similar names, verify the tenant and contract identity before bulk-updating. Do not copy one organisation's approver into another's records merely because the two companies share an outsourced office manager. Keep the change limited to the exact customer identity and relevant service scope.

Confirm communications and authority work as intended

Once the records are updated, check a frontline ticket view and any relevant approval prompt to ensure the right person appears. Where appropriate, ask the client's authorised representative to confirm that the requested roles and contact channels are correct. Sending an email is not proof the new contact accepted responsibility or can use the client portal. Record the actual result and any outstanding supplier acknowledgement, rather than claiming the whole process is finished because one database field changed.

Test only the permissions or communication capabilities relevant to the approved scope. An account role change belongs to its own access request and verification. The service desk should not demonstrate an approver's power by performing a consequential live change that the client has not authorised.

Protect personal data and maintain an auditable register

Contact registers contain names, business contact details, roles and sometimes escalation numbers. Keep only the information needed for the service agreement, apply appropriate access and retention controls and avoid exposing personal numbers in broadly shared documents. Provide a clear way for authorised client owners to review the information and report corrections. A long history of copied spreadsheets can be more dangerous than a concise, trusted register with a controlled revision trail.

Preserve who made the decision, who applied it and the observed result. If a dispute arises later, the MSP should be able to explain which authorisation was current when a significant change was approved. That is different from retaining every email or private conversation indefinitely.

Use recurring errors to improve the client onboarding process

When a contact cannot be reached during an incident, investigate whether the register was stale, the client never designated a backup or the on-call team used the wrong tool. If frequent requests say 'make this person the admin', update the request form to distinguish communication, financial and security authority. A clearer template can prevent repeated clarification without creating an oppressive approvals process for ordinary address changes.

Include a focused contact review during service meetings and after known organisational changes. Confirm key roles with the authorised client and document any unresolved gaps. Do not assume an annual check is sufficient for every client; significant changes may need immediate review. The outcome is a reliable answer to who can decide what, not a larger list of names.

Close the change without leaving hidden dependencies

The request is complete when the client-authorised role changes are recorded, effective dates are clear, operational systems agree and affected open cases have been handled. Remaining identity work or external supplier updates should have explicit owners and linked references. A tidy ticket status is not a substitute for a functioning escalation route and correct approval authority.

The practical discipline is simple: verify the instruction through a trusted route, change only the intended responsibilities and check what the next technician will actually see. This protects client relationships while reducing the chance that an informal contact edit becomes an unauthorised technical or commercial decision.

References: UK NCSC identity and access management guidance for appropriate identity governance; Microsoft Learn, role-based access control for the distinction between roles and privileges. Neither defines a customer's contractual authority; the client agreement remains decisive.