An ERP RFP scoring matrix is a table that turns vendor responses into comparable numbers. You first apply pass or fail gates to every mandatory requirement, then score the survivors on weighted criteria using a fixed 0 to 5 scale, with each evaluator scoring alone before the group meets. The weighted total is an input to the decision, not the decision itself.
Most ERP selections do not fail because nobody scored the vendors. They fail because the scores were given without a shared scale, weights were chosen after the favourite emerged, and one loud evaluator set the result. This guide covers the scoring side only. The RFP document itself (sections, requirement wording, a copy-and-adapt template) is in our ERP RFP template, and the longer list of selection criteria is in the ERP selection criteria checklist. Read those for what to ask; read this for how to mark the answers.
What is the difference between an RFP matrix and a vendor scorecard?
The two terms are used loosely, but they do different jobs.
- The RFP scoring matrix scores written responses to the RFP. It is used once, early, to cut a long list to a shortlist of two to four vendors.
- The vendor evaluation scorecard scores what you see and hear later: scripted demonstrations, reference calls, a proof of concept or pilot, and the commercial proposal. It is used to choose between the shortlisted vendors.
Using one sheet for both stages causes a common error. Written answers are cheap to polish, so a matrix filled in from RFP text alone rewards the vendor with the best proposal writer. The scorecard should be rebuilt around evidence you gathered yourself. A practical split is to carry the matrix result forward as roughly a third of the final score and let the scripted demo, references and pilot decide the rest.
Step 1: apply pass or fail gates before any scoring
Gates are the requirements where a "no" ends the conversation. Score nothing until they are checked, because weighting a missing mandatory capability just hides it inside an average.
Typical gates for an ERP selection:
- The vendor can run the business in the country or countries you operate in, including the tax and invoicing rules you must follow. Ask for the specifics in writing; do not accept a general "yes".
- The system can hold your required entity structure (companies, branches, warehouses, currencies).
- Required integrations are feasible through a documented method (API, file exchange, connector), not "possible with customisation" and nothing more.
- Data hosting and access terms meet your policy, including who can reach your data and where it sits.
- The vendor will accept your minimum contract terms for data export and exit.
A gate is recorded as Pass, Fail or Pass with condition. A conditional pass needs the condition written down, an owner and a date by which it must be confirmed. Anything still conditional at the end becomes a risk item in the contract discussion.
Step 2: choose criteria, weights and a scale
Weights say what matters to you. They must be agreed and recorded before the responses are opened. The weights below are illustrative, a starting point for a mid-sized business, not a standard. Adjust them to your situation, and make sure they add to 100.
| Criterion group | What it covers | Illustrative weight |
|---|
| Functional fit | How well the product meets the Should and Could requirements without custom code | 30 |
| Total cost of ownership | Licences or build, implementation, hosting, support, internal effort over a fixed period (for example five years) | 20 |
| Delivery approach and team | Plan, methodology, named people, data migration approach, training | 15 |
| Integration | Quality of APIs, connectors, effort for your listed integrations | 10 |
| Non-functional | Performance, security design, availability, audit trail, usability | 10 |
| Vendor strength and references | Relevant references, financial stability, product roadmap | 10 |
| Contract, ownership and exit | Data ownership, source code or escrow position, termination and export terms | 5 |
Use one scale for everything and describe each number in words. A scale that evaluators interpret differently is the main cause of noisy scores.
| Score | Meaning |
|---|
| 0 | No answer, or the requirement is not met |
| 1 | Met only by a workaround or significant custom work, with weak evidence |
| 2 | Partly met; important gaps remain |
| 3 | Met in a standard way, with evidence from the response |
| 4 | Met well, with evidence shown in a demo or a reference |
| 5 | Met exceptionally and proven in your own scenario |
Two rules keep this honest. A score of 4 or 5 needs evidence that is not the vendor's own claim: a demo against your script, a reference, or a pilot. And "will be in the next release" scores 0 or 1 unless the vendor accepts a contractual commitment with a date.
A scorecard you can copy (Excel or Google Sheets layout)
Create a spreadsheet in Excel or Google Sheets with one row per criterion and one block of columns per vendor. Each evaluator fills in their own copy; a facilitator merges them.
| Criterion | Weight | Vendor A score (0-5) | Vendor A weighted | Vendor B score (0-5) | Vendor B weighted | Evidence or note |
|---|
| Functional fit | 30 | | | | | Which requirement IDs are not met |
| Total cost of ownership | 20 | | | | | Cost model and period used |
| Delivery approach and team | 15 | | | | | Named roles, plan quality |
| Integration | 10 | | | | | Listed integrations: method and effort |
| Non-functional | 10 | | | | | Security, performance evidence |
| Vendor strength and references | 10 | | | | | Reference calls held |
| Contract, ownership and exit | 5 | | | | | Export and exit terms |
| Total | 100 | | | | | |
The formula in each weighted cell is weight multiplied by score, divided by 5. With a 0 to 5 scale and weights adding to 100, the grand total is then a number out of 100, which is easier to discuss than a sum of products.
If you build the matrix in an Excel or Google Sheets file, put the weights in column B, one evaluator's scores in column C and the weighted result in column D, with criteria in rows 2 to 8.
| Cell | What to enter |
|---|
| B2:B8 | The weight for each criterion |
| B9 | =SUM(B2:B8), which must show 100 before anyone scores |
| C2:C8 | The evaluator's 0 to 5 score for one vendor |
| D2 | =B2*C2/5, copied down to D8 |
| D9 | =SUM(D2:D8), the weighted total out of 100 |
Evaluator fill-in sheet
Give each evaluator a copy of this sheet and ask for one row per criterion and vendor. The facilitator merges the sheets only after everyone has submitted.
| Evaluator | Role | Vendor | Criterion | Score (0-5) | Evidence (demo, reference or document) |
|---|
| | | | | |
A worked example (illustrative numbers only)
The figures below are invented to show the arithmetic. They are not benchmarks of any real product, and they say nothing about what any vendor scores in practice.
Three vendors are scored on the weights above.
| Criterion | Weight | Vendor A | Vendor B | Vendor C |
|---|
| Functional fit | 30 | 4 | 5 | 3 |
| Total cost of ownership | 20 | 3 | 2 | 5 |
| Delivery approach and team | 15 | 4 | 3 | 4 |
| Integration | 10 | 3 | 4 | 3 |
| Non-functional | 10 | 4 | 3 | 3 |
| Vendor strength and references | 10 | 5 | 3 | 4 |
| Contract, ownership and exit | 5 | 2 | 4 | 5 |
Weighted totals (weight times score, summed, divided by 5):
- Vendor A: 120 + 60 + 60 + 30 + 40 + 50 + 10 = 370, divided by 5 = 74.0
- Vendor B: 150 + 40 + 45 + 40 + 30 + 30 + 20 = 355, divided by 5 = 71.0
- Vendor C: 90 + 100 + 60 + 30 + 30 + 40 + 25 = 375, divided by 5 = 75.0
Three vendors within four points of each other is a normal outcome, and it tells you something: the matrix cannot pick a winner here, so the decision falls to the things the matrix handles badly, such as risk, fit with your team and what the pilot shows.
Now test the weights. Suppose the finance director argues functional fit should count for 40 and cost for 10, other weights unchanged:
- Vendor A: 160 + 30 + 60 + 30 + 40 + 50 + 10 = 380, divided by 5 = 76.0
- Vendor B: 200 + 20 + 45 + 40 + 30 + 30 + 20 = 385, divided by 5 = 77.0
- Vendor C: 120 + 50 + 60 + 30 + 30 + 40 + 25 = 355, divided by 5 = 71.0
The ranking changed from C, A, B to B, A, C by moving ten points of weight. This sensitivity check is worth running on every real selection. If the winner changes under reasonable alternative weights, you have not found a clear winner, and you should say so to the steering group rather than presenting a single number as fact.
How to run the scoring so the numbers mean something
- Fix weights before opening responses. Write them into the RFP so vendors can see what matters. Changing them afterwards is the commonest way a favourite wins.
- Use three to five evaluators with different roles (finance, operations, IT, and one end user). Each scores alone first, without discussion.
- Look at the spread, not only the average. If two evaluators differ by two or more points on a line, discuss that line and the evidence. Do not average away a real disagreement.
- Score from the response, not from the sales relationship. Evaluators who have met a vendor socially tend to score them higher. A facilitator who removes vendor names from the first pass helps, where that is practical.
- Keep cost separate for a first look. Score everything except cost, then add cost. This stops an unusually low price from lifting a weak solution.
- Normalise price scores by formula. A common method gives the lowest compliant total cost the full score and others a score proportional to the lowest divided by theirs. Whatever you choose, apply it to the same cost model, covering the same period and the same scope.
- Record evidence next to every 4 or 5. If you cannot point to a demo step or a reference, it is a 3.
Turning the RFP matrix into a demo scorecard
For the shortlist, replace generic criteria with scripts. Give each vendor the same two or three business scenarios, written from your real processes: for example, receive goods against a purchase order with a price variance, post the supplier invoice, and show the effect on stock value and the ledger. Score each step Pass, Partial or Fail, then convert to the 0 to 5 scale using the table above.
Add a reference score from at least two calls per vendor. Ask references what went wrong, how long go-live took against the plan, and what they would change. A reference who names no problems is a data point too. A committee can pair these scores with a production-readiness checklist and scalability tests, as set out in our ERP selection committee toolkit.
Risks the scorecard does not capture
A weighted total hides three things you should list separately:
- Implementation risk. A strong product with an inexperienced implementer is a weak choice. Rate the delivery team separately from the software.
- Dependency on one person. If the answer to many questions was "ask our consultant", note it.
- Customisation load. Count the requirements met only by custom work. Each is a future upgrade and support cost. Our guide to ERP customization versus configuration explains why this count matters.
Should the scorecard include a custom build as an option?
Often it should. When your processes are the thing that sets you apart, or the packaged options each need heavy customisation, a custom build deserves a line in the comparison, scored on the same criteria with the same evidence standard. The comparison is easier when the custom option shows working software, which is the reason a pilot is useful. For the wider trade-offs, see our ERP versus custom development comparison and the page on custom ERP development. Timeline Digital does not publish prices for custom software, because every project is custom.
How Timeline Digital approaches being scored
Timeline Digital is a custom software development company founded in 2013 and headquartered in Islamabad, Pakistan. When we are one of the vendors in a selection, we ask for the requirement list and scoring weights before we respond, so we answer the questions that carry the most weight. Before you commit to the full project, we build 2 to 3 of your key modules as working software, free of charge, ready in about 2 days. Your team tests the pilot, and the full build starts only after you approve it. That gives your evaluators evidence for the 4 and 5 scores that a written response cannot. The full project starts after you approve the pilot, and the scope, milestones and terms are agreed after it. If a packaged product scores better on your matrix, take it: a good selection process sometimes ends with someone else.
Quick checklist before you send the scorecard out
- Gates are written and each has a clear Pass or Fail definition.
- Weights add to 100 and are agreed by the steering group before responses arrive.
- The 0 to 5 scale is defined in words and shared with all evaluators.
- Each evaluator scores alone first.
- A sensitivity check on weights is planned.
- Cost is modelled over the same period, scope and user count for every vendor.
- Reference calls and a scripted demo are in the plan.
- The decision record states who decides, and what happens if the top two are within a few points.