How to Run an IT Spot Check

A spot check turns a vague doubt ("I'm not sure our agency is doing a good job") into evidence ("four of the ten tickets we reviewed were closed without a real fix"). This guide walks you through doing one yourself.

Plan for two to four hours of focused work for a small spot check, spread over a few days so you can collect material and ask questions.

Step 1: Pick one thing to check

A spot check works because it is narrow. Choose a single subject:

• one vendor (a development agency, an IT provider, a SaaS platform),
• one internal team or role,
• one recurring process (onboarding new employees, monthly reporting, patching, backups).

Then write down, in one sentence, the question you want answered. For example:

"Are the support tickets our IT provider marks as resolved actually resolved?"

If you cannot write the question in one sentence, the scope is too broad. Split it and pick one.

Step 2: Define what "good" looks like

Before you look at anything, write down what you expect to see if the work is good. This prevents you from adjusting your standards after the fact.

Sources for your standard, in order of strength:

1. The contract or SLA. Response times, deliverables, quality commitments.
2. What was promised in writing. Proposals, estimates, emails, statements of work.
3. Your own reasonable expectations, written down before you look.

Turn these into three to six concrete criteria. Good criteria can be answered with yes or no for each item in your sample:

Criterion	Example
Delivered on time	Resolved within the SLA response window
Actually fixed	Problem did not reappear within 30 days
Documented	Ticket explains what was done, not just "fixed"
Communicated	Requester was informed when it was resolved

Step 3: Choose your sample

The sample is the heart of the spot check. Two rules matter more than the size.

Do not let the person being checked choose the sample. If you ask a vendor for "a few examples of your work", you will get their best work. Pull the sample yourself from the full list.

Mix random and targeted items. Take most of the sample at random, so it represents normal work. Add a few deliberately chosen items where you expect problems, such as the largest task, the one with the most complaints, or the most recent rushed change.

How many items? For a first spot check, 10 to 20 is usually enough to see a pattern. If the first ten are all clean or all bad, you rarely need more. If the results are mixed, extend the sample.

Step 4: Review each item against your criteria

Go through each item and score every criterion: yes, no, or can't tell. Write a short note for every "no" and every "can't tell".

Keep it in a simple table:

Item	On time	Fixed	Documented	Communicated	Note
#1042	Yes	Yes	No	Yes	Only "done" in ticket
#1057	No	Yes	Yes	No	3 days over SLA, no update
#1063	Yes	No	No	Yes	Same issue reopened as #1088

"Can't tell" is a valid and important result. If you cannot verify whether work was done properly, that lack of visibility is itself a finding.

Step 5: Ask, then verify

For items that look problematic, ask the person or vendor responsible for an explanation. Do it in writing and stay neutral: "Can you walk me through what was done on #1063? We see the same issue reported again two weeks later."

Sometimes there is a good explanation you did not have. Sometimes there is not. Either way, note the answer, and where possible verify it rather than taking it at face value.

Step 6: Look for the pattern

Now step back from individual items and count:

• What share of items met all criteria?
• Which criterion failed most often?
• Are the problems spread out, or concentrated in one type of work, one period or one person?

The pattern is what makes a spot check useful. One bad ticket is an incident. The same criterion failing in a third of the sample is a process problem.

Step 7: Write it up on one page

Your write-up should fit on a single page and contain:

1. The question you set out to answer.
2. The standard you checked against, and where it came from.
3. The sample: how many items, how you chose them.
4. The results: the numbers from step 6, plus two or three concrete examples.
5. Your verdict: in line with expectations, partly, or not.
6. Next step: what you will do now.

That last point matters. Typical next steps are: no action and repeat in six months, a conversation with the vendor with the findings in hand, a larger sample, or a broader review if the problems look systemic.

Common mistakes

• Checking everything. A spot check that grows into a full review loses its main advantage, which is speed.
• Letting the vendor pick examples. You will learn what their best work looks like, not their normal work.
• Setting the standard after looking. You will unconsciously adjust it to what you found.
• Ignoring "can't tell". If you cannot see whether work is good, you are relying on trust alone.
• Stopping at the findings. Without a next step, the spot check is just a document.

When to bring in outside help

A do-it-yourself spot check works well for processes and vendors you understand. It gets harder when judging quality requires technical expertise: code quality, security configuration, cloud architecture, or whether an estimate was reasonable. In those cases, an independent reviewer can apply the same method with the background to judge what they see.

Not sure whether a spot check is enough? Read Spot Check vs. Full IT Audit.