A studio quotes for a website. Three months later the project is not finished, the client has asked for a homepage layout to be reconsidered for the fourth time, half the content has not arrived, and someone has mentioned a booking system that was never in the quote.
Nobody behaved badly. The scope was simply never written down properly.
The teardown: where the divergence starts
The client imagines a finished website. The studio imagines a defined number of page templates, a fixed set of features and a stated number of revision rounds. Both use the word website and mean different things.
Failure one: revisions are undefined
How many rounds, at what stages, what counts as a revision and what counts as a change of direction. Without this, feedback is unlimited and the project has no end.
Failure two: content responsibility is assumed
Clients frequently assume copy is included. Studios frequently assume it is not. Stating who writes, who sources images and when it must arrive prevents the most common cause of delay.
Failure three: page count is vague
A five page site and a five page site with twelve variations are different jobs. Counting templates rather than pages is usually the honest way to define it.
Failure four: functionality creeps in
Booking, payments, logins, member areas and integrations each change the project substantially. Listing what is included, and explicitly what is not, protects both sides.
Failure five: the deadline is not owned
Delays caused by content, feedback or approvals are the client's, and delays in build are the studio's. Saying so in advance keeps a slipping timeline from becoming a dispute, which is the territory of how long a website takes and other timeline questions.
Failure six: what happens after launch is unstated
Hosting, updates, fixes, training and how long a bug is covered. Clients assume support continues indefinitely and studios assume the project ended at launch.
Failure seven: nobody asked what they actually need
An enquiry that starts with budget and page count misses the question of what the site is supposed to achieve, which is the same problem as website quote requests without a brief.
What to establish before quoting
What the site is for, roughly how many templates, what functionality is needed, who writes the content, who supplies images, the deadline and what exists already.
Price change rather than refusing it
Clients will always want changes. A published hourly rate for work outside scope turns an awkward conversation into an ordinary one.
Publish an indicative range
A range by project type filters enquiries usefully and stops a week of conversations with someone whose budget was never going to work.
Briefs are the same problem in every design field
It appears identically in garden design enquiries that need a proper brief.
Capture the brief when it is written
Clients write their brief in the evening after thinking about it all day, and the enquiry that waits until Monday competes with three that did not, which is the wider point in is it in stock, the question retail websites fumble.
Getting started
Publish what a project includes, revision rounds, content responsibilities and your out-of-scope rate, then capture briefs at any hour. SpideyChat for web studios answers from your published pages. Try SpideyChat on your own site, or read about capture on the features page.