ERP Selection for SMEs What the Mid-Market Should Weight

What SME ERP selection really means (and what it does not)

SME ERP selection is the weighting exercise a 10-250 staff organisation goes through to decide which ERP fits the realities of its size band - not the generic vendor shortlist, and not the small-business price hunt. The mid-market sits in an awkward middle: too complex for the lightweight SMB playbook, too lean for the enterprise program model. The decisions that actually decide outcomes at this size are which selection criteria to weight heavily, and in what proportion, given a constrained budget, a thin internal team, and a growth roadmap that will probably add entities, geographies, or functions within the system's useful life.

This guide is deliberately scoped to the weighting question. If you want the structured process - cross-functional team, requirements, RFI/RFP, scripted demos, scoring matrix, reference checks, contract negotiation - that lives in our ERP vendor selection guide. If you are closer to the small-business end and the dominant question is which platform gives the lowest entry price for your stack, our best ERP for small business framework is the right cut. Both overlap this guide at the edges, but neither addresses the specific question a mid-market operator faces: of all the criteria every ERP claims to satisfy, which ones actually move the needle for a 10-250 staff company, and how should the weighting shift as you move from a lean 10-person growth firm to a 250-person multi-entity operator?

The reason weighting matters more than methodology at this size is simple economics. A mid-market ERP is a 5-10 year commitment whose total cost of ownership typically lands in the hundreds of thousands to low millions of dollars, and whose success or failure is dominated by organisational and resourcing factors rather than feature checklists. Getting the weights wrong - over-weighting sticker price, under-weighting internal skills, ignoring multi-entity headroom - is how otherwise competent companies end up with a system that fits the demo and breaks the business three years in.

The three pillars every SME should weight first

Across analyst guidance, implementation-partner consensus, and the failure patterns that recur at this size, three criteria deserve to be weighted before everything else for a 10-250 staff organisation. The first is budget realism: not the lowest price, but an honest model of what the system will actually cost over five years once implementation, internal staff time, training, and escalation are included. The second is in-house skills: how much of the ongoing operation and future change your team can absorb itself, versus how dependent you will be on a vendor or partner for every modification. The third is growth headroom: whether the platform can absorb new business units, geographies, and functions without a rip-and-replace or a parallel second system.

These three are not the only criteria that matter. Functional and industry fit, ease of use and adoption, integration depth, deployment model, and vendor financial stability all belong in a complete scorecard - and several of them are covered in depth in the vendor selection guide. But for the mid-market band specifically, the three pillars are where selection is won or lost, because they are the ones that compound over the system's life and the ones mid-market buyers most consistently under-weight. A system that wins the functional demo but busts the 5-year budget, or that only your partner can change, or that cannot consolidate a second subsidiary, is a mid-market failure waiting to happen.

The rest of this guide works through each pillar in turn, then gives you a weighting framework that adjusts the proportions for three common SME sub-profiles - because a lean cost-sensitive growth firm, an established single-entity operator replacing legacy accounting, and a multi-entity scaler should not weight the same criteria identically.

Budget realism: model the five-year number, not the monthly fee

The single most common budget failure at this size is treating the per-user subscription as the cost of the system. It is not. Across mid-market deployments, software licensing typically accounts for only about 20-30% of total ERP spend; the remaining 70-80% sits in implementation services, data migration, internal staff time, training, ongoing support, infrastructure, and future upgrade work. Analyst guidance puts the under-estimate bluntly: most organisations miss true ERP total cost of ownership by 40-60% when they rely solely on vendor-quoted software costs. A mid-market buyer who anchors on sticker price is therefore anchoring on roughly a quarter of the real number.

Spending is also heavily front-loaded, which is what strains a mid-market budget most. Year 1 typically absorbs 45-65% of a five-year TCO, driven by implementation, migration, and training, before the system settles into a more predictable steady-state run rate. For a 100-user mid-market deployment, that steady-state annual operating cost commonly runs $120,000-$350,000 per year. A defensible SME budget is a year-by-year cash-flow model across five years, not a single lump sum, and it is the front-loaded Year 1 shape that determines whether the project survives its own go-live.

Where a mid-market firm lands on the cost spectrum depends heavily on which vendor tier it chooses. For a 100-user deployment over five years, budget and open-source platforms such as Odoo or ERPNext typically run $150,000-$500,000; mid-range systems such as Sage Intacct, Acumatica, and SAP Business One run $400,000-$1.5 million; premium platforms such as NetSuite, Dynamics 365, and Epicor Kinetic run $800,000-$3 million. Enterprise systems sit at $2 million and above, well outside the realistic SME envelope. 2026 planning ranges reinforce the same shape at the implementation line: mid-market software is often $5,000-$20,000+ per month, with implementation commonly planned at $75,000-$250,000+ for a focused scope—while year-one total investment for many mid-market programs still lands around $150,000-$750,000 when software, services, migration, integrations, and training are combined. Headcount bands matter: rough implementation ranges of roughly $10,000-$80,000 for 1-50 employees and $80,000-$250,000 for 51-200 employees are useful planning floors, not quotes. The point of the band is not to pick the cheapest tier but to pick the tier whose five-year number your business can fund without starving operations—and to recognise that implementation complexity, not the vendor badge, moves the number more than anything else.

• →Software is roughly 20-30% of total spend; services and internal time are 70-80%
• →Year 1 absorbs 45-65% of a 5-year TCO - model it as cash flow, not a lump sum
• →2026 mid-market implementation is often planned at $75K-$250K+; year-one all-in frequently $150K-$750K
• →Steady-state for a 100-user mid-market deployment typically runs $120K-$350K per year
• →Pick the vendor tier your 5-year number can fund, not the cheapest monthly fee

What an SME should actually put in the budget

Translating budget realism into a line-item budget is where most mid-market planning falls short, because the largest cost categories are the ones vendors have the least incentive to surface. The first hidden line is internal staff time: for a 12-18 month mid-market implementation, the diverted salary cost of your project manager, finance lead, IT administrator, and department heads routinely amounts to $150,000-$400,000, and it almost never appears in the project budget. Add an implicit productivity budget of roughly 10-15% of affected staff's annual salary for the output dip during implementation and the first months after go-live.

The second routinely under-budgeted line is training. Vendors typically quote a one- or two-day end-user programme, but sustainable adoption requires super-user development, role-based curricula, and ongoing reinforcement. A realistic training budget is 8-12% of implementation cost, not the 2-3% vendors quote. The third is annual price escalation: most SaaS ERP contracts include 3-8% annual increases, and an uncapped 5% escalator on a $150,000 subscription adds more than $80,000 over five years. A 10-15% contingency on subscription cost in years four and five covers the restructuring of pricing tiers that vendors frequently introduce at renewal.

Finally, weigh the cost of customisation as a recurring liability rather than a one-time build. Every line of custom code must be regression-tested with each upgrade, and a heavily customised system can cost 30-50% more per upgrade cycle than a clean, configuration-led implementation. The discipline this implies for a mid-market buyer is simple: configure before you customise, adapt processes to the system's standard flows before you bend the system to legacy processes, and treat any customisation as a multi-year maintenance commitment that belongs in the budget, not a one-off build cost.

Two 2026 cost lines deserve explicit SME treatment. First, change management and training: industry practice increasingly budgets 10-20% of project spend for training and adoption work—not the one-day vendor session that shows up in a quote—because projects that underfund adoption are the ones that miss business-case goals even when the software goes live. Second, hypercare: the first 60-90 days after go-live is the highest-risk window; organisations that skip dedicated post-go-live support often pay emergency consulting later. Treat hypercare as a named budget line, not an assumption that 'the partner will be around.'

In-house skills: the hidden variable that decides who runs the system

The second pillar is the one mid-market buyers most often treat as an afterthought, and it is the one that decides who actually controls the system after go-live. A typical 10-250 staff organisation has somewhere between zero and three people who could reasonably be called IT or ERP staff, and usually none of them has prior experience standing up an ERP. That reality has two consequences that should drive weighting: the implementation will consume far more internal time than expected, and the long-term cost and speed of every change will depend on how much of the system your own team can operate versus how much you must outsource.

Name the roles before you shortlist platforms. For a 10-250 staff firm the minimum viable internal spine is usually a finance process owner (chart of accounts, close calendar, approvals, reporting definitions), an operational process owner in the heaviest domain (inventory, manufacturing, projects, or services), and a system administrator who will own users, security, basic configuration, and the partner relationship after go-live. If you cannot name those people—or free roughly 25-50% of their time during the heaviest months of the rollout—you are not selecting an ERP; you are buying a system nobody can operate. Weight platforms by how much day-two change a competent admin can complete without a change order: fields, workflows, reports, and approvals should not require a development ticket.

The internal-time consequence is measurable. Beyond the implementation-partner hours you buy, your own people will spend real, salaried time on requirements workshops, data cleansing, testing, training, and hypercare - and as the budget section notes, that diverted salary is one of the largest single costs of the project. Weighting in-house skills means asking, before you sign, how many internal full-time equivalents the rollout realistically needs, and whether your organisation can free them without gutting business-as-usual. A platform that demands more internal capacity than you have is not cheaper at any price.

The long-term consequence is about configuration versus customisation, and it is where skills weighting becomes strategic. A configuration-led approach - using the system's standard settings, fields, and low-code tools to match your processes - keeps the system operable by a competent internal administrator and keeps upgrades working automatically. A customisation-led approach - bending the source code or building bespoke modules to replicate legacy processes - creates dependency on whoever wrote the code, makes every upgrade a project, and compounds maintenance cost. The mid-market skills question is therefore not just 'can we run it?' but 'can our team evolve it without calling the partner for every report, workflow, or field change?' If the answer is no, that ongoing partner dependency belongs in your TCO model as a permanent line item.

• →Most 10-250 staff firms have 0-3 IT/ERP staff and no prior ERP experience
• →Name a finance process owner, an operational process owner, and a system admin before you shortlist
• →Internal diverted salary is one of the largest single project costs
• →Configuration keeps the system operable internally; customisation creates permanent dependency
• →Model ongoing partner dependency as a permanent TCO line, not a one-off

Vendor-led or partner-led: who actually runs your rollout

Closely tied to the skills pillar is a structural choice that shapes the entire relationship: whether your ERP is implemented by the vendor itself or by an independent partner. The two models behave very differently at mid-market scale, and the choice should be weighted explicitly rather than left to whichever sales channel reached you first. When the vendor both sells and implements, you are typically a smaller customer in a large pipeline, and you are expected to fall in line with the vendor's standardised process. That can mean speed and predictability, but it can also mean less responsiveness and a relationship where attrition is tolerated because the vendor's incentive is weighted toward new sales over retention.

When the ERP is sold through a partner network and implemented by that partner, the dynamic inverts. Implementation partners are themselves usually mid-sized, more responsive, and less bureaucratic, and as a mid-market customer you are typically a larger and more valued relationship for them. Their focus is on successful implementations and long-term retention rather than unit sales. Independent guidance from practitioners who work with mid-sized manufacturers is blunt on this point: a strong implementation partner is frequently the single most important criterion for a mid-sized business, because outcomes depend far more on how the system is used than on which system was chosen.

Weighting this decision means asking hard questions during selection, not after signing. If the vendor implements: how does the relationship transition from sales to delivery, and what is your realistic priority in their queue? If a partner implements: what is the partner's depth in your industry and size band, how many similar rollouts have they completed, and what does post-go-live support look like? Either model can succeed, but the mid-market buyer who treats the implementation relationship as a separate, weighted decision - rather than a bundle that comes with the licence - is the one who avoids the most common post-go-live disappointment: a technically fine system poorly deployed.

Vet the partner as hard as the product. Confirm certified depth in the specific product and your industry; ask how many comparable projects they have completed in your size band; take at least two reference calls with similar companies; meet the named delivery lead (not only sales); and clarify their resourcing model and post-go-live availability. Boutique partners often suit lean SMEs that need senior attention; mid-tier regional partners suit 51-200 staff programs that need several workstreams at once; global systems integrators are usually overkill—and overpriced—inside the 10-250 band unless you are already inside a complex multi-country program. A mid-market buyer who skips partner diligence is effectively randomising the largest driver of outcome quality.

Growth headroom: scaling without a rip-and-replace

The third pillar is the one with the longest half-life, because a mid-market ERP is bought for where the business will be in three to five years, not just where it is today. ERP scalability, properly defined, is the system's ability to accommodate growth - in users, transactions, data volume, entities, or business processes - without compromising performance or requiring a fundamental rearchitecture. Every vendor promises it; far fewer deliver it cleanly, and the failures almost always surface not at the infrastructure level but in how the system was originally configured for future complexity.

The growth scenarios that break mid-market systems are predictable. Adding a second subsidiary or legal entity is the most common: some platforms handle multi-entity through a shared data model with real-time consolidation, while others require cross-entity reporting to be custom-built, leaving teams patching with manual workarounds that erode the agility the ERP was meant to provide. Geographic expansion is the second: a system configured for a single country's tax and currency will not magically support multi-currency transactions or regional compliance such as localised invoicing regimes unless that was modelled at implementation. Adding new functions - e-commerce, field service, advanced manufacturing, a second warehouse - is the third, and it is where modular, add-app-as-needed architectures outperform monolithic ones.

The strategic principle that protects growth headroom is straightforward and unfashionable: build for configurability, not customisation. If each business unit carries its own custom code or bespoke modules, every expansion becomes a mini-implementation, and what was sold as a single scalable platform fragments into a set of connected-but-divergent instances. Mid-market buyers should weight four scalability tests before signing: can the system handle materially higher transaction and user volume; how easily can a new business unit be added with shared master data and automatic consolidation; how cleanly do future tools (e-commerce, logistics, third-party apps) integrate without one-off code; and does the licensing model scale on usage or punitively on headcount.

Growth headroom is also an architecture choice. Some SMEs will stay inside one suite for a decade; others will keep a financial and operational core and attach specialist tools for warehouse, CRM, or field service. That single ERP versus best-of-breed decision should be scored during selection, not after the first integration fire drill. If you already see the signs of outgrowing a narrow system—manual consolidations, spreadsheet workarounds, module gaps—work the scaling-your-ERP levers (activate modules you own, extend selectively, multi-entity, two-tier) before you re-buy the same ceiling with a new logo.

• →Scalability = absorb growth in users, transactions, entities, and processes without rearchitecture
• →Failures usually surface in configuration for future complexity, not in infrastructure
• →Multi-entity, multi-geography, and added functions are the three scenarios that break SME systems
• →Build for configurability, not customisation - or every expansion becomes a mini-implementation

Phased go-live: match delivery to mid-market velocity

Selection is not finished when you pick a product logo. How you stage the rollout is itself a selection criterion, because mid-market businesses evolve while projects run. Enterprises can sometimes absorb multi-year waterfall programmes; 10-250 staff companies usually cannot. If design freezes requirements for a year while sales channels, SKUs, and entities keep changing, go-live becomes a rework programme. That is why modern mid-market selection increasingly weights implementation speed against business velocity: can this platform and partner deliver a useful core in months, then iterate, rather than promising a perfect big-bang cutover that arrives after the business has moved on?

The practical answer for most SMEs is a phased, configuration-first go-live—the same discipline you will later formalise in ERP implementation phases. Phase one typically lands general ledger, AP/AR, the operational spine you cannot run without (inventory, projects, manufacturing, or services), and a small set of integrations. Later phases add secondary modules, deeper reporting, and specialist tools only where the suite genuinely falls short. This approach reduces Year 1 cash risk, improves adoption because users learn a stable core, and preserves growth headroom without forcing a rip-and-replace when the first subsidiary or warehouse arrives. It also disciplines the customise-versus-configure debate: if a process is not needed for phase-one cash and service levels, it does not get custom code in phase one.

Weight platforms and partners on whether they support that model. Ask for a phase map with exit criteria, a named hypercare window, and a clear rule for what is configuration versus customisation. Ask whether business users can change workflows, fields, and reports after go-live without a development queue—the operational-agility test that separates systems an SME can run from systems an SME only rents. Pair this with the growth tests in the scalability pillar: multi-entity, multi-site, and licensing that does not punish headcount growth. If your longer-term path may mix a core suite with a few specialist tools, decide that architecture now rather than discovering it as sprawl later.

• →Mid-market firms rarely survive multi-year frozen requirements without rework
• →Phase one: core finance + critical operational loop + minimal integrations
• →Configuration first; defer custom code until the process is proven necessary
• →Score platforms on day-two admin self-sufficiency, not only demo features

How to weight the criteria: a framework for three SME profiles

Because the 10-250 staff band is wide, a single set of weights does not fit every SME. A lean, cost-sensitive growth firm, an established single-entity operator replacing legacy accounting, and a multi-entity scaler face materially different risks and should weight the same five criteria differently. The framework below assigns percentage weights across total cost of ownership, in-house skills and adoption, growth and scalability headroom, functional and industry fit, and partner and support quality - summing to 100 - for three common mid-market sub-profiles. Use it as a starting calibration for your scorecard, then adjust for your specific context.

The lean growth profile (typically 10-50 staff, single entity, fast-growing, cost-sensitive) should weight budget realism and in-house skills most heavily, because cash and internal capacity are its tightest constraints. Functional fit matters but should not be over-weighted: at this size, standard best-practice processes are usually an improvement over the legacy workflows being replaced, and chasing a perfect functional match risks over-paying. Growth headroom still matters, but the near-term question is whether the platform can be entered cheaply and scaled modularly rather than whether it consolidates multiple subsidiaries today.

The established mid-market profile (typically 50-150 staff, replacing legacy accounting or a patchwork of point tools, one to three entities, moderate budget) should weight growth headroom and functional fit more heavily, because the trigger for replacement is usually that the current setup can no longer handle the business's complexity. Budget realism still matters but is less decisive than ensuring the new system genuinely absorbs the next phase of growth. The multi-entity scaler (150-250 staff, multiple subsidiaries or geographies, consolidation and compliance complexity) should weight growth headroom and partner quality highest, because multi-entity architecture and the partner's ability to deliver it are the decisive success factors, and a wrong choice here is the most expensive to unwind.

Why both the SMB and enterprise playbooks misfit the mid-market

A recurring source of mid-market selection errors is importing a framework built for a different size band. The small-business playbook optimises for lowest entry price and fastest start, which is exactly right for a firm where the alternative is spreadsheets and the budget is genuinely thin - but it under-weights the five-year TCO, internal-skills, and multi-entity questions that a 10-250 staff operator cannot afford to ignore. The enterprise playbook optimises for governance, customisation depth, and global consolidation, which is right for a 250-plus-staff multinational with a dedicated IT function - but it over-engineers the decision, inflates the timeline, and commits a mid-market budget to enterprise-grade complexity the organisation may never need.

The mid-market sits between these in ways that matter for weighting. On cost, the SMB lens is the monthly fee and the enterprise lens is multi-year program governance; the SME lens is the realistic five-year TCO band the business can fund. On internal capability, the SMB typically has near-zero IT and outsources everything, while the enterprise has a dedicated ERP team; the SME has a small mixed team whose capacity must be protected, which makes configuration-versus-customisation and partner dependency disproportionately important. On growth, the SMB asks 'will we outgrow it?' and the enterprise asks 'how does this fit a two-tier global strategy?'; the SME asks 'can it absorb the entities and geographies we will realistically add in three to five years without a parallel system?'

Recognising where you sit on this spectrum is itself a selection decision. A 10-person firm that will stay small may genuinely be best served by the SMB framework; a 250-person multi-subsidiary manufacturer may genuinely need enterprise-grade thinking. But the broad middle of the 10-250 band - the companies this guide is written for - is best served by weighting the three pillars above, calibrated to their sub-profile, rather than by borrowing either neighbour's playbook wholesale.

The selection mistakes that are specific to SMEs

Mid-market selection fails in characteristic ways, and most trace back to a mis-weighted pillar. The first is buying too cheap - anchoring on the lowest per-user fee or a free tier and discovering that implementation, add-on modules, and internal time push the real five-year cost into a band the business cannot fund. The mirror mistake is buying too big: defaulting to an enterprise-grade system on the assumption that bigger is safer, and then committing a mid-market budget and a thin team to complexity and customisation they cannot sustain. Both errors come from weighting the wrong cost lens - monthly fee or brand reassurance - instead of realistic total cost of ownership.

The second family of mistakes is skills-related. Over-customising - bending the system to replicate every legacy process rather than adapting processes to standard flows - turns the ERP into a bespoke system that only the original implementer can maintain, inflates every upgrade cycle, and erodes the agility the purchase was meant to deliver. Under-resourcing the internal team - assuming the partner will carry the project without meaningful internal commitment - is the other face of the same error, and it is a leading cause of the productivity dip and adoption gap that follow go-live. Both stem from under-weighting the in-house-skills pillar.

The third family is growth-related and the most expensive to unwind. Ignoring the multi-entity roadmap - choosing a single-entity configuration because that is the immediate need - leaves the business patching with manual consolidations or a parallel second system when the first subsidiary arrives. Equally damaging is choosing a platform whose licensing model punishes headcount growth, so that adding users raises cost disproportionately just as the business is scaling. Vendor and analyst guidance converges on a set of recurring failure causes that map cleanly onto these three families: unrealistic timelines, fluctuating budgets, lack of leadership buy-in, poor change management, and inadequate data hygiene. For an SME, the weighting discipline that prevents them is to score the three pillars honestly before the demos begin, not after the contract is signed.

A fourth family of mistakes is timeline and change discipline. Midsize companies cannot absorb multi-year waterfall implementations the way enterprises can: during a 12+ month build, products, markets, and processes keep moving, so requirements at go-live no longer match the original design and the customisation cycle restarts. Under-budgeting change management, skipping scripted demos with real data, and signing before naming internal owners are the SME versions of that failure. Prefer a phased, configuration-first go-live that lands core finance and the critical operational loop first, then expands modules—exactly so the business keeps shipping while the system matures.

• →Buying too cheap and buying too big are the same error: weighting the wrong cost lens
• →Over-customising and under-resourcing the internal team both stem from under-weighting skills
• →Ignoring the multi-entity roadmap is the most expensive growth mistake to unwind
• →Score the three pillars honestly before demos, not after the contract is signed
• →Under-budgeting change management and hypercare is how live systems still miss the business case
• →Prefer phased go-lives over multi-year waterfall when the business is still changing

Your SME selection weighting checklist

Pulling the pillars into a sequence, a disciplined mid-market weighting exercise looks like this. First, place your organisation on the size band honestly—lean growth, established mid-market, or multi-entity scaler—and adopt the corresponding starting weights from the framework above. Second, build a year-by-year five-year TCO model that includes the hidden lines: internal staff time, training and change management at a serious share of project spend, escalation caps, customisation maintenance, hypercare, and the productivity dip. Third, assess your in-house skills realistically: name the finance process owner, operational process owner, and system admin; quantify how much of the ongoing operation your team can absorb; and where permanent partner dependency will sit. Fourth, map your realistic three-to-five-year growth in entities, geographies, and functions, and test each shortlisted platform against the four scalability tests—and decide whether you need a single integrated suite or room to bolt specialist tools later.

Fifth, separate the implementation-relationship decision from the licence decision: weigh vendor-led versus partner-led delivery on responsiveness, industry depth, and post-go-live support, and run the partner scorecard above before you shortlist. Sixth, insist on a phased rollout plan—core processes first, configuration before customisation—so the project matches mid-market velocity rather than an enterprise waterfall. Seventh, run the full process—cross-functional team, prioritised requirements, scripted demos, weighted scoring, independent references, and contract negotiation—using the weights you have now calibrated to your sub-profile rather than a generic checklist. A structured process can complete a mid-market evaluation in a few months if the weighting is settled up front; it drags when teams re-litigate priorities late.

This is the work Flectic does with SMEs across Canada, the UK, and the US as a platform-neutral implementation partner for both Microsoft Dynamics 365 and Odoo. Because we implement both platforms rather than selling one, the weighting exercise is genuinely neutral: we help you pressure-test which pillar should dominate for your specific size, budget, and growth path, then deliver whichever system fits without vendor bias. If you are ready to frame your own weights before you shortlist, the ERP Readiness Call is the right starting point.

1. 01
   Place yourself on the size band

   Decide whether you are lean growth (10-50), established mid-market (50-150), or a multi-entity scaler (150-250). Adopt the corresponding starting weights and adjust for your context.

2. 02
   Build a 5-year TCO model with hidden lines

   Include internal staff time, training at 8-12% of implementation, escalation caps, customisation maintenance, and the productivity dip. Model cash flow, not a lump sum.

3. 03
   Assess in-house skills honestly

   Quantify the internal capacity the rollout needs, how much ongoing operation your team can absorb, and where permanent partner dependency will sit as a TCO line.

4. 04
   Map your 3-5 year growth and test scalability

   List the entities, geographies, and functions you will realistically add. Test each shortlisted platform on volume, business-unit addition, integration, and licensing model.

5. 05
   Insist on phased go-live and configuration-first design

   Land core finance and the critical operational loop first. Adapt processes to standard flows before custom code. Expand modules after the business is stable on the core.

6. 06
   Weigh the implementation relationship separately

   Decide vendor-led versus partner-led delivery on responsiveness, industry depth, and post-go-live support. Treat partner quality as a decisive mid-market criterion.

7. 07
   Run the full process with calibrated weights

   Execute team, requirements, scripted demos, weighted scoring, references, and negotiation using the sub-profile weights, not a generic checklist.

Frequently asked questions