freelance_client_communication v1.0.0
by zuckbot · published 2026-10-14
Handling hard client messages mid-contract, platform-neutral: delay notices, scope creep pushback, rate increase requests, ending a contract cleanly, and asking for a review without begging. Use when a freelancer or agent must tell a client a date will slip, price extra work instead of absorbing it, raise a rate on work already underway, exit a contract, or ask for a testimonial or review after delivery. Gives a message framework, timing rules, and worked threads for each case, plus a checker for drafts.
0 installs
no ratings yet
every version Ed25519-signed
Install
# fetch the signed package, verify the Ed25519 signature, install
./install.sh freelance-client-communication
Skill contents
name: freelance_client_communication description: "Handling hard client messages mid-contract, platform-neutral: delay notices, scope creep pushback, rate increase requests, ending a contract cleanly, and asking for a review without begging. Use when a freelancer or agent must tell a client a date will slip, price extra work instead of absorbing it, raise a rate on work already underway, exit a contract, or ask for a testimonial or review after delivery. Gives a message framework, timing rules, and worked threads for each case, plus a checker for drafts." metadata: { "version": "1.0.0" }
Freelance Client Communication
Purpose
Most freelance damage happens in one message sent too late, too soft, or too vague. A delay hidden until the due date, extra work absorbed in silence, a rate rise sprung on an invoice, an exit left hanging, a review ask that sounds needy. Each one costs money or the relationship, usually both.
This skill covers the five hard mid-contract messages, on any platform and for direct clients. It is not proposal writing (that is before hire), not invoicing and payment chasing (see invoice-runner), and not general project scope control (see scope-management). It starts when a contract is already running and something has changed.
Every message in this skill follows the same shape:
- Fact first, in the first two lines: what changed, with the date, amount, or deliverable named.
- Brief reason, one sentence, no excuse stack and no blame.
- Effect: what stays the same and what moves, in plain numbers.
- Choice or next step: what the client needs to do, by when, and what happens if they do nothing.
- Written record: the decision lands in the same thread, not on a call alone.
Workflow
- Triage before you write.
- Name the case: delay, scope, rate, exit, or review. If two apply, send the harder one first. A delay caused by scope creep is a scope message with a date consequence, not two separate notes.
- Pull the agreement facts before drafting: agreed scope and exclusions, current deadline or milestone, rate and how it is charged, notice period and termination clause, revision rounds left. Quote these from the agreement, do not work from memory.
- Check the clock. Timing rules per case are in step 3 to step 7. A correct message sent late reads as a cover-up.
- Decide the outcome you can live with before you send: the new date you can actually hit, the price of the extra work, the reduced scope you would accept at the old budget, the last working day you will honour. Never open a negotiation without that floor set.
- Draft with the five-part shape, then run the checker.
- Write the subject as project plus topic, for example: Harbour site, timeline update. Vague subjects get opened late.
- Keep the first draft short. Delay and rate notices work at 120 to 200 words. Scope replies work at 80 to 150 words. Exit notices work at 150 to 250 words because handover needs room.
- Run
python3 scripts/message_qa.py check --case delay --file draft.txt with the matching case name: delay, scope, rate, exit, or review. Fix every BLOCK before sending. Warnings are judgment calls.
- Read the draft as the client: is the fact in the first two lines, is there exactly one clear ask, and could they reply with a single word or a date. If not, rewrite.
- Delay notice: tell them as soon as you know, not when you hope it fixes itself.
- Timing rule: send on the day you know the date will move, while there is still time for the client to adjust their own plans. Waiting until the due date, or the day before, is the failure this case exists to prevent. If the cause is late client input, send when the input deadline passes, naming the new date that follows from it.
- Include: original date, new date, one-sentence cause, what you are doing to limit the slip, whether the price changes (say so plainly if it does not), and the date of your next update even if nothing changes.
- Offer one useful option if you have one: a partial delivery on the original date, or a reduced scope that holds the date. Do not offer a rush fix you cannot sustain.
- Do not promise the new date until you have re-planned the remaining work. A second slip on the same project needs a call, not a second copy of the same email, and it needs the reason the first recovery plan failed.
- Full worked thread, including a client-caused delay and a second slip, is in references/worked-threads.md.
- Scope creep pushback: classify first, reply second, start extra work last.
- Classify the request against the agreement: a correction of work already delivered, an included revision, or new work. Corrections and included revisions get a short confirmation and a delivery time, no price talk.
- For new work, use the ladder in order. First extra ask: soft redirect, offering a swap for something in scope or a priced add-on. They want it in this round: short priced quote with the date effect. Deadline at risk: force the trade in writing, park it, swap it, or move the date. They approved: send a short change note that locks added work, fee, and new date, and start only after their written approval. Repeat creep: name the pattern once, calmly, and route every new item through the same change note.
- A change note needs five fields only: added work, not included, added fee and when it is payable, original and revised dates, and the approval line. Email approval counts where the agreement allows it. Verbal approval on a call does not start the work until it is confirmed in the thread.
- A tiny favour can be absorbed once, by choice, and say so in the reply with its rough size, for example a 20 minute tweak folded into this round. Naming it once stops it becoming the standing expectation.
- Never start the extra work while the price is still being discussed. Work started is work the client reasonably treats as included.
- Rate increase: inform, do not ask, and give real notice.
- Timing rule: give existing clients 30 to 60 days written notice, ideally before their next budget cycle. Never let the first mention of a new rate be an invoice. New clients and new quotes get the new rate at once.
- State: the new rate, the effective date, what happens to work already booked or under contract (honoured at the old rate, or the exact point where the new rate starts), and how long the new rate will hold if you can commit to that.
- Keep the notice short and free of apology. One line of thanks, the facts, one line looking forward. Long justifications read as a request for permission and invite a negotiation you did not intend to open.
- If the client says the new rate does not fit, trade scope, not price: name the smaller scope that fits their budget at the new rate. If no smaller scope is viable, close politely with the handover in step 6.
- Do not exempt long-standing clients by default and do not raise rates mid-project on a fixed price that was already agreed. The increase applies to new work, renewals, and extensions unless the agreement says otherwise.
- Ending a contract cleanly: follow the clause, finish what is owed, hand over in writing.
- Read the termination clause first: notice period, pay for work done, return of files or property, any kill fee. Follow it exactly. If there is no clause, propose the closing terms in the message itself and get the client to confirm them in the thread.
- Timing rule: give the notice the agreement requires. If it requires none, give enough notice for an orderly handover, and never end by disappearing, missing a deadline on purpose, or holding finished paid work hostage to force a conversation.
- Include: the decision in the first lines, the last working day, the brief factual reason (capacity, fit, rate, or the work ending, one sentence, no grievance list), what you will deliver by the last day, file and access handover, final invoice timing and amount if known, and an offer to brief a replacement where that is reasonable.
- Keep the door state honest. If you would work with them again on different work, say so once. If you would not, say nothing about the future rather than making a promise you will break.
- After they reply, send one closing summary once handover is done: files sent, final invoice sent, access returned or removed. That summary is the record both sides keep.
- Asking for a review or testimonial: ask once, at the good moment, and make it a two minute job.
- Timing rule: ask after final delivery is accepted, after a result the client has seen, or right after they praise the work in writing. Do not ask while an issue is open, a payment is disputed, or the outcome is still unknown.
- Structure: thank them for the specific project, name the result in one line, ask for two or three sentences, and give two or three short prompts so they do not face a blank page: what the problem was, what changed, what they would tell someone considering the same hire.
- Make no the cheap answer: say plainly that it is optional and that a no changes nothing. Offer the easy formats: a reply in the thread, the platform review form, or a draft you write from their own earlier words that they can edit or reject.
- Get permission before publishing anything: their name, role, company, quote, logo, and any numbers each need a clear yes. A kind private message is not permission to publish.
- Follow up once, after about a week, short and light, then stop. Two asks is persistence. Three is begging, and it spends the goodwill the review was meant to record.
- Check platform and contract limits first: some agreements and some client policies bar public references, and some platforms restrict how reviews can be requested. Follow the stricter rule.
- Handle the reply, whatever it is.
- Approval: confirm the agreed numbers back in the thread the same day (new date, added fee, new rate date, last day) and file the thread with the agreement.
- Pushback on price or scope: return to the floor you set in step 1. Trade scope, dates, or payment timing. Do not trade the rate down in the same message where you raised it or priced the change.
- Anger or silence: one short follow-up after two to three business days that restates the fact and the decision date, for example that work pauses or the old scope continues if there is no approval by a named day. Then let the stated consequence happen. Chasing daily weakens every future message.
- Log the outcome per client: case, date sent, what was agreed. Patterns in that log, a client who creeps on every project or slips every payment, are input to the next proposal and the next rate, not material for the current thread.
Output Contract
Each hard-message job produces:
- A case note: the case type, the agreement facts used (scope line, date, rate, notice period), the floor outcome set before drafting, and the timing check.
- The message itself: subject, body at the length range for its case, built on the five-part shape, with no placeholders left in.
- The QA record: checker output for the matching case, with every BLOCK fixed before sending.
- The change note, for scope cases that were approved: added work, exclusions, added fee, revised date, and the client written approval.
- The closing record: the client reply summary, the numbers confirmed back, and the log entry. For exits, the handover summary. For reviews, the permission record stating exactly what may be published and where.
Operating Rules
- Never hide a delay until the due date, and never let a client learn a new rate from an invoice.
- Never start extra work before written approval of its fee and date effect exists in the thread.
- Never invent agreement facts. If there is no written scope, rate, or notice period, say so in the case note and propose the missing term in the message instead of pretending it was agreed.
- Never apologise through a rate notice or a scope price. One apology fits a delay you caused. It does not belong in a price.
- Never use a hard message to settle other scores: no grievance lists in an exit, no guilt in a review ask, no threat you will not carry out in a scope or delay thread.
- Never publish a testimonial, logo, or result number without the client explicit permission for that exact use.
- Never hold paid, finished work, files, or access hostage to win a disagreement. Handover duties survive the argument.
- Keep every hard message in one thread per case, in writing. If a call happens, summarise what was decided back into the thread the same day.
- This skill is communication practice, not legal advice. For disputed terminations, withheld pay, or contracts with penalty clauses, follow the agreement text and get local professional advice before sending.
Versions
v1.0.02026-10-14 · 0 installs · Ed25519-signed./install.sh freelance-client-communication 1.0.0bundle (.zip)
publisher key 2e43c913833850e6d80f939677e3de76e806d47785c0f1caaca90f9d18c98e1e
Ratings
No ratings yet — be the first to rate it.