Scope creep rarely announces itself. It shows up as a friendly message on day nine, a „quick tweak“ that becomes a second design direction, or a stakeholder who was never on the kickoff call and now has opinions. The way you onboard a new client in the first five business days decides whether those requests quietly eat your margin or get handled as visible, priced decisions. Everything below runs in a blank spreadsheet.<\/p>\n
Before you fix it, name it. Scope failures on service projects almost always fall into four patterns:<\/p>\n
None of these are personality problems. They are documentation problems. A client who asks for extra work is behaving normally; the failure is that you had no mechanism to convert the ask into a decision with a price and a date attached.<\/p>\n
A signed contract is not a started project. The gap between the two is where most control is lost. Treat intake as its own deliverable with its own deadline.<\/p>\n
Open a sheet called Inputs Register<\/strong> with one row per thing you need from the client. Columns: input name, owner (a person, not a company), requested date, due date, status, and which deliverable it blocks. Ten to twenty rows is typical for a mid-sized project. Assets, access credentials, copy, approver names, legal or compliance contacts, and the name of the single person who can say yes.<\/p>\n Then attach a rule and say it out loud in the kickoff call, not buried in a PDF:<\/p>\n If a required input is more than five business days late, the affected delivery date moves by the same number of days. No penalty, no drama \u2014 the calendar just shifts.<\/p>\n<\/blockquote>\n This one sentence removes the most common source of late-project resentment. You are not punishing anyone; you are making a dependency visible before it costs you a weekend.<\/p>\n Next sheet: Deliverables<\/strong>. One row per item you will hand over. For each row, write a one-sentence definition of done, the file format, the named approver, the number of revision rounds included, and the approval deadline.<\/p>\n The definition of done is the part people skip. „Homepage design“ is not a deliverable. „Desktop and mobile homepage design in Figma, final copy in place, one hero variant“ is a deliverable, because you can point at it and prove it exists.<\/p>\n Set a revision budget explicitly. Two rounds per deliverable is a common default for design and copy work. Define what a round is, because that definition is what actually protects you:<\/p>\n Finally, define what silence means. Pick one and write it into the kickoff email: either work pauses until approval arrives, or the deliverable auto-approves after five business days following written notice. Both are defensible. Ambiguity is not.<\/p>\n You need a threshold that decides, in seconds, whether a request is absorbed or billed. Here is a decision rule you can adopt as-is and tune later:<\/p>\n Then build a Change Log<\/strong> sheet: date, requester, description, category (absorbed \/ billable \/ declined), estimated hours, fee, schedule impact in days, status, and who approved it. The log matters more than the fee. It is the artifact you open in the end-of-project call when someone asks why delivery slipped.<\/p>\n Fixed fee $9,000. Two revision rounds per deliverable. Change rate $150 per hour, stated in the contract.<\/p>\n Day 12.<\/strong> The client asks for a second homepage direction after approving the wireframe. That is a new direction, not a revision. You estimate six hours: $900, plus three days on the timeline. You send a four-line change order. They approve it. Either outcome is a good outcome \u2014 you get paid or you get your schedule back.<\/p>\n Day 20.<\/strong> They want a button color changed. Ten minutes. You absorb it and log it as absorbed.<\/p>\n Day 28.<\/strong> A marketing lead who was never in kickoff asks for Spanish versions of five pages. Fourteen hours: $2,100 and a new delivery date. You route it to the named approver from your Deliverables sheet, not to the person who asked. The approver declines it and defers to phase two.<\/p>\n At handoff, your change log shows $3,000 of requested work, $900 approved and billed, $2,100 declined by the client, and seven absorbed items totaling roughly two hours. The project delivered three days late for a documented, client-approved reason. Nobody is surprised, and you have a clean record for the renewal conversation \u2014 which is exactly the kind of operational detail worth revisiting in the other workflow walkthroughs on the blog<\/a>.<\/p>\n Run this every time you onboard a new client, regardless of project size. It takes about ninety minutes of setup.<\/p>\n That last item is underrated. When a dispute happens in week five, the day-one summary written in plain language usually settles it faster than the contract does.<\/p>\n Be honest about the ceiling. A spreadsheet is excellent for defining rules and terrible at enforcing them. It has no signature trail, so a change order approved by email lives outside the file. It handles one editor well and several editors badly. It does not notify anyone when an input goes overdue.<\/p>\n Move to dedicated tooling when you hit any of these: more than about five concurrent projects, two or more people editing the same tracker daily, retainers with rolling unused hours, or a client who requires a shared portal. At that point you want proposal software with e-signature for change orders, a project tool with task-level owners and due-date alerts, and time tracking that feeds your change log automatically.<\/p>\n Even then, keep the sheet for the first two weeks of every engagement. The rules are the asset; the software is just where you store them later.<\/p>\n If you would rather start from a built version than a blank file, the Client Onboarding & Scope Control OS<\/a> packages this workflow as a PDF guide plus an Excel system with the intake register, deliverables sheet and change log already wired together. You can also browse the rest of the operations workbooks in the shop<\/a> if pricing or pipeline is the tighter constraint right now.<\/p>",
"protected": false
},
"excerpt": {
"rendered": " A five-day onboarding system for freelancers and agencies: intake registers, approval gates, a revision budget and a change request rule you can run in one spreadsheet.<\/p>",
"protected": false
},
"author": 1,
"featured_media": 0,
"comment_status": "open",
"ping_status": "open",
"sticky": false,
"template": "",
"format": "standard",
"meta": {
"_jetpack_memberships_contains_paid_content": false,
"footnotes": ""
},
"categories": [
33
],
"tags": [
73,
74
],
"class_list": [
"post-352",
"post",
"type-post",
"status-publish",
"format-standard",
"hentry",
"category-business-productivity",
"tag-onboard-a-new-client",
"tag-scope-management"
],
"aioseo_notices": [],
"aioseo_head": "\n\t\n\t\n\t\n\t\n\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n
Step Two: Define Deliverables, Approval Gates and a Revision Budget<\/h2>\n
\n
Step Three: Price Change Requests Instead of Arguing About Them<\/h2>\n
\n
Worked Example: A Six-Week Brand and Website Sprint<\/h3>\n
The First-Week Onboarding Checklist<\/h2>\n
\n
Where a Spreadsheet Stops Being Enough<\/h2>\n