An agency quotes a fortnight for a client assistant. The build itself takes three days.
Seven weeks later it is still not live. The client has not supplied the pricing answers, two topics were added that were never quoted, somebody wants it to book appointments through a system nobody mentioned, and the person who approved it has gone on leave.
The agency is losing money on a project it priced correctly, because it scoped the wrong thing. The work was never the build.
Step 1: scope the content, not the software
Configuration is a small part of the effort. Gathering, writing and approving the answers is the project, and it is the part that is never estimated properly.
Step 2: list the topics in scope explicitly
Named, itemised and finite. Anything not on the list is a change request. Without this list there is no way to tell scope creep from a reasonable expectation.
Step 3: name who at the client supplies each answer
By topic and by person, with a date. Content chasing is the single largest cause of overrun and it is entirely predictable, which is the ground in agency retainer clients asking the same update questions.
Step 4: set a content deadline with a consequence
A stated date after which the timeline moves. Without one, the project has no clock and drifts indefinitely while the agency carries the cost.
Step 5: start from what already exists
Website pages, existing documents and past enquiries. Most clients believe they have nothing written and are wrong, which shortens the gathering stage considerably.
Step 6: define the escalation rules with the client
What must always go to a person, what hours apply and what happens out of hours. This is a business decision and agencies frequently make it by default instead.
Step 7: scope the integrations separately
Booking systems, inventory, ticketing and anything requiring access. Each needs its own estimate and access that only the client can arrange, which is the same product data problem as how to train a store assistant on your product catalogue.
Step 8: agree the success criteria in writing
Two or three measurable outcomes. Without them, completion becomes a matter of opinion and the project ends when somebody gets tired rather than when it is done.
Step 9: scope the testing stage
Against real past enquiries rather than invented ones, with a named person at the client reviewing. Testing is always in the plan and rarely in the estimate.
Step 10: include accessibility in the scope
It is a requirement rather than an enhancement, which is the ground in accessible website assistant.
Step 11: scope the launch and the training
Who announces it, what the client team needs to know, and who handles the first week. A launch nobody prepared for produces a bad first impression internally.
Step 12: scope the tuning period explicitly
Thirty days of review and adjustment, included and bounded. Without a boundary this becomes indefinite free work.
Step 13: separate the ongoing work into a retainer
Content changes, new topics and seasonal updates are a service rather than part of a build, which is the model described in agencies selling chatbots as a service to local clients.
Step 14: put the change request process in the proposal
Named, priced and unembarrassing to invoke. An agency that has agreed the process in advance can say yes to extra work instead of absorbing it. See features, start at try, and the sector view sits under agencies.
Step 15: gather the answers automatically where you can
An assistant configured early can collect the client's real enquiries while the content is still being written, which both shortens the gathering stage and proves the topic list was right.