When to Decline a Client

Declining revenue is uncomfortable and sometimes correct. The signals are usually present during the sales process and are usually ignored.

The commercial decision in “When to Decline a Client” is stronger when it rests on consistently recorded delivery effort rather than memory. An MSP can use time reporting tools to relate time to clients, projects and recurring tasks, while keeping service quality, contractual scope and customer outcomes as separate measures.

For an independent operational benchmark, compare the local practice with official ITIL resources; the important test is whether the control remains proportionate, documented and recoverable when the usual technician is unavailable.

The signs in the estate

Substantial unsupported software with no budget to replace it.

No backups, or backups nobody has tested.

Shared administrator credentials everywhere and resistance to changing them.

Equipment well past its life, with a refusal to refresh.

Each is fixable; a combination with no funding is a commitment to carry somebody else's accumulated risk.

The signs in the relationship

A previous provider terminated recently, with an account of events that blames them entirely.

Unwillingness to sign anything that constrains them.

Pressure to start before discovery.

And a budget that assumes you will absorb remediation, which is the clearest single indicator.

The security position specifically

You will hold administrator access to their environment and your platform will reach it.

A client who declines basic controls — multi-factor on their own systems, removing shared credentials, replacing unsupported systems — is a client whose compromise becomes your incident.

And your other clients share the platform, which is the consideration that elevates this above commercial judgement.

The conditional yes

Better than a flat refusal in most cases.

"We will take this on provided these four things happen in the first ninety days, funded, and here is what each costs."

Written into the engagement.

Clients who accept become good clients; clients who refuse have told you something useful without anybody having to decline.

Declining well

Specifically and without insult: this estate needs work we cannot do within a managed fee, here is roughly what it would cost, we would be glad to revisit.

Referrals where appropriate.

Providers who decline clearly get referrals back, and the industry is smaller than it looks.

The existing client version

Harder: a client already on the books whose risk or cost has become unacceptable.

Raise it with figures, offer the conditional path, give notice if it is declined.

And offboard properly, which its own note covers and which matters most precisely when the parting is unwanted.

Checking yourself

The temptation is strongest when revenue is tight, which is when judgement is worst.

Write your criteria down while things are comfortable.

A standing list of what you will not take on is worth more than a decision made in a difficult quarter.

What to check

Do you have written criteria for declining?

When did you last decline anything?

Does your onboarding allow a conditional yes?

And is there a client on your books who would fail your own criteria today?

The point

Write your criteria for declining while things are comfortable.

The temptation is strongest when revenue is tight, which is when judgement is worst.

Underlying all of this

Everything in this collection reduces to four habits: tune until every alert is read, verify rather than assume at every stage from ring one to script execution, treat the console as the privileged system it is, and know what each client costs you. None needs a better platform, and a provider doing all four runs a quieter service than one twice its size.

The recurring pattern

The recurring pattern across every section here is the same: the appearance of control substituting for control. An unread alert queue looks like monitoring. A compliance percentage that excludes pending reboots looks like protection. A script that reports success looks like automation. In each case the provider believes a risk is handled and it is not, which is worse than knowing it is open.