Web Project Intake Form Template
For builds bigger than brochureware — functionality, platforms, success metrics, and budget envelopes, framed for stakeholders who answer to other stakeholders.
This intake frames the engineering conversation: what the project must do, what it must connect to, and how everyone will know it worked.
Some web work is a brochure; some is infrastructure. This intake is for the second kind — builds with user accounts, integrations, and stakeholders who must defend the spend upstairs. Its questions are shaped so a project lead can answer them in one sitting and the answers still hold up in an estimation meeting a week later.
Classification first. The build-type question sorts the enquiry into the lane that determines everything downstream: marketing site, product or portal, commerce, or migration. Each lane has a different definition of done and a different risk profile, and agencies staff them with different teams. The functionality multi-select then inventories the non-negotiables — accounts, CMS, integrations, multilingual — the features that move estimates by multiples rather than percentages. A checkbox here is worth three discovery emails later.
The metric question does the qualifying. "How will you measure whether the project worked?" is rare on intake forms, and it should not be. Teams that answer with a number — demo requests per month, portal adoption by Q3 — are ready to build; teams that answer "a more modern look" need a strategy conversation first. Both are fine, but the answer routes your reply. The current-stack field catches migration landmines early: a decade of CMS plugins or a homegrown admin changes week one completely.
Budget as an envelope, not a number. Buyers at this scale rarely hold a fixed figure; they hold an envelope and a case they still have to make. The bands include "needs a business case first" because that answer is real, common, and useful — it tells you the sale is upstream of the scope. The timeline select trades false precision for the same honesty.
What the form declines to ask. Visual taste, brand adjectives, page-level content — that territory belongs to the web design intake, and mixing the two produces a form nobody finishes. Also absent: RFP theater. Vendor matrices and reference lists arrive by email when procurement requires them; they do not belong between a stakeholder and a submitted enquiry.
In practice. Development shops link this from their services page and route submissions by build type. Digital agencies use the functionality answers to decide which architect joins the first call. Internal IT teams repurpose it as the project-request front door for other departments. Adaptations that pay off: attach a file upload block for existing RFP documents or analytics exports; wire the webhook into your ticketing system so each intake opens a pre-scoped ticket; and add a Logic rule revealing commerce-specific questions — catalog size, fulfillment model — only when the e-commerce lane is chosen. Estimation never becomes easy, but it should never again start from a blank page.
Frequently asked questions
Can submissions open tickets in our tracking system automatically?
Yes — configure the webhook to your intake endpoint. Each submission posts as signed JSON with every answer, and failed deliveries are retried.
Prospects want to attach an RFP document. Possible?
Add a file upload block; PDF and Office documents are accepted and each file can be up to 10MB. Uploaded files sit alongside the response.
Can I show extra questions only for e-commerce projects?
Open the Logic panel and add a show rule keyed to the build-type answer. Conditional questions keep the base form short for everyone else.
How do I share results with our estimation team?
Export responses as CSV for the estimation worksheet, or let the team read the responses view directly — each submission shows answers in full.