Example
How to leave a freelance client cleanly when the work no longer fits
A relationship can be good and still occupy the wrong future.
AI assistance helped shape this fictional example from a structured editorial brief. It was reviewed for usefulness, distinctness, accessibility, and product truth.
End the retainer with honest notice, complete artifacts, and no invented emergency
Purpose, boundaries, and the definition of enough
Hold the mission and boundary: end the retainer with honest notice, complete artifacts, and no invented emergency
The decision and preparation that deserve attention next
Hold the live choice—whether to offer a shorter transition retainer, name a final date, or refer the client immediately—so Noah can decide from the evidence in this Room
Draft a notice that names the chosen handoff path, final responsibility, and date
Draft one question about homepage approval and a separate question about the final invoice
Mark each source package ready, incomplete, or needing a client question before promising a handoff
The visible proof behind the plan—not a vague feeling of readiness
Inventory the logo source, page layouts, design-system files, and invoice state without assuming client approval
Name the source package Noah must transfer
Separate approved layouts from work that may require a client question
Record the reusable component source included in the handoff
Determine the current state before treating payment or acceptance as Waiting
Record the actual notice period and deliverables promised in the agreement
Name what Noah wants to preserve without letting goodwill choose the exit path
Show which higher-value work the recurring requests interrupt
Noah is an explicitly fictional portrait, not a customer or testimonial.
The Clean client exit Board gives one mission a visible field; the Transition, final date, or referral Room keeps its evidence, conversation, state, and decision together.
Current You.one provides the Superboard structure and explicit, bounded Ava paths described here; broader proactive or external work is not a current promise.
Why Clean client exit needs an operating picture
Noah is a fictional 42-year-old independent designer ending a four-year client relationship in Edmonton, Alberta. The client is kind, the retainer is reliable, requests now interrupt higher-value work, and several source files and open approvals need a deliberate handoff.
A good relationship does not tell Noah whether the client needs a short transition, a firm final date, or a referral.
Homepage approval and invoice state are not Waiting until Noah learns the current state and actually sends a question.
In You.one's Superboard view, Noah can give “End the retainer with honest notice, complete artifacts, and no invented emergency” a Board of its own. That Board connects a four-year retainer, source-file packages, uninventoried approvals and invoice state, and three exit paths; opening “Transition, final date, or referral” creates a Room for its evidence, discussion, state, and decision.
Clean client exit has one live choice: Transition, final date, or referral
The mission is specific: End the retainer with honest notice, complete artifacts, and no invented emergency.
The consequential choice is not something a board or an AI should quietly make: Whether to offer a shorter transition retainer, name a final date, or refer the client immediately.
You.one can keep the work, evidence, and “Transition, final date, or referral” decision visible through its Superboard view. The Owner boundary stays explicit: Noah chooses transition, a final date, or referral and owns the notice, source-file map, and deliverables he promised. The client owns whether a transition, final date, referral, homepage copy, or final invoice is accepted.
Available today
Clean client exit: one Board shape to adapt
The Clean client exit Board gives this mission one durable operating picture. Noah can use familiar language instead of translating the situation into project-management jargon. Its three Lists separate the kinds of attention this situation actually requires.
Its Cards deliberately distinguish actions, evidence, and decisions while keeping unsent questions in owned work. A Waiting List would be premature until a named request or outside condition is actually in motion. That separation makes the current choice, evidence, and next move easier to scan.
| List | What belongs here |
|---|---|
| Exit promise | Purpose, boundaries, and the definition of enough |
| Handoff work | The decision and preparation that deserve attention next |
| Account evidence | The visible proof behind the plan—not a vague feeling of readiness |
Available today
The Cards make the operating picture concrete
These Card titles come directly from Noah's situation: “Transition, final date, or referral” is the live choice, “Logo source, page layouts, design-system files, and final invoice” holds evidence, and “Draft separate homepage-approval and final-invoice questions” is still work Noah controls—not a fake Waiting item. The point is recognition, not a perfect taxonomy.
| Card | List | Job |
|---|---|---|
| Clean client exit | Exit promise | Hold the mission and boundary: end the retainer with honest notice, complete artifacts, and no invented emergency |
| Transition, final date, or referral | Handoff work | Hold the live choice—whether to offer a shorter transition retainer, name a final date, or refer the client immediately—so Noah can decide from the evidence in this Room |
| Logo source, page layouts, design-system files, and final invoice | Account evidence | Inventory the logo source, page layouts, design-system files, and invoice state without assuming client approval |
| Draft the notice | Handoff work | Draft a notice that names the chosen handoff path, final responsibility, and date |
| Draft separate homepage-approval and final-invoice questions | Handoff work | Draft one question about homepage approval and a separate question about the final invoice |
| Mark each source package ready, incomplete, or requiring a client question | Handoff work | Mark each source package ready, incomplete, or needing a client question before promising a handoff |
| Logo source files | Account evidence | Name the source package Noah must transfer |
| Page layouts: approval state not yet inventoried | Account evidence | Separate approved layouts from work that may require a client question |
| Design-system source | Account evidence | Record the reusable component source included in the handoff |
| Final invoice: draft, issue, and acceptance state not yet inventoried | Account evidence | Determine the current state before treating payment or acceptance as Waiting |
| Retainer notice terms | Account evidence | Record the actual notice period and deliverables promised in the agreement |
| Four-year relationship value | Account evidence | Name what Noah wants to preserve without letting goodwill choose the exit path |
| Capacity cost of the current retainer | Account evidence | Show which higher-value work the recurring requests interrupt |
Available today
Available today: Transition, final date, or referral becomes a Room
Opening the Card gives the visible item durable depth. Stage can hold Exit-path brief: Place contract terms, logo source, page layouts, design-system files, homepage-copy approval, final invoice, relationship value, and capacity cost together. Live choice: Whether to offer a shorter transition retainer, name a final date, or refer the client immediately.. Chat keeps the request and response beside that artifact instead of in a detached thread. Pulse can show “Open decision: Noah will decide whether to offer a shorter transition retainer, name a final date, or refer the client immediately.” Activity can preserve this attributed receipt: “Ava compared the options in Card Chat using the Exit-path brief and this Card Room's visible notes and left “Transition, final date, or referral” with Noah.”
A useful Card Chat request would be: “Using only this Card Room and the Exit-path brief, compare a short transition, a final date, and a referral. Treat homepage approval and final-invoice state as unknown until Noah verifies them. Do not send a notice, message the client, invent urgency, or choose.” When live AI is configured, current Ava can respond to an explicit Card mention using supported Room context and can make limited reversible changes inside this Card Room after an explicit request. She uses only supported Room context; she cannot summarize the Board, watch other Lists, or act outside this Card Room. She does not gain authority over the decision merely because the context is organized.
Noah's call remains explicit: Noah chooses transition, a final date, or referral and owns the notice, source-file map, and deliverables he promised. The client owns whether a transition, final date, referral, homepage copy, or final invoice is accepted.
| Surface | Job in this example |
|---|---|
| Stage | Exit-path brief: Place contract terms, logo source, page layouts, design-system files, homepage-copy approval, final invoice, relationship value, and capacity cost together. Live choice: Whether to offer a shorter transition retainer, name a final date, or refer the client immediately. |
| Chat | Keep Noah's request and Ava's attributed response with the work |
| Pulse | Open decision: Noah will decide whether to offer a shorter transition retainer, name a final date, or refer the client immediately |
| Activity | Ava compared the options in Card Chat using the Exit-path brief and this Card Room's visible notes and left “Transition, final date, or referral” with Noah |
What to ask Ava—and what not to assume
These requests use the visible supported context inside the “Transition, final date, or referral” Card Room. They do not imply that current Ava automatically surveys the whole Board or follows up on her own; Noah must provide the relevant facts and check the result.
Current Ava can reply in this Room to an explicit Card mention using supported Room context. She cannot summarize the Board, make the choice, represent Noah, watch other Lists, or act outside this Card Room.
Noah chooses transition, a final date, or referral and owns the notice, source-file map, and deliverables he promised. The client owns whether a transition, final date, referral, homepage copy, or final invoice is accepted. Ava compares only evidence in the choice Card Room and does not contact anyone or decide.
Noah finishes “Mark each source package ready, incomplete, or requiring a client question,” keeps “Logo source, page layouts, design-system files, and final invoice” beside “Transition, final date, or referral,” and does not treat “Draft separate homepage-approval and final-invoice questions” as completed or sent before doing the work.
- Request idea: using only this Card Room and the Exit-path brief, compare a short transition, a final date, and a referral. Treat homepage approval and final-invoice state as unknown until Noah verifies them. Do not send a notice, message the client, invent urgency, or choose.
- Request idea: use only the Exit-path brief and notes the Owner has placed in this Card Room to separate facts, assumptions, and unanswered questions
- Request idea: name which visible Room note could most change the comparison; do not watch other Lists or follow up autonomously
An offboarding email draft may still be enough
An offboarding email draft is enough when “Draft the notice” and “Draft separate homepage-approval and final-invoice questions” no longer change the “Transition, final date, or referral” choice.
It starts to break when “Logo source, page layouts, design-system files, and final invoice” and “Draft separate homepage-approval and final-invoice questions” must inform the same choice.
The Clean client exit Board earns its place only when the familiar tool—an offboarding email draft—can no longer keep the reason, Exit-path brief, conversation, current state, decision, and history connected.
A starter recipe to adapt, not obey
Noah should rename every List or Card that feels artificial. This recipe succeeds when “Transition, final date, or referral” becomes easier to decide and fewer open loops depend on memory—not when the Board looks tidy.
| Step | Action |
|---|---|
| 1. Inventory the handoff | Mark logo, layouts, design-system source, and invoice ready, incomplete, or unknown |
| 2. Read the real agreement | Put notice terms and promised deliverables beside the source-file map |
| 3. Choose the exit path | Compare transition, final date, and referral before writing the notice |
| 4. Draft separate client questions | Do not collapse homepage approval and invoice state into one ask |
| 5. Transition, final date, or referral | Name the selected path, final responsibility, artifacts, and date |
Direction
Direction, not a current promise
The useful future step is timely orientation: Ava may surface “Transition, final date, or referral” when new evidence follows “Draft separate homepage-approval and final-invoice questions”, explain what changed in the Exit-path brief, and stop at the named Owner's authority boundary.
A future unified You.one experience could carry relevant context from “Transition, final date, or referral” across guidance and the Superboard view. Broad proactive coordination, cross-surface personalized memory, realtime shared editing, and general external execution are not available today. Any future action would still require the applicable capability, connection, grant, and human authority.
What this realistic example does not claim
- Noah is fictional and is not a customer, testimonial, research participant, or disguised real person.
- This fictional example is not legal, contractual, tax, or client-relationship advice; the freelancer reviews the actual agreement and owns every communication.
- It does not show Ava completing external actions or contacting anyone for Noah.
- It does not report a measured result, and this Board is a starting shape to adapt—not a universal prescription.