When something about technology hurts, most owners reach for a single mental bucket: IT people. But the market splits that bucket three ways, and each type of firm is built — and paid — to do a different job:
- A managed service provider (MSP) keeps your technology running.
- A business systems consultant works out how your business and its systems should fit together.
- An implementation partner builds and deploys a specific system once you've chosen it.
None of them substitutes for the others, and each one, asked a question outside its lane, will usually give you an answer from inside its lane. That's the trap this guide helps you avoid.
The MSP: keeps the lights on
An MSP is your outsourced IT department. Helpdesk when a laptop dies, email and network administration, security monitoring, patching, backups, and someone to call at 7 a.m. when nothing works. MSPs typically charge a monthly fee per user or device, which is exactly right for what they do: keeping technology healthy is an ongoing job, not a project.
You need an MSP when the pain is operationalized technology itself — outages, slow machines, security anxiety, no in-house IT staff, or a compliance requirement that demands professional management. If that's your situation, hire a good local MSP. It's the right tool.
What an MSP won't fix: work that flows badly between people and systems. If your team re-types the same order into three tools, your MSP can make all three tools run flawlessly — and the waste survives untouched, now with excellent uptime.
The business systems consultant: decides what should exist
A business systems consultant starts from the work, not the technology: how orders, jobs, information, and handoffs actually move through your company; where they snag; which of your systems help and which just accumulate. The output is clarity — the real problems named, the fixes prioritized, and a roadmap for what to change, buy, retire, or integrate, in what order. The role is diagnostic and architectural, so it's typically a fixed-scope project, not a subscription.
You need a consultant when the business feels harder to run than your size should warrant: reports nobody trusts, spreadsheets doing jobs software should do, a CRM your team quietly abandoned, or a major purchase looming — a CRM, an ERP, a field-service platform — that you don't want to get wrong. That last case is the big one. The most expensive technology mistakes growing businesses make are made at selection time, and they're usually process problems wearing a software costume. (We've catalogued the recurring ones in common technology mistakes growing businesses make.)
What a consultant won't do: answer the helpdesk, run your network, or (if they're honest) camp in your business forever. And one structural point matters more than any credential — the advisory role should be economically independent. Whoever helps you decide what to buy shouldn't earn money from what you buy. A consultant who resells software or collects platform commissions has the same incentive problem as the vendor's own sales team, just one step removed.
The implementation partner: builds what was decided
Implementation partners (integrators, certified partners, solution providers) configure and deploy a specific platform: they migrate your data into the new ERP, configure the CRM to your pipeline, build the integrations, and train your people. Good ones are worth every dollar — deployment is a craft, and botched rollouts are how promising software becomes shelfware.
You need an implementation partner when the decision is genuinely made and well-founded, and what remains is execution.
What an implementation partner won't tell you is that their platform is the wrong fit. That's not dishonesty; it's their business model. A certified partner for platform X sells X implementations. Ask them whether you need X and you will learn a great deal about what X can do. That's precisely why the what should we buy question belongs with someone who has no stake in the answer.
Match the symptom to the role
- "Computers are slow, email breaks, we worry about security." → MSP.
- "We have no one to call when technology fails." → MSP.
- "We bought software and nobody uses it." → Consultant first — adoption failures are almost always process-fit failures, and buying the next tool repeats the cycle.
- "Everything runs on spreadsheets and one person's memory." → Consultant.
- "Every department reports different numbers." → Consultant.
- "We know we need a CRM/ERP but don't know which." → Consultant for the decision, then an implementation partner for the build.
- "We chose the platform; now it needs to be configured and our data moved." → Implementation partner.
How the three work together
In a well-run engagement the roles form a sequence, not a rivalry: the consultant diagnoses and designs, the implementation partner builds to that design, and the MSP operates the result. The consultant's roadmap also makes the other two firms measurably better at their jobs — the implementer builds against defined requirements instead of guesses, and the MSP inherits a simpler, more coherent environment to maintain.
The order matters. Businesses that start with the implementer get a beautifully deployed answer to the wrong question. Businesses that start with the MSP get very reliable versions of their existing problems. Start with the diagnosis; it's the cheapest of the three and it de-risks the other two.
Where we sit
Applied Architecture Group is the middle role, on purpose. We're a vendor-neutral business systems consultancy: we don't provide IT support or managed services, we don't resell software, and we don't take commissions — so our recommendations have nothing to steer them but the work itself. Our standard first engagement is a fixed-scope Business Systems Assessment: a clear picture of how your business runs today, where the friction and risk sit, and a prioritized roadmap you keep whether or not you ever hire us again. If what you actually need is an MSP or an implementer, the assessment will say so — that's what neutrality is for.