RFP for a Website: Template, Criteria, and Submission Instructions
18 min read
An RFP for a Website: A Template, Evaluation Criteria, and Submission Instructions
An RFP for a website should include a presentation of your organization, goals with measurable indicators, a clear scope of work, technical requirements, integrations, accessibility requirements, a timeline, a budget framework, and submission instructions. Clear evaluation criteria and compliance with accessibility standards are decisive. Below, you'll find an organized template and a system for comparing proposals.
In short:
If you don't disclose your budget, request itemized pricing by phase, integration, and recurring cost, so you can trim scope without the whole project falling apart.
Define your criteria and weights in advance; have evaluators score proposals independently on a scale of 1 to 5 first, then calculate the average.
Require accessibility from the start of the project, per the SIST EN 301 549 standard, with verification that includes automated scans, screen readers, and keyboard navigation.
In the scope, separate what's included, excluded, and optional; specifically list content migration, licenses, hosting, maintenance, and a separate price for every connection to an external system.
For a public procurement, check the applicable rules; when the process runs through e-JN, submit your proposal before the deadline, since a delay or a missing attachment can lead to disqualification.
Moxy-web — Plan a custom web solutionMoxy-web builds flexible websites, online stores, and applications, tailored to businesses' needs and technical requirements.Check out Moxy-web's services
Table of Contents
e-JN, public procurement procedures, and accessibility requirements
The author's perspective, and how we handle RFP-based projects
How we can help you prepare your RFP and deliver the project
What to gather before you start writing the RFP
A good RFP starts before the first line of the document. If you send providers a vague description, you'll get vague proposals you won't be able to compare. So gather internal information first, then open the template. This helps you avoid a classic mistake: providers interpreting blank spots however they like, leaving you to compare apples to oranges at the end.
Our guide to how to plan a business website can also help with planning, covering a project's initial phase. For a broader look at planning steps, this Portuguese practical guide to website planning is also useful, showing how to structure your thinking before putting it into an RFP.
Before writing, prepare the following:
Goals and success metrics. Write down what you want to achieve — a higher conversion rate, shorter loading time, or more inquiries through a form, for example. Set the numbers yourself based on your current state; don't copy them from someone else's example.
A description of the problem, not the solution. The RFP should define what you need to achieve, not how the provider should do it. The moment you prescribe a solution, you lose the chance for a provider to propose a better one.
Reference examples. Gather websites you like, and write down why: navigation, speed, visual identity, or how products are presented.
A list of existing systems. List the CRM, ERP, accounting software, payment gateway, and email tool the new site needs to connect to.
Constraints. Legal (data protection, accessibility), technical (existing hosting, domain), and timing-related (a season, an event, the end of a budget year).
A point of contact and a question process. Designate one person to answer providers' questions, and set a deadline for questions and answers, so everyone has the same information at the same time.
Pro tip: Before writing the RFP, agree with your internal team on who has the final say in the selection. Proposals evaluated by multiple people with no agreed-upon criteria can end in disputes about what actually matters.
It's also worth deciding in advance how much you're prepared to invest. Providers can only design a realistic solution if they know the budget range, or at least its rough order of magnitude. Hiding the budget doesn't lower prices — it widens the spread of proposals and makes comparison harder. If you don't want to disclose your budget, ask providers for a phased, itemized proposal instead, so you can trim or postpone elements without the whole project falling apart.
Finally, check whether the project falls under public procurement. If you're a public institution or a contracting authority bound by public procurement law, the process, deadlines, and submission format differ from a private inquiry. The section on e-JN and accessibility below covers this in more detail.
Required RFP sections, and what to write in each
Below, each section is explained with instructions on what to include and sample text. This structure is also confirmed by the World Council of Churches' sample RFP, which includes an organization presentation, goals, target audience, a detailed scope, technical recommendations, qualification criteria, and an itemized financial proposal.
The sections follow in this order:
Organization presentation
Goals and success criteria
Target audience and user journeys
Scope of work
Technical requirements
Integrations
Accessibility
Timeline and milestones
Financial section
Submission instructions
Disqualification criteria
Organization presentation
A provider needs to understand who they're working for. Write down your industry, size, markets, key products, and existing web presence. Add contact details, legal information (company name, registration and tax numbers), and the addresses of your existing websites. Sample sentence: "We are a mid-sized manufacturing company with a long track record, exporting to various markets. Our current website serves as a catalog and receives inquiries through a form and by phone." Don't make up precise figures — use only the data you actually have.
Goals and success criteria
This is the most important section. Write down three to five goals, each with a measurable indicator. Instead of "we want a modern website," write "we want a visitor to find a product quickly, and we want form inquiries to increase." Add a baseline and a target value you set yourself, plus how you'll measure it — Google Analytics or form tracking, for example.
Target audience and user journeys
Describe who uses the site: customers, partners, job applicants, journalists. For each group, list two to three key tasks they need to accomplish. Example: "A business customer needs to quickly find a technical data sheet and submit an inquiry." A description like this tells a provider which functionality is critical, and lets them propose a tailored solution.
Scope of work
This is usually where the most expensive misunderstandings hide. Clearly separate what's included from what isn't. Examples of items worth explicitly defining:
number of subpages and proposed content types,
preparing or migrating existing text and images,
translations and number of languages,
CMS or plugin licenses (paid by the provider or by you),
migrating data from the old site,
training your team to manage content,
hosting, domain, and later maintenance.
If you're uncertain about an item, list it as optional and request a separate price. You'll find a more detailed breakdown of typical phases in our article on what building a website includes, which helps you put together your scope list.
Technical requirements
Define minimum standards, not specific technology, unless you have a well-founded reason to do so. Require:
a content management system you can edit yourself without a developer,
HTTPS on every subpage, plus regular security updates,
automatic backups and a recovery process,
responsive design for phones, tablets, and desktops,
a target loading time, measured with a scanning tool, agreed upon as an acceptance criterion,
SEO basics: clean URLs, metadata, structured headings, and redirects from the old site.
Ask providers to state which technology they propose and why. Pay attention to whether they're proposing a custom-built solution or an adapted pre-built platform, since this affects flexibility and later costs.
Integrations
For every external system, list its name, purpose, and connection method. Note whether an API exists, which authentication it uses, and who's the owner on your side. Examples: connecting a form to a CRM, syncing stock with an ERP, a payment gateway for an online store, a connection to an email tool. Ask providers to estimate the effort for each integration separately, since integrations are the most common source of scope overruns.
Accessibility
Require compliance with the SIST EN 301 549 standard, which in practice relies on WCAG guidelines. The Act on the Accessibility of Websites and Mobile Applications requires compliance with this standard, with oversight carried out through simplified and in-depth methods. In your RFP, describe how you'll verify compliance: automated scans, manual testing with screen readers, and keyboard navigation. Also require the provider to treat accessibility as a concern from the start of the project, not only at the end. More on this in the section on public procurement procedures below.
Timeline and milestones
Propose a phased structure: discovery and specification, concept and design, development, content entry, testing, launch. Build time into each phase for your own approvals, since delays typically don't originate with the provider — they come from waiting on the client's feedback. Write out clear milestones with dates you need to approve, and define what happens if a deadline slips.
Financial section
Ask for an itemized proposal. Example structure:
one-time costs by phase (analysis, design, development, content entry, testing),
integration costs, itemized individually,
annual costs for hosting, domain, and licenses,
monthly or annual maintenance and technical support costs,
the price of additional hours beyond scope.
A proposal with a single lump sum doesn't let you understand what you're paying for. An itemized proposal shows you exactly where the differences between providers actually lie.
Submission instructions
Specify the deadline and submission address, file format (typically PDF), maximum page count, and required attachments. Typically require company identification details, references, a description of approach, a timeline, and a financial proposal. Also require proof of standards compliance, such as an accessibility statement or test reports from past projects.
Disqualification criteria
Write down in advance what counts as automatic disqualification: missing required documents, a late submission, a proposal with no itemized pricing, or a lack of required proof. When these rules are published upfront, you avoid accusations of bias and save time during review.
How to compare and evaluate proposals
Without an agreed-upon matrix, evaluation turns into gut feeling, and gut feeling is hard to defend to leadership or an auditor. Write your criteria and their weights into the RFP itself, so providers know what counts, and so you can't change your mind later.
Example weight distribution, to adapt to your project:
quality of the solution and understanding of your needs,
technical compliance, including accessibility,
price,
references.
We often overweight price, even though the cheapest proposal with mismatched scope ends up costing more in the end than a pricier but complete one.
Use a scoring matrix like this:
Have each evaluator score every criterion individually, on a scale of 1 to 5, before the team discusses it. This avoids the influence of the loudest voice in the room.
Multiply each criterion's score by its weight and add them up. Example: if a provider scores 4 out of 5 on quality, and quality is weighted 40%, that contributes 4 ÷ 5 × 40 = 32 points out of 40.
The average of all evaluators' scores is the final result for that criterion.
The overall score is the sum of contributions across all criteria.
Build your evaluation committee out of people from different areas — content, technical, finance, and legal where relevant. If the project is a public procurement, the committee and process are set by legislation.
Handle ambiguities in writing. If a proposal contains an ambiguous item, send the provider a question, and share the answer with every participant, where rules allow it. Verbal agreements get forgotten or misused quickly.
Pro tip: Before evaluating prices, require every provider to present pricing in the same structure. If you do this later, you'll waste time reconciling line items you could have simply compared from the start.
An RFP template to copy and customize
Copy the structure below into your own document and fill in the fields. The sample sentences are a starting point for you, not final text.
Template by section:
Client presentation. Name, industry, point of contact, email, phone. Sample: "[Company name] is a [industry] business with [years] years of experience."
Background and project goal. Why you need the project, and what you need to achieve. Sample: "The goal is for [indicator] to reach [value] by [date]."
Target groups. User groups and their key tasks.
Scope of work. List of included and excluded items, plus optional items.
Technical requirements. CMS, security, speed, responsiveness, SEO basics.
Integrations. System, purpose, connection method, owner.
Accessibility. Required compliance and verification method.
Timeline. Phases, milestones, your approvals.
Budget and proposal format. Itemized pricing structure.
Submission instructions. Deadline, address, format, attachments.
Evaluation criteria. Weights and process.
Terms. Proposal validity, confidentiality, intellectual property.
Adjustments by project scope and type:
A smaller project (a presentational site): shorten the integrations and timeline sections, but keep scope, pricing, and accessibility clear. The length of the RFP should be proportional to the project.
A larger project (a portal, store, or application): add detailed user scenarios, an architecture description, performance requirements under heavier load, and a phased rollout.
An online store: add payment methods, delivery methods, tax treatment, stock synchronization, and return processes.
A corporate website: emphasize content management for multiple editors, multilingual support, and role-based editor permissions.
A checklist before publishing your RFP:
Are your goals written with measurable indicators?
Is the scope of work clearly divided into included and excluded?
Are integrations listed with the system's name and purpose?
Is the accessibility requirement written with a reference to the standard?
Are evaluation criteria and weights specified in the RFP?
Is a deadline set for questions, and a deadline for submission?
Is the proposal format specified, along with a list of required attachments?
Is a point of contact designated?
A complement to this list is our checklist for building a website, covering the implementation phase once a provider is chosen.
e-JN, public procurement procedures, and accessibility requirements
If you're a public contracting authority, or you're submitting a bid for a public tender, you have additional obligations. The Ministry recommends using the e-JN system for public procurement, with the system supporting the process from market analysis through contract award, built on principles of transparency and competition on quality and price. Even for smaller projects not subject to an open tender, transparency in market research is still recommended.
Practical tips for submitting through e-JN:
A bidder needs to register in the system before submitting. The e-JN user instructions describe registration, preparation, and electronic submission of bids, along with technical requirements.
Deadlines are strict. Submit your proposal well before the deadline, since technical issues or delays can mean disqualification.
More detailed instructions for bidders are also available in the e-JN portal manual.
The contracting authority should clearly state the required format and attachments in the tender documentation, so providers aren't disqualified over formalities.
What to require around accessibility in your RFP:
compliance with the SIST EN 301 549 standard,
a published, up-to-date accessibility statement,
a description of testing methods: automated scans and manual checks,
test reports from similar past projects.
The report on the accessibility of websites and mobile applications states that the inspectorate uses the Wave, axe DevTools, and Accessibility Insights tools, along with seven checkpoints for an accessibility statement. That means you can verify compliance with the same tools before launching your site.
To demonstrate compliance, it helps for a provider to treat accessibility as a process: accounting for users with different impairments, running automated and manual tests, and documenting the work from the start of the project. This also prepares you for any inspection requests to address deficiencies.
The most common mistakes, and how to fix them
Most RFP problems repeat themselves. Knowing them in advance makes them easier to avoid.
A scope that's either too technical or too vague. If you prescribe every technical detail, you take away a provider's chance to propose something better. If you just write "a modern website," you get proposals that can't be compared. Fix: describe your goals and constraints, and leave the technology to providers, who should justify their choice.
Unclear evaluation criteria and missing references. Without weights, every evaluator judges differently. Fix: write your criteria and weights into the RFP, and require references with a contact and a description of the work performed.
Administrative mistakes in submission. The wrong file format, a missing attachment, or a late submission are common reasons for disqualification. Fix: write an exact list of attachments and a deadline with a time into the RFP, and advise providers to submit ahead of the deadline.
Copying templates with no customization. A template pulled from the internet that doesn't reflect your project leads to incomparable proposals. Fix: use the structure, but write the content yourself.
Treating accessibility as an afterthought. If you only require it at handover, fixing it is expensive. Fix: require it as a process requirement from the start.
The author's perspective, and how we handle RFP-based projects
Running web projects, the same story repeats itself: the best projects happen when a client clearly states what they want to achieve and leaves the how up to the provider. An RFP isn't a contract — it's the start of a conversation, meant to let a provider show they understand your problem.
We typically start a project with an introductory conversation, where we work together to clarify goals, target audiences, and constraints. We build our own web solutions and don't use pre-built platforms, which lets us tailor our proposal to your needs and integrations.
As proof, we expect the following from providers:
references with a client contact,
accessibility test reports from similar projects,
a description of testing and quality-assurance methodology,
a clearly itemized proposal by phase.
A good RFP doesn't constrain a provider — it tells them what they need to solve. Proposals only become comparable once every provider is answering the same questions.
Where RFPs most often go wrong: the author's view
Conventional advice says an RFP should be as detailed as possible. In my view, that's exactly the trap. A long document packed with requirements creates a sense of control, but in reality it forces providers toward identical solutions and obscures the differences that actually matter. You get the best proposals when you clearly state which problems you're solving and how you'll measure success, leaving the method of delivery open.
We often overvalue price. The cheapest proposal is rarely the cheapest solution, because additional costs show up everywhere the RFP wasn't clearly written. So I'd focus first on three things: measurable goals, a sharp line between included and excluded, and accessibility as a process requirement. Everything else is refinement.
— Ziga
How we can help you prepare your RFP and deliver the project
If you have goals but aren't sure how to put them into an RFP, we can help you with that very first step. Our team builds custom websites, online stores, and web applications, and we also offer hosting, domain registration, graphic design, and technical support and maintenance. That means we can cover a project from concept through ongoing care of the site afterward.
Our solution is custom-built, with no pre-made platforms, meaning more flexibility and fewer technical constraints when integrating with your systems. Read more about our approach on our website development page.
The next step is simple: send us a brief description of your project, and let's talk about delivery. Request a proposal through our homepage, and we'll figure out together where to start.
Frequently asked questions
What does an RFP for a website need to include?
An RFP needs to include a presentation of the client, goals with measurable indicators, scope of work, technical requirements, integrations, accessibility requirements, a timeline, a budget, and submission instructions. Add evaluation criteria and disqualification conditions too, so proposals are comparable.
Do I need to state my budget in the RFP?
It's advisable to state at least a range. This lets providers design a realistic solution, without over- or under-proposing. If you don't want to disclose your budget, request an itemized, phased proposal instead, so you can adjust the scope.
How should I compare proposals from different providers?
Use a scoring matrix with predefined criteria and weights — quality, technical compliance, price, and references, for example. Have each evaluator score independently, then average the results. Require every provider to present pricing in the same structure.
Is website accessibility mandatory?
Entities covered by the Act on the Accessibility of Websites and Mobile Applications are required to comply with the SIST EN 301 549 standard. Check with the relevant authority whether you're covered, but require accessibility as a process requirement in your RFP either way.
Do I need to use e-JN for a public procurement?
The Ministry recommends the e-JN system for public procurement. Check the exact obligations for your procedure against current legislation, or consult a public procurement specialist.