1. Turn the brief into delivery boundaries
Create one row per deliverable, not one row per broad discipline. ‘New website’ is too wide to estimate. Discovery workshops, information architecture, reusable page templates, content entry, a course-data integration and a hosting handover are different pieces of work. Record the source document, section, version and the evidence behind each requirement.
Mark each item as required, optional or unresolved using the buyer’s wording. Keep your interpretation separate. An unanswered question is not permission to remove the work from your price. Where the pack is inconsistent, use the official clarification route before its stated deadline and preserve the response alongside the original requirement.
2. Count content and migration work separately
Ask for the content inventory: URLs, documents, media, languages and the material to retain, merge or retire. Ten design templates do not mean ten pages to migrate. Include redirect mapping, metadata transfer, document handling, image preparation and checking the imported content where those tasks sit in your scope.
State who supplies approved copy and who enters it. A buyer-owned writing task still creates a project dependency. Set a decision date, acceptance criteria and the consequence of late content in your working plan; do not assume the agency can invent missing copy or obtain permissions on the buyer’s behalf.
3. Test integrations before calling them covered
For each integration, list the system owner, data direction, authentication method, available documentation, test environment and licence responsibility. A logo on a CMS integration page is not evidence that the buyer’s particular system, version and workflow will work.
Separate configuration from bespoke development. Include failure handling and the user’s route when an external service is unavailable. If a partner is essential, confirm its delivery responsibilities, availability and estimate. Record the remaining discovery risk instead of presenting a broad ‘we do integrations’ claim as a completed technical check.
4. Price accessibility and acceptance as work
Read the accessibility, browser, performance and security requirements in the actual pack. Identify the required test method, the evidence to provide and the acceptance decision-maker. Do not promise a certification or a level of conformance that your team has not assessed or cannot substantiate.
Allocate effort for testing with representative content, documenting results, fixing defects and retesting. Include forms, search, navigation, error states and embedded services, not only the homepage. Clarify who owns changes to third-party widgets or legacy documents if those affect the required outcome. This is a scoping method, not a statement of the legal requirements applying to a particular buyer.
5. Follow the website into live service
Check who provides hosting, domain and DNS changes, backups, monitoring, updates, incident response and ongoing changes. Distinguish a defect warranty from a support retainer and from new feature development. Read the hours, response targets, exclusions and contract term rather than assuming ‘support included’ has a shared meaning.
Cost the transition as well as the build: training, administrator accounts, deployment documentation, source-code handover, licences, data export and the exit process. Separate one-off charges from recurring costs and identify any third-party price assumptions. A launch-day estimate alone cannot establish that a multi-year commitment is sustainable.
6. Finish with a decision, not just a total
Consider a hypothetical college website: the agency can design and build the CMS, but the required course-data interface is undocumented and the buyer has not supplied a content inventory. The correct next step is to clarify those two boundaries, not to treat the whole project as either a perfect fit or an automatic rejection.
Use proceed, clarify or pass, with an owner and a date. Record which unanswered points could change the team, schedule or price. The worksheet below helps make that decision reproducible; it is not a buyer’s form and does not replace the tender instructions.
Put the method to work
The free CSV is a blank planning template, not a procurement form. It has no macros, needs no account and does not send your working information to NoticeSift.
Download the website tender scope worksheet (.csv)Continue with the related bid preparation guide or the full guide collection.
Prepared with AI assistance. These are NoticeSift’s suggested working methods, not legal advice or a guarantee of eligibility or contract award. Hypothetical examples are not live opportunities. Follow the current buyer instructions. Read our method or suggest a correction.