Before you quote, write what counts as done
“Route new leads” sounds clear until two people describe what they expected.
Before you quote, write down the input the automation will receive, the trigger, the result someone can observe, the timing condition, the reviewer and the evidence to collect. Name dependencies and exclusions beside that condition. The client and builder then have something specific to review under their own agreement.
Consider a fictional lead-routing project. “Send leads to the right person” leaves several questions open: which leads qualify, which fields are required, what happens when a field is missing, and what counts as a successful result? A scope can make those boundaries explicit without pretending every future request is already known.
When a later request arrives, classify it before estimating it. A missing detail needs clarification. A new addition beyond an agreed boundary needs its own estimate and decision. A failure to meet an agreed acceptance condition on an in-scope input is an included defect. Check permitted operating changes against the baseline too. Record the reason, rather than calling every request “small.”
For an addition, show labor, one-time direct costs, recurring fees and dependency effects separately. An estimate gives the client information; it does not authorize the change or promise a calendar delivery date. Record the decision and update the baseline before scheduling the work.
The Automation Scope and Change Pack supplies editable scope, acceptance and change records with fictional worked examples. You provide the workflow facts, estimate and client agreement. It is an operational document pack, not contract drafting, discovery or implementation.