Choosing the wrong PSA consultant is expensive in ways that aren't immediately obvious. The invoice gets paid, the project gets delivered, and six months later you're dealing with a billing configuration that doesn't match your contracts, automations that fire inconsistently, and a team that's working around the system instead of through it.
The problem is rarely that the consultant didn't know the platform. It's that they knew it well enough to configure it, but not well enough to configure it for your operation. PSA implementation is not a generic technical exercise — it's a translation between how your business works and how a complex software platform can be made to reflect that. Getting that translation right requires experience that goes beyond reading documentation.
These seven questions are designed to help you tell the difference.
This sounds obvious, but it's the question most MSPs forget to ask explicitly. A consultant who has implemented ten PSA platforms at a surface level is not the same as a consultant who has implemented one platform deeply, many times, across different MSP sizes and configurations.
Platform-specific depth matters because PSA platforms are not interchangeable. The billing model in one platform is fundamentally different from another. The automation engine has different capabilities. The way contracts, work types, and exclusions interact is specific to the platform. A consultant who knows the platform well will design your configuration to work with its native logic — not against it.
Ask for specific examples: which versions have they worked with, what types of configurations have they built, what are the platform's known limitations and how have they worked around them. Vague answers to specific questions are a signal.
What a good answer looks like: Specific version experience, a clear understanding of the platform's strengths and weaknesses, and examples of non-standard configurations they've handled.
Volume matters, but not in isolation. Ten implementations done carelessly teach less than three done with rigour. What you're really asking is: have they seen enough variation to recognise your situation, and have they made the mistakes that produce genuine expertise?
A consultant who has only implemented for MSPs identical to yours will struggle when your operation has a non-standard billing structure, an unusual team configuration, or a legacy contract setup that doesn't map cleanly to the platform's defaults. Breadth of experience — different sizes, different billing models, different tool stacks — is what produces the pattern recognition that separates a good consultant from an excellent one.
Ask about the range, not just the number. Small MSPs, mid-sized MSPs, complex billing environments, simple ones. Migrations from other platforms and fresh implementations. Each scenario produces different lessons.
What a good answer looks like: A range of implementation types with specific examples, honest acknowledgement of which scenarios they find most challenging, and a clear sense of what makes each engagement different.
Size matters in PSA implementation for reasons that aren't always obvious. A 5-person MSP and a 50-person MSP are not just different in scale — they have fundamentally different operational requirements. The ticket categorisation structure, the SLA configuration, the billing complexity, the number of contracts, the team structure — all of these compound with size in ways that require different configuration approaches.
Complexity matters independently of size. An MSP with a simple, standardised service catalogue is a different engagement from one with highly customised billing arrangements, multiple contract types, and a history of acquired companies with inconsistent processes. A consultant who has only worked with straightforward setups may not have the experience to navigate the edge cases that complex operations generate.
Be specific about your situation: your headcount, your billing model, the number of active contracts, any non-standard arrangements you have. A good consultant will immediately start asking follow-up questions — that's a sign they understand what makes your situation distinctive.
What a good answer looks like: Relevant examples at comparable scale and complexity, specific acknowledgement of what makes larger or more complex engagements harder, and intelligent questions about your specific situation.
This is the question that separates consultants who have done difficult migrations from those who have only done easy ones. Historical data migration — ticket history, contract records, billing data, asset information — is where PSA migrations most commonly go wrong, and where the consequences are most expensive.
The right answer involves treating data migration as a separate workstream with its own timeline, validation process, and acceptance criteria. It involves a data audit before migration begins, mapping between source and destination data structures, and parallel validation before cutover. It does not involve "we'll export a CSV and import it" as a complete answer.
Listen for specificity. What is their process for data mapping? How do they handle data that doesn't map cleanly between platforms? What does their validation process look like? How do they handle discrepancies discovered after migration? A consultant who has done this well will have detailed answers. One who hasn't will be vague.
What a good answer looks like: A defined migration methodology, specific examples of data migration challenges they've navigated, and a clear validation process before go-live.
Scope clarity is where many consultant relationships go wrong. An engagement that sounds comprehensive at proposal stage can turn out to have significant gaps when the project is underway — integrations that weren't scoped, configurations that require additional work, training that wasn't included.
Ask for an explicit breakdown: what is in scope, what is out of scope, and what are the most common additions that come up in engagements like yours. A good consultant will be direct about this because they've learned through experience what assumptions cause problems. A consultant who is vague about scope is either inexperienced or deliberately leaving room for scope creep.
Also ask about what happens after go-live. Is there a support period? How are post-go-live issues handled? What does ongoing optimisation look like? The initial implementation is the beginning of the configuration process, not the end — a good consultant will acknowledge this.
What a good answer looks like: A clear scope breakdown, honest acknowledgement of what typically falls outside standard scope, and a defined approach to post-go-live support.
In consulting engagements, the person who sells the work and the person who delivers it are not always the same. This matters because the expertise that makes a proposal compelling needs to be present in the room — or on the call — when configuration decisions are being made.
Ask explicitly: who will be leading the technical work? Will you have direct access to that person, or will communication be routed through a project manager? What happens if that person becomes unavailable during the engagement?
For a PSA implementation specifically, continuity matters. The consultant who designs your billing arrangement needs to still be available when you discover an edge case three weeks into the project. Handoffs mid-engagement — to a junior consultant, to a different team — are a risk that's worth surfacing before you sign.
What a good answer looks like: A named person with verifiable experience, direct access throughout the engagement, and a clear plan for continuity if circumstances change.
This question reveals more about a consultant's approach than almost any other. A consultant who measures success by "going live on time" has a different value system from one who measures it by "your billing output is accurate and your team is using the system effectively three months after go-live."
PSA implementations that go live on schedule but leave the client with a misconfigured billing setup, an undertrained team, or automation rules that fire incorrectly are not successful. They're just finished. The difference matters enormously for the MSP living with the consequences.
The best consultants define success in operational terms: what does a well-configured system look like for this specific MSP, what metrics indicate it's working correctly, and what does the handover process look like to ensure the internal team can own and maintain it going forward.
One specific red flag to watch for: a consultant who commits to your go-live date without first fully scoping the project. It's common for MSPs to have a date in mind — a contract renewal, a team restructure, a fiscal year deadline — and to communicate it early in the conversation. A consultant who simply agrees to that date, without first understanding the full complexity of your operation, your data, and your configuration requirements, is telling you something important: they're prioritising winning the engagement over delivering it correctly.
The right consultant evaluates the project in its entirety before committing to a timeline. They ask about your billing complexity, your data migration requirements, your team's availability for training and testing. They provide a timeline based on what the project actually requires — not on the date you had in mind. If that timeline is longer than you hoped, a good consultant will explain why and help you understand what can be done to accelerate safely. One who simply tells you what you want to hear is setting you up for a go-live that happens on schedule and fails in operation.
What a good answer looks like: Operational success criteria specific to your situation, a defined handover process, a follow-up mechanism to identify and address issues after go-live — and a timeline that was earned through proper scoping, not agreed to close the sale.
These questions aren't a checklist to run through in a single call. They're a framework for evaluating the quality of thinking a consultant brings to your engagement. The answers matter less than what the answers reveal — whether the consultant has genuinely done this work, genuinely understands your situation, and genuinely cares about the outcome rather than just the invoice.
A consultant who answers all seven questions well may still not be the right fit. One who struggles with two or three of them is telling you something important. Use the questions to have a real conversation rather than a sales pitch.
At Kinesys, we're happy to be asked all of them.
If you're evaluating PSA consultants for an implementation, migration, or optimisation project, we're happy to answer every question on this list — and any others you have.
kinesys.it • info@kinesys.it • HaloPSA Official Partner & Autotask Experts