Scorecard
8 criteria · gates · live scoring
Score the proposals, not the presentations
Eight weighted criteria with a defined evidence standard for each, six pass/fail gates checked before scoring begins, and a running total that tells you whether the decision you are about to make is defensible.
Gates, before anything is scored
No failures recorded
Legal standing and insurance
Registered entity, professional liability and cyber cover at the level your contract requires, no debarment or conflict of interest.
Three comparable Drupal builds
At least three production Drupal 10 or 11 builds of comparable scale and complexity, with references that can be contacted.
Named architect with Drupal depth
A named Drupal architect or lead with demonstrable depth on the modules and patterns your project depends on, committed to the engagement.
Security assurance available
A current SOC 2 Type II or ISO 27001 report, or an equivalent independent assessment, available for review before award.
Can meet the required hosting model
Able to deliver and support the hosting model the RFP specifies, including ownership, region and exit requirements.
Accessibility capability evidenced
A named individual or partner able to perform manual WCAG 2.2 AA testing, with a prior conformance report as evidence.
Weighted scorecard
Drupal technical approach and architecture
Whether the proposed content model, configuration strategy and deployment approach would actually work at your scale.
Evidence · A content model sketch, configuration management approach (config split or equivalent), deployment pipeline description, and named contributed modules with justification for each.
Team, roles and named expertise
Who does the work, whether they are employees or subcontractors, and how much of the project the named architect is actually on.
Evidence · Named individuals with role, allocation percentage, location and relevant project history. A commitment that the named architect remains on the engagement.
Comparable experience and references
Whether they have delivered the specific thing you are buying, at a similar scale, in a similar constraint environment.
Evidence · Three references for projects of comparable size and complexity, with contactable names, plus a case study that states the original budget and timeline against the final ones.
Hosting, infrastructure and operations
Ownership, recovery evidence, patching discipline and whether you can leave at the end.
Evidence · Answers to every hosting clause with evidence attached: backup restore report, availability figures, patch timeline for the last critical advisory, export formats, and exit terms accepted in writing.
Security, privacy and compliance
Whether the security posture is documented, audited and scoped to the layer you are relying on.
Evidence · SOC 2 Type II or ISO 27001 with the scope paragraph highlighted, pen-test summary, incident notification commitments with timelines, WAF and access-control description.
Accessibility and quality assurance
Whether accessibility is engineered in and verified, or bolted on before launch and forgotten.
Evidence · A named accessibility standard (WCAG 2.2 AA), the automated and manual test method, who performs manual testing, the defect-remediation process, and an example conformance report they have produced before.
Delivery plan, migration and support model
Whether the plan is specific enough to hold them to, and whether the migration and post-launch period are priced
Evidence · A phased plan with dates and dependencies, two migration rehearsals, a cutover sequence with a rollback trigger, a hypercare period, and severity-based support targets.
Three-year total cost of ownership
The real cost of ownership across build, hosting, support and change over three years, in a comparable format.
Evidence · The required cost table completed in full, a rate card by role, stated assumptions and exclusions, and a separate line for hosting that shows whether it is pass-through or marked up.
Weighted total · 0 of 8 criteria scored
Weak — do not award
0.0 / 100
Demonstration
Three tasks, every finalist
Same three tasks, in the vendor's own environment, with real content. Score the demonstration inside "technical approach" — it is the only part of the evaluation a vendor cannot write in advance.
01Edit and publish
Create a new landing page using an existing content type, add a hero, a component and an image, then publish it through your approval workflow. Do this live, in your own environment, not in a slide.
Watch for: How many clicks per decision, whether the editor knows where things are without hunting, and what happens when a required field is missed.
02Deploy and roll back
Make a configuration change in code, deploy it to staging through the pipeline, then roll it back to the previous release. Show the time each step takes.
Watch for: Whether rollback is a real button or a manual procedure described from memory, and whether anyone hesitates.
03Prove a requirement
Pick the requirement the panel finds hardest to believe — usually accessibility, object caching or redirect handling — and ask them to demonstrate it working rather than describe it.
Watch for: Live evidence versus an anecdote about another client. A vendor who cannot demonstrate it on their own site has not done it.
Red flags
Signals worth a question
None of these disqualifies a vendor on its own. Each should produce a written clarification question before award, and the answer should be recorded.
- Price quoted without assumptions, exclusions or a rate card.
- Hosting described as a platform rather than an environment, with no region, backup report or export format.
- Every team member is 'senior' and nobody is named on more than one project.
- Accessibility and security appear only in the compliance appendix, never in the approach.
- Migration is a single line item with no rehearsal, redirect mapping or cutover plan.
- References are large organizations with no contact details.
- The proposal answers a different question than the one the RFP asked, at length.
- Three-year cost is not offered, and the quote is valid for only 30 days.
Questions
Scoring disagreements
How many criteria should a vendor scorecard have?
Seven to nine scored criteria plus a short list of pass/fail gates. Every additional criterion dilutes the weight of the ones that matter and invites scoring drift between evaluators. If a criterion cannot change your decision, it belongs in the gates or in the contract, not in the weighted score.
Should price be 30 percent of the score?
For Drupal work, price usually sits between 20 and 30 percent. Below 20 percent you are not testing affordability; above 35 percent you are buying a commodity and will likely select the vendor least able to deliver. Whatever you choose, publish the weights and the formula so vendors can see how their proposal will be read.
How do we stop evaluators from scoring on gut feel?
Give every score a definition. A five means the proposal names the approach, the people and the evidence; a three means it is plausible but unsupported; a one means it is asserted only. Two evaluators who disagree by more than two points discuss that criterion before scores are averaged, and every score above four needs a citation from the proposal.
Keep the record
Export it before the panel meets
A scorecard that lives only in a browser tab is not an evaluation record. Export the CSV, attach it to the procurement file, and keep the evidence notes alongside it — appeals are won and lost on whether a score can be traced to a passage.