
Start With the Work, Not the Shortlist
The usual first move is to collect three proposals. You then spend a fortnight comparing three documents, each written to look good beside the other two. The thing you are actually buying stays out of sight the whole time.
Start with a list of the work instead. Write down every technical job that happens in a normal month, who does it now, and roughly how long it takes. Include the jobs nobody has a name for. The person in accounts who resets the billing password. The operations lead who restarts the machine in the warehouse. The director who approves new staff by replying to an email.
That list is your real scope. When a proposal does not mention half of it, you have learned something before the first meeting, and you have learned it about the proposal rather than about the person presenting it.
Read the Service Description Before the Price
A price per person is only comparable when the service behind it is. One company's number covers the servers, the firewall, the backups and the email. Another covers the laptops and bills everything else as a project. Both can be honest. They are not the same number.
Find the line between support that is included and work that is charged. That line is where nearly every argument in this kind of relationship happens. A company that has written it down plainly has had the argument before and decided to stop having it.
Check the hours against how your business actually runs. If the warehouse starts at five in the morning and the desk opens at nine, you have bought four hours a day of nobody answering. You will find that out on a morning when it matters.
Ask How the First Month Is Spent
How they start tells you what the next three years look like. A team that plans to learn your systems while clearing your tickets will stay a step behind for as long as you keep them, because they never get in front of the work.
A serious plan separates three jobs and puts dates on each. Finding out what exists. Writing it down so a different engineer can use it at two in the morning. Fixing the things the first two turned up. That third list exists in every business without exception. Anyone who tells you their onboarding produces no such list either did not look or would rather not say.
Ask to see a real one from another client with the names taken out. Whether they are willing to show you tells you as much as what is on it.
Find Out Who Actually Answers
There is a real difference between a desk where the next free engineer takes the next ticket and a desk where the same few people handle your account. Neither is wrong. The first answers faster when everything is busy. The second knows your setup, which is what stops you explaining your own business to a stranger every time something breaks.
Ask what happens when a ticket gets stuck, who decides to push it up, and what gets handed over at the end of a shift. An escalation path that exists only as a diagram runs on whoever happens to be free that afternoon. That works until the day it does not.
It is worth asking plainly how many clients one engineer looks after, and how they know when that number has got too high. The answer matters less than whether anybody is counting.
Test the Exit Before You Sign the Entry
Read the ending clause first. It describes the relationship more honestly than the front page does, because it was written for the day goodwill runs out.
Four things are worth settling in advance. Who owns the documentation written during the contract. Whether the administrator passwords for your own systems come back to you in full, and how quickly. Whether the monitoring, patching and security tools are licensed to you or to them, so you know exactly what stops working the day you leave. And whether help with the handover is included or charged by the hour.
A company that is relaxed about a clean exit usually expects to keep you for other reasons. One that leaves it vague is telling you where its grip is.
Judge the Review, Not the Report
Every provider sends a monthly report and nearly all of them are green. The meeting is the thing that matters, and what to watch for is whether they arrive with problems you had not raised yourself.
A good review covers what changed, what is about to stop being supported, which repeat tickets point at a cause nobody has funded a fix for, and what should happen next quarter. A poor one reads out ticket counts and asks whether you are happy with the service.
Ask to see a real review pack before you sign, again with the names removed. If every recommendation in it is something to buy from them, you have learned what the meeting is for.
The Omegaswift engineering team
Support and delivery at Omegaswift. Filed under Managed Services.


