On this page
The scorecard in one paragraph
In this RFP template, give each criterion a weight that sums to 100, score each provider from 0 to 5 against written anchors, and compute the total as the sum of weight times score divided by 5. The nine criteria are the response-time SLA by severity (20), version and distribution coverage (15), escalation path and named engineers (15), hours and geography of cover (10), end-of-life handling (10), pricing transparency (10), scope of work (10), security and compliance evidence (5) and references (5). Change the weights to fit your risk, but fix them before proposals arrive, and ask every vendor for the same evidence. As an example of the answers to look for, AceMQ commits to a 15-minute emergency response for a P1, 24/7, sets lower severities in the contract, delivers a written root cause after every P1 and publishes a regular support range of $24,000 to $72,000 a year; end-of-life support is quoted separately.
What should an open-source support scorecard weigh?
Weigh the things that decide how an incident goes: how fast a qualified person answers, whether they cover your versions, and who they escalate to. The table below is the scorecard to copy. Scores run from 0 to 5; the last two columns anchor a 5 and a 1 so two reviewers score the same answer the same way.
| Criterion | Weight | Ask the provider | A score of 5 | A score of 1 |
|---|---|---|---|---|
| Response-time SLA by severity | 20 | What is the first-response time for each severity, and how is it measured? | Written times for every severity, measured from ticket or call, 15 minutes for a production-down case, with credits or remedies for a miss | A single 'business day' target, or no times in the contract |
| Version and distribution coverage | 15 | Which versions and distributions do you support, and which releases are you running today? | Names every version you run, including the commercial and managed distributions, in the contract | Supports only the latest release or only one distribution |
| Escalation path and named engineers | 15 | Who answers first, who do you escalate to, and how fast? | A named senior engineer answers, with a written escalation ladder and an engineer on a live bridge | A queue handled by first-line staff, with no stated escalation |
| Hours and geography of cover | 10 | When do engineers work, and from where? | 24/7 across several regions, including a night shift that is staffed rather than on call | Business hours in one time zone |
| End-of-life handling | 10 | What do you do for versions the community no longer patches? | A stated, quoted process for security fixes and support past end of life, with a record of each fix | No answer, or an instruction to upgrade |
| Pricing transparency | 10 | What does it cost, what moves the price and what is excluded? | A published range or formula, the drivers listed, and nothing extra for incidents | Quote only, with per-incident or per-hour charges hidden in the terms |
| Scope of work | 10 | What is covered: break-fix, configuration, performance, upgrades, root cause analysis? | Break-fix, tuning, upgrades and deliverables such as a written root cause on every severe incident are all in scope | Break-fix only, with advice treated as extra |
| Security and compliance evidence | 5 | How do you access our estate, and what records do you give us? | Scoped, logged access, a change record for each action and patch records you can hand to an auditor | Shared accounts and no records |
| References and track record | 5 | How many customers, how many severe incidents a year, and may we speak to two? | Customer and incident counts you can check, and references in your industry | No numbers and no references |
What is the RFP process and timeline?
Run the RFP process in four steps over about four weeks: write the requirements and fix the evaluation criteria, send the RFP to a short list of potential vendors, score the submissions and call the references. To write a request for proposal that gets comparable answers, state the project requirements, the scope of work and the evaluation criteria, and ask for each RFP response in the same format. A shortlist of three to five potential vendors is enough to compare without burying your team. Ask each provider to open its submission with an executive summary and a company overview, so the scorer can see what is being offered before reading the detail.
| When | Step | What you produce |
|---|---|---|
| Week 1 | Write the requirements | The list of technologies and versions, the severity table, the scorecard weights and the scope of work |
| Week 1 | Issue the RFP | The questions below, the submission deadline and the timeline, sent to the shortlist of providers |
| Week 2 | Answer provider questions | One written answer, shared with every vendor, so no one has an advantage |
| Week 3 | Score the submissions | A scorecard per provider, a ranked list and a deliverable check: the sample patch record and root cause report |
| Week 4 | Check references and decide | Two reference calls per finalist, a price comparison for the same scope and the decision |
How do you turn the scores into one number?
Multiply each score by its weight, divide by 5 and add the nine results, which gives a total out of 100. A provider scoring 5 on every criterion gets 100; one scoring 3 on every criterion gets 60. Check the arithmetic on one row: a 4 on the response-time SLA is 20 times 4 divided by 5, which is 16 of the 20 points. In a spreadsheet the total is =SUMPRODUCT(weights, scores)/5.
Treat the total as a way to rank providers and not as a decision. Any provider that scores 1 on SLA, version coverage or escalation should be out whatever the total says, because those three decide whether the provider can help on the day.
What questions should the RFP template ask?
Ask every vendor the same thirteen questions, in writing, and require evidence for each answer. Copy the block below into your RFP template:
1. List the technologies and exact versions we run: [insert]. Confirm each is covered, in writing.
2. State the first-response time for each severity, how it is measured, and the remedy if missed.
3. State the hours of cover and where the engineers who answer a night-time P1 are based.
4. Who answers first: a named senior engineer or first-line staff? Describe the escalation ladder.
5. What is in scope: break-fix, configuration, performance, upgrades, root cause analysis?
6. What do you do for versions the community no longer patches? How is it priced?
7. What is the annual price, what moves it, and what is excluded? Are incidents ever charged separately?
8. How do you access our environment? Describe accounts, approvals and the records you keep.
9. Provide a sample patch record and a sample root cause report with customer data removed.
10. How many customers do you support, and how many severe incidents do you handle a year?
11. Provide two references in our industry.
12. What is not covered, and who do you hand it to?
13. Give a short company overview: years in business, size of support team, regions covered.Send the questions with your versions filled in, a submission deadline, a timeline for questions and decision, and the scorecard weights. Publishing the weights helps vendors answer what matters in an RFP like this, and fix the evaluation criteria before proposals arrive.
How do you write a request for proposal with clear evaluation criteria and submission instructions?
Write the request for proposal in six parts: the background, the technical requirements, the scope of work, the evaluation criteria, the submission instructions and the budget. Keep each part short and well-defined, because a structured document gets answers you can compare and lets you evaluate the proposals side by side.
- Background and business goals. Say what runs on the platform, what an outage costs you and why you are changing or adding support. Agree the goals with your internal stakeholders first, including whoever signs off the budget.
- Technical requirements. List the technologies, exact versions, where they run (cloud, on premises or Kubernetes), the number of clusters and the severity table below.
- Scope of work. State what is in and out: break-fix, tuning, upgrades and the written deliverables you expect after a severe incident.
- Evaluation criteria. Publish the weights, so every bid is written against what you will score.
- Submission instructions. Give clear instructions on format, the contact for questions, the submission deadline and the date you will decide. Ask each provider to open with an executive summary of the proposed solution.
- Budget. Either state the budget available or ask every provider to price the same scope, so the bids compare like for like.
If you run several technologies, send one RFP rather than separate RFPs for Kafka, Redis and RabbitMQ, so providers can price the combined scope. This free template covers the support requirements and the scoring. It does not replace your procurement team's contract terms, which stay with them.
Is this the same as a software development RFP?
No. A software development RFP buys a project, with a fixed scope, delivery milestones and an acceptance test, and it is scored on delivery. An open-source support RFP buys a service level: response times, version coverage and who answers a production incident at 3 a.m. A software RFP has no place for severity, escalation or end-of-life handling, so do not reuse one for support. If you are also buying custom development, send that as a separate software development RFP.
What does an SLA-backed response time actually promise?
An SLA-backed response time promises that a qualified engineer starts work on your case within a stated time, not that the problem is fixed in that time. Ask four things: whether the clock starts at ticket creation or at the phone call, whether the first response is a person who can act or an automated acknowledgement, what each severity is called and who decides it, and what happens if the target is missed. A table like the one below, filled in by each provider, makes proposals comparable.
| Severity | Your definition | First response | Hours of cover | Update cadence |
|---|---|---|---|---|
| P1: production down | Production unavailable or data at risk | Provider fills in (AceMQ: 15 minutes) | Provider fills in (AceMQ: 24/7) | Provider fills in |
| P2: severe degradation | Production slow or partly failing, no workaround | Provider fills in | Provider fills in | Provider fills in |
| P3: limited impact | Defect or question with a workaround | Provider fills in | Provider fills in | Provider fills in |
| P4: request | Advice, configuration review or planning | Provider fills in | Provider fills in | Provider fills in |
How should the RFP treat versions and end of life?
Name every version you run and make the provider confirm each one in writing, because most estates run something past community support. Ask for the process, the price basis and a sample record for security fixes on those versions. End-of-life support is a different product from regular support at most providers, and the price differs. AceMQ's regular support range of $24,000 to $72,000 a year does not apply to end-of-life or extended support, which is tailored and quoted separately. Expect a similar split from other providers and ask for both figures.
How do you compare pricing models that are not like for like?
Compare the annual total for the same scope, the same SLA and the same set of technologies, and ask what is excluded. Published prices come in three shapes: a floor or share of spend, a price per machine, or a quote. The support price index lists the ones providers publish. A multi-technology discount is a legitimate line to ask for: AceMQ gives aggressive discounts for covering several technologies, such as RabbitMQ, Kafka and Redis, under one contract. Reject any proposal that charges per incident, because it discourages you from calling at 3 a.m.
What are the red flags in a support proposal?
The clearest red flags are a response target with no definition, a version list that says "all versions", and a price that arrives only after a call. Watch for these six:
- "Response" that means an automated acknowledgement.
- Support limited to the latest release, when you run an older one.
- Escalation that ends at a vendor you do not have a contract with.
- Charges per incident or per hour inside a flat-fee contract.
- No sample root cause report or patch record.
- No stated exclusions. Every provider has them.
Where the problem is a defect in a vendor's closed-source product, only the provider can patch it. A support provider should say so and write the vendor case for you.
How would AceMQ answer, and when is it the wrong provider?
AceMQ answers the template with a named senior engineer, a 15-minute response for a P1 around the clock across the Americas, EMEA and APAC, lower-severity times set in the contract, and a written root cause after every P1. AceMQ supports 160+ customers, has been in business for more than 10 years and handles 40+ Severity 1 incidents a year. Regular support contracts run $24,000 to $72,000 a year by SLA, scope and deployment, and quote requests are answered within 1 hour.
AceMQ is the wrong provider if you need a vendor-certified product fix, if you want a managed service in one cloud provider's own console, or if your estate is a single small cluster that your own team already covers well.
Frequently asked questions
What is an RFP template?
A reusable request for proposal: the questions you send every vendor, the evidence you require and the scorecard you use to rank the answers. This one is built for open-source support providers and covers SLA, version coverage, escalation, end-of-life handling and pricing.
What is the difference between an RFI, an RFP and an RFQ?
An RFI asks providers for information so you can build a shortlist, an RFP asks for a full proposal against your requirements, and an RFQ asks for a price for a defined scope. For support, an RFP is the usual choice because the SLA and scope matter as much as the price.
How do I evaluate proposals after issuing the RFP?
Score each proposal on the same weighted criteria with the written anchors, drop any provider that scores 1 on response-time SLA, version coverage or escalation, then compare annual prices for the same scope. Check the sample patch record and root cause report, and call the references.
What should an open-source support RFP include?
The technologies and exact versions you run, a severity table with first-response times, hours of cover, the escalation path, scope of work, the process and price basis for end-of-life versions, pricing and exclusions, how the provider accesses your environment, sample records, and references. Send the same questions and the scorecard weights to every vendor.
How do I choose the right open-source support provider?
Score each on the same weighted criteria with written anchors, then drop any provider that scores 1 on response-time SLA, version coverage or escalation. Compare annual prices for the same scope, SLA and technologies, and ask each provider what is excluded.
What does an SLA-backed response time mean?
A qualified engineer starts work on your case within a stated time for a stated severity. It is a response time, not a resolution time. Ask where the clock starts, whether the first response is a person who can act, who sets the severity and what happens if the target is missed.
How much does open-source support cost?
It depends on the technology, SLA, scope and deployment. AceMQ's regular support contracts run $24,000 to $72,000 a year, with aggressive discounts for covering several technologies. End-of-life or extended support is quoted separately.
How do I handle versions the community no longer supports?
List every version you run and ask each provider to confirm it in writing, with the process, the price basis and a sample patch record for security fixes on those versions. End-of-life support is usually priced separately from regular support.
Should I score price?
Score price transparency, not the price itself, in the main scorecard, then compare the annual totals for the same scope after the shortlist is set. A low price on a narrower scope or a slower SLA is not cheaper.