Client operations: proposals, boundaries, difficult clients

An email arrives: “We've seen your work and would love to talk something over. Do you have capacity?” An hour-long call follows, an evening spent writing a proposal from scratch, two weeks of silence, and then the line “great, let's do it, when can you start?” — and from that moment on, you're working. No written scope, no deposit, nobody saying out loud exactly what the finished deliverable is or when it's done.

Six weeks later, the same project has a different name. Five “small things” have been added, the client writes at ten at night and is surprised you don't answer until morning, and nobody remembers whether those three variants were part of the agreement or an extra favor. The invoice goes out with a nagging sense of guilt, because more work got done than the amount on it reflects. And most of all: next time will be exactly the same, because nothing from it got saved anywhere.

A project isn't a new story every time — it's a repeating process with almost identical steps that only looks like improvisation each time because it was never written down. This chapter isn't about being a tougher negotiator. It's about the fact that most conflicts with clients come from things nobody said at the start — and those can be named once, written once, and after that you just fill in names and numbers.

A project's path is the same every time

Try to recall your last five projects. You'll probably get the same list of steps five times, in a slightly different order: an inquiry came in, you clarified something, you sent a proposal, you agreed on something, the work happened, something got delivered, feedback came in, and finally an invoice. The details varied — the field, the amount, the person on the other side — but the skeleton was identical.

That's good news, though it usually doesn't get treated as such. A repeating process can be described, and once it's described it can be sped up, delegated, automated, and above all it stops eating up decision-making energy. The chapter Processes and automation covers this in a company context, but the logic applies even more strongly when you work on your own — there's nobody else to hold in their head what's supposed to happen at each stage.

The practical consequence of this map is simple: every step should have its own text. A reply to an inquiry, qualifying questions, a proposal, an order confirmation, a welcome message at kickoff, an update format, a handover note, a cover note for an invoice. It doesn't have to be built all at once — it gets built by saving the result aside next time you write one of these from scratch. The tip Reply templates from your own sent mail describes how to pull recurring message types out of your own sent folder and turn them into templates written in your own words; for proposals, contracts and invoices it's the same idea by different means — see Templates for proposals, contracts and invoices.

A template isn't mainly about saving minutes. Its main value is that you don't have to remember what you're not allowed to forget. A proposal with a pre-printed “what's not included” section forces you to think about it even on a rushed Thursday evening. An improvised proposal almost always skips that section — and that's exactly where the later dispute comes from.

A proposal that protects both sides

Most proposals focus on what you'll deliver and for how much. But that's only half the information, and it's almost never what conflicts are actually about. What conflicts are about is whatever wasn't written down: how many rounds of feedback are included in the price, whether preparing materials was part of it, what happens when the client delivers assets three weeks late.

So a good proposal rests on four parts.

Scope. What exactly you'll deliver, in what form, and in what quantity. Not “we'll build a website,” but how many pages, how many language versions, how many design options, how many rounds of feedback. Numbers matter more here than adjectives — “responsive, modern and user-friendly” protects nobody from anything.

What's not included. The most valuable and most often skipped part. List out the things a client will naturally assume are baked into the price, and say they aren't: copy, photography, licenses, hosting, training, follow-up support, migrating old data, communicating with third parties. This section looks like a defense, but it actually sells — it's the first time the client sees how much the project actually involves, and they often end up ordering some of it separately.

Assumptions. What has to happen on the client's side for the deadline and the price to hold: materials by a certain date, one contact person with decision-making authority, feedback within five working days, access to systems. And above all, a sentence about what happens when it doesn't happen — the deadline shifts, or the work pauses and gets rescheduled based on open capacity. That isn't a threat, it's information. A client who knows their own delay will shift the deadline behaves differently than one who assumes it'll somehow get squeezed in.

Validity. A proposal has a date after which it stops being valid. Without one, a client comes back after seven months with “okay, let's do it” — and by then your capacity and your terms have changed, but you feel bound by a piece of paper you sent long ago.

A proposal written this way protects both sides. The client learns from it what they'll get and what they need to arrange themselves. And it's also the best defense against a race to the lowest price: if your proposal is the only one showing everything the project actually requires, it stops being comparable to one that just shows a number.

A contract and a deposit aren't distrust

“I don't want to complicate things with a contract, since we understand each other.” Both sides say this line, and both mean it kindly. But a contract doesn't solve the situation where you understand each other. It solves the situation where you stop understanding each other — or, far more common, where each of you remembers something different, with no bad intent on either side.

The best way to think of a contract is as minutes from a meeting that both sides signed. A year later, nobody argues about interpretation, because they just read it. For smaller projects it doesn't have to be anything complicated — a confirmed order by email that references the proposal and your terms covers most of the purpose. For bigger projects, or where copyright and confidentiality are involved, it's worth having a document drafted, or at least reviewed, by a lawyer.

The same goes for contracts the client hands you. Especially with larger companies, a standardized vendor document shows up with clauses about penalties, exclusive rights, long payment terms, or unrestricted return of the work. You're not obliged to accept it unchanged, and a decent client will negotiate on your comments. The tip The contract before you sign: let AI find the catches shows how to go through such a document, spot the catches, and prepare questions for the other side as well as material for a lawyer. The same rule applies here that applies across this whole site: AI proposes, a human approves — the model can help you understand a contract, but it doesn't replace a qualified person's legal review. And actual contracts containing the other party's details belong strictly in a paid account with contractually protected data handling, or should be stripped of identifying details before you paste them in.

A deposit works similarly — as a filter, not as insurance. A client who pays one genuinely wants the project and has budget for it; a client who stalls on a deposit will very likely not pay the final invoice either. You find that out either right away, at the cost of a few hours, or three months later, at the cost of the whole project. For longer projects it makes sense to replace one big deposit with installments tied to milestones — each completed phase gets its own invoice. That solves cash flow, and it also means you're never carrying more unpaid work in progress than you're willing to lose.

You never need more than one sentence to defend it: “This is how I set it up for all my projects.” Deposits and contracts aren't an expression of distrust toward a particular person — they're standard operating terms, just like payment terms or working hours. The moment you start explaining and apologizing for them, you've opened negotiation on something that shouldn't be up for negotiation.

Scope creep: how a small thing turns into a month of extra work

Scope creep — the gradual expansion of the brief — is the quietest way to lose income. It doesn't arrive as a request for twice the work; if it did, you'd say no. It arrives in five-minute pieces, each of which genuinely looks small on its own. It's only the sum that's a disaster, and nobody sees it, because nobody's adding it up anywhere.

A typical run has three phases. First, “it could also use” — small additions you do out of goodwill and never mention are extra. Then “while you're at it” — bigger items you feel awkward flagging, because you already did three previous ones for free. And finally “but we said that from the start,” where the shifted brief gets retroactively presented as the original one, usually entirely sincerely. That last phase can only be won one way: with the paperwork from the first.

Scope creep usually isn't a sign of a client's dishonesty. It arises naturally, because a project sharpens as it takes shape — the client only figures out what they actually wanted once they see the first version. That's legitimate, and you can't ban it. What you can arrange is that a change to the brief goes through a conscious decision by both sides, instead of a silent assumption by one of them.

One sentence handles it, and all you need is the ability to say it without emotion: “Sure, that works. It's beyond the original agreement, so I'll send you a short addendum with the price and the effect on the timeline.” There's no no in it, no reproach, no conflict — just the information that things have a cost, and the client decides whether they want to pay it. Often they say it can wait for phase two, and that's a good outcome for both sides.

A few operating habits go along with this. Keep a running list of out-of-scope requests — including the ones you end up doing for free — and show it at the end of the project; the client then sees how much they got on top. Have a defined number of feedback rounds in the proposal, because endless revisions are the most common form of unpaid work. And distinguish between fixing an error and a new request: whatever doesn't match the brief, you fix for free; whatever changes the brief is new work. That distinction has to be stated before it becomes relevant.

If that addendum line feels uncomfortable — and for plenty of people it does — you can rehearse it. That's exactly what the tip Rehearsing a hard conversation: AI plays the other side is for: have it play a client who's pushing, and test your phrasing beforehand. An improvised reaction in this situation tends to come out either too soft or needlessly harsh.

Boundaries on availability get set at the start

There's one value you set at the start of a collaboration that's almost impossible to change afterward: how fast you respond. If you answer the first three messages within five minutes because you want to make a good impression, you've just set the expectation. A month later, when you take four hours to answer, it won't register as a professional standard — it'll register as the service getting worse.

That's the crux of the whole thing: boundaries don't get set at the moment your patience runs out — they get set at the moment everything's fine. A boundary introduced during a conflict looks like punishment and triggers a reaction. The same boundary stated in a welcome email at the start of the collaboration is simply information about how you work — and nobody blinks at it.

What exactly should you say up front? Four things are enough. Which channel you communicate through — one main channel, not email plus three chat apps plus a phone. What hours you respond in and roughly when a reply will land. What a genuinely urgent situation looks like and what to do about it, because an urgent channel has to exist, or everything becomes urgent. And when a regular update goes out.

That last point gets underrated. Most client pestering isn't impatience, it's uncertainty — someone who paid a deposit and doesn't know what's happening a week later writes in because they need to confirm something is actually happening. A short regular update removes that anxiety before it turns into a phone call, and it costs ten minutes a week. The tip Answer clients in windows, not on call works out the operational shape of responding in fixed windows instead of standing by continuously; the broader principles of handling mail are in the chapter Email communication.

But boundaries aren't the same thing as inflexibility. Sometimes it makes sense to pick up the phone on a Sunday — a critical outage, a client in genuine trouble. The difference is naming the exception as an exception: “I'm taking this outside my usual hours because it can't wait.” The sentence that flags an exception stops it from becoming a new rule. This is exactly the mechanism by which boundaries most often dissolve — not through one big violation, but through a series of unnamed exceptions.

A difficult client: spot it early, address it right away, end it with dignity

When a client relationship isn't working, people on their own usually blame themselves. The truth is more mundane: some projects go badly regardless of how well you work, because the brief, the budget, or the person on the other side doesn't work. The skill worth training isn't “being able to handle anyone” — it's recognizing the problem early.

The warning signs are mostly visible from the first contact already. A client who negotiates on price from the start, without asking about the substance of the work. A client who badmouths every previous supplier — if there were five of them and they were all incompetent, there's a simpler explanation. A client who won't put anything in writing. A client who can't say who decides. A client pushing to start “tomorrow, no later,” but delaying signing and the deposit. And a client who's already testing boundaries before signing — evening phone calls, free sample work, small extras requested already at the proposal stage.

None of those signals on its own means disaster, and people have bad days. But two or more at once is a strong recommendation to slow down: ask more questions, tighten the scope, insist on a written agreement and a deposit. This is the cheapest point at which most bad projects can be stopped.

Once a problem has actually shown up during a project, one rule applies: address it the first time it happens, not the fifth. An uncomfortable conversation after the first broken agreement is short and factual, because it's about one specific thing. The same conversation after the fifth is emotional, because it ends up being about everything at once, and the other side can rightly point out it didn't seem to bother you the previous four times. A useful format avoids blame: what happened, what effect it has on the project, how to do it differently going forward. Not “you keep calling me in the evenings,” but “I need us to agree that requests come by email — details slip through on calls, and that costs us both time.” Someone who doesn't respond even to a second reminder is giving you important information by doing so.

An ending that doesn't hurt you

Sometimes the right answer is to end the collaboration. That isn't a failure — it's a business decision that can be made cleanly, if it's made deliberately. The precondition is that the contract or order allows it; that's why documents should spell out how the collaboration can be ended and what happens then to work in progress and to deposits already paid.

A dignified ending has several parts. Announce it in writing and with notice, don't just disappear. Offer a reasonable handoff: finish the phase in progress, hand over materials in a usable form, possibly recommend someone else. Bill for the work actually done and list what was delivered. And hold back from judging the person — the reason can be stated factually (“the way this collaboration is set up isn't working for me long-term, and I don't want to deliver work at this quality”). The field is always smaller than it looks.

And one thing people rarely do, even though it's the most valuable: after every project that went badly, write down two sentences about what you could have noticed sooner and what you'll change in the process next time — in your intake questions, your contract, your proposal. That's how a bad experience turns into a rule that protects you next time. Skip this step, and the same project comes back a year later under a different name.

Delivering the work, and what comes after

The end of a project tends to get rushed, because by then you're already thinking about the next one. But this is exactly where it gets decided whether a project turns into a repeat client and a referral, or just an invoice and silence. Delivery isn't sending a batch of files. It's the moment you explicitly say: with this, the work is done. A short handover note listing what was delivered, where it lives, and what the client can do with it on their own costs twenty minutes and saves months of confusion. It should also include a sentence about what happens now: how long any error warranty lasts, what counts as paid follow-up work, and whether any form of ongoing support exists.

Without that sentence, a gray zone forms where the client naturally assumes small tweaks will be free forever, because “that's still part of the project.” It isn't bad faith — it's an unfilled gap in the agreement, and everyone fills it in their own way. Fill it in yourself.

After the invoice, three things remain that take half an hour and have the best return-on-time of the whole project. Ask for a reference while the client is still happy, not six months later. Write down notes: how long it actually took versus the estimate, what was unexpectedly hard, what to do differently next time — this single habit produces more accurate estimating more reliably than any methodology. And set a reminder to check in a few months from now, because a new client costs several times the effort of one who's already worked with you. The tip A follow-up watchdog is handy for a light routine that keeps loops from staying open.

The whole close-out of a project, just like invoicing and paperwork, belongs in one standing block — see the tip The Friday admin block. Admin has the property that when it isn't given a fixed rhythm, it seeps across the whole week and eats up more time than it would take done in one focused sitting.

Key takeaways

• A project is a repeating seven-step process, not a fresh adventure every time. Every step should have its own text; templates save less time than they save you from forgetting what matters.
• A proposal shows its quality in what it says is not included. Scope in numbers, an explicit list of exclusions, assumptions on the client's side, and an expiration date protect both sides and pull the proposal out of a race to the lowest price.
• A contract and a deposit aren't distrust — they're standard operating terms. A contract solves the situation where everyone remembers something different; a deposit is a filter that quickly reveals a client with no budget.
• Scope creep happens five minutes at a time, and nobody adds it up. One conflict-free sentence helps: “sure, that works, it's beyond scope, I'll send an addendum with the price and the effect on the timeline.”
• Boundaries on availability get set at the start, not once your patience runs out. How fast you answer the first time sets the expectation for good, and unnamed exceptions quickly turn into the new rule.
• You can usually spot a difficult client from the very first contact. Address the first instance of a problem, not the fifth, and if it's time to end things, end them in writing, with a proper handoff, and without judging the person.
• Delivery is the sentence “this is done,” not sending a batch of files. After the invoice, ask for a reference, log the real time against your estimate, and schedule a check-in — a repeat client is the cheapest client you can have.