Skip to content

DOMAIN:CLIENT_COMMUNICATIONS:PITFALLS

OWNER: margot, dima ALSO_USED_BY: faye, sytske, eric UPDATED: 2026-03-26 SCOPE: common client communication mistakes and how to avoid them

PITFALLS:OVERVIEW

CONTEXT: GE's agents handle client communications autonomously within defined boundaries CONTEXT: a single mishandled communication can damage months of trust-building PRINCIPLE: prevention is cheaper than repair — know the pitfalls, avoid them

PITFALL:OVER_PROMISING_TIMELINES

THE_PROBLEM

SYMPTOM: agent tells client "that will be done by Friday" without checking with the team SYMPTOM: client receives timeline commitment that development cannot meet SYMPTOM: repeated missed deadlines erode client trust

IMPACT

  • client loses confidence in GE's reliability
  • team is pressured to rush, increasing bugs and technical debt
  • credibility damage that takes months to recover

PREVENTION

RULE: never commit to a timeline without consulting the PM (faye/sytske) RULE: for any timeline question, respond: "Let me check with the project team and get back to you by [specific date]" RULE: when providing estimates, add buffer: if team says 3 days, tell client 5 days RULE: underpromise and overdeliver — never the reverse RULE: if a deadline will be missed, notify client BEFORE the deadline (see bad news delivery in client-relationship.md)

GOOD: "I will confirm the timeline with the team and get back to you by tomorrow afternoon." BAD: "No problem, we can have that done by next week."

PITFALL:TECHNICAL_JARGON_WITH_NON_TECHNICAL_CLIENTS

THE_PROBLEM

SYMPTOM: email to client contains "API endpoints", "database migration", "CI/CD pipeline" SYMPTOM: client does not understand the status update and feels lost SYMPTOM: client nods along in meetings without actually understanding

IMPACT

  • client feels excluded and confused
  • misunderstandings about what was delivered or what is needed
  • client stops reading updates because they do not understand them

PREVENTION

RULE: translate every technical concept into business language RULE: if a technical term is unavoidable, explain it in one sentence

TRANSLATIONS: - "API" → "the connection between your system and the external service" - "database migration" → "restructuring how your data is stored (no data lost)" - "CI/CD pipeline" → "our automated quality check that runs before every update goes live" - "deployment" → "publishing the update to your live website" - "bug fix" → "fixing an issue that was causing [specific problem]" - "refactoring" → "improving the internal structure to make future changes faster" - "responsive design" → "making sure it works well on phones, tablets, and desktops" - "caching" → "making your website load faster by remembering frequently used data" - "authentication" → "the login system" - "staging environment" → "a test version of your website that is not public"

RULE: read every client email out loud before sending — if you would not say it to your non-technical friend, rewrite it

PITFALL:INCONSISTENT_UPDATES

THE_PROBLEM

SYMPTOM: status updates arrive on random days, sometimes skipped entirely SYMPTOM: client does not know when to expect communication SYMPTOM: client feels forgotten during quiet development phases

IMPACT

  • client anxiety increases during communication gaps
  • client starts sending "what is happening?" emails (reactive, not proactive)
  • perception that GE is disorganized

PREVENTION

RULE: status updates on the SAME day each week (e.g., every Thursday afternoon) RULE: never skip a status update — even if there is nothing new, say so RULE: if the regular update day falls on a holiday, send the day before RULE: set expectation in kickoff meeting: "You will hear from us every Thursday"

TEMPLATE_FOR_QUIET_WEEKS: 

Subject: Status update — {project_name} | Week {number}

Dear {client_name},

This week the team is heads-down on {current_work}. No new items to
report, but work is progressing as planned.

You will see concrete results in next week's update when {specific_item}
is ready for review.

Kind regards,
{pm_name}

PITFALL:IGNORED_CLIENT_PREFERENCES

THE_PROBLEM

SYMPTOM: client asked for communication via Slack, team keeps sending email SYMPTOM: client prefers Dutch, team communicates in English SYMPTOM: client said they do not want Friday meetings, team keeps scheduling them

IMPACT

  • client feels unheard and unvalued
  • small irritations compound into relationship damage
  • signals that GE does not pay attention to details

PREVENTION

RULE: capture communication preferences in kickoff meeting RULE: store preferences in client profile (language, channel, timezone, meeting preferences) RULE: review preferences before every communication RULE: if preferences change, update the profile immediately RULE: periodically ask "Is this communication style working for you?"

PREFERENCES_TO_CAPTURE: - preferred language (Dutch, English, German) - preferred channel (email, Slack, Teams, phone) - preferred update frequency (weekly, bi-weekly) - preferred meeting days/times - timezone - formality preference (formal, semi-formal, casual) - who should receive communications (just primary contact, or team) - how they prefer to receive files (email attachment, shared drive link)

PITFALL:TIMEZONE_CONFUSION

THE_PROBLEM

SYMPTOM: meeting scheduled for "3 PM" without specifying timezone SYMPTOM: client in different timezone shows up at wrong time SYMPTOM: "end of day" deadline interpreted differently across timezones

IMPACT

  • missed meetings damage professionalism
  • deadline confusion leads to misaligned expectations
  • particularly problematic for international clients

PREVENTION

RULE: always include timezone in every meeting invitation and deadline RULE: GE operates in CET/CEST (Central European Time) — state this explicitly RULE: for international clients, show both timezones: "3:00 PM CET / 9:00 AM EST" RULE: calendar invitations must include timezone-aware time RULE: "end of day" means 18:00 CET unless otherwise specified RULE: "business days" means Monday-Friday CET unless otherwise specified

GOOD: "The update will be delivered by Thursday, March 26, 18:00 CET." BAD: "The update will be delivered by end of day Thursday."

PITFALL:SCOPE_CREEP_ACCEPTANCE

THE_PROBLEM

SYMPTOM: client says "can you also just add..." and agent says "sure" SYMPTOM: small additions accumulate into significant unscoped work SYMPTOM: project goes over budget because of accepted scope additions

IMPACT

  • project profitability drops
  • timeline extends without formal agreement
  • sets precedent that scope changes are free

PREVENTION

RULE: any request that is not in the original scope must be flagged RULE: response: "That is a great idea. Let me assess the impact on timeline and budget and get back to you." RULE: PM (faye/sytske) assesses scope change: is it < 2 hours? Include as goodwill. Is it > 2 hours? Formal change request. RULE: for changes > 2 hours: provide written estimate with timeline and cost impact before starting RULE: get written approval for any scope change that affects budget or timeline

THRESHOLD_FOR_GOODWILL: - under 2 hours: include without formal change request (builds relationship) - 2-8 hours: informal email confirmation from client ("Yes, go ahead") - over 8 hours: formal change request with signed approval

GOOD: "I love the idea of adding a dashboard widget for that. Let me check what it would take and whether it fits in the current timeline." BAD: "Sure, we can add that."

PITFALL:CONFLICTING_INFORMATION_FROM_MULTIPLE_AGENTS

THE_PROBLEM

SYMPTOM: margot says project is on track, faye says there is a delay SYMPTOM: dima promised a feature during intake that was not in the contract SYMPTOM: client receives different answers from different GE contacts

IMPACT

  • client loses trust in GE's organization
  • creates confusion about what is actually happening
  • may lead to disputes about what was promised

PREVENTION

RULE: clear boundaries between agent roles (see client-relationship.md) RULE: margot handles relationship comms, faye/sytske handle project comms RULE: if asked about a topic outside your scope, say "Let me connect you with {correct person} who handles that" RULE: before communicating timeline or scope information, verify with the PM RULE: dima's intake notes are reviewed against the signed contract — no promise survives unsigned

HANDOFF_PROTOCOL: - dima → eric: intake summary with all discussed features (eric verifies against contract) - eric → margot: contract signed, client profile with preferences - margot → faye/sytske: relationship context, client personality notes - faye/sytske → margot: project status for relationship communications

PITFALL:GOING_SILENT_DURING_PROBLEMS

THE_PROBLEM

SYMPTOM: something goes wrong, and GE goes quiet hoping to fix it before the client notices SYMPTOM: client discovers the problem themselves (through their users, or by checking the site) SYMPTOM: silence is interpreted as either ignorance or evasion

IMPACT

  • client feels blindsided
  • trust damage is worse than the original problem
  • client assumes the worst during silence

PREVENTION

RULE: bad news delivered fast is better than bad news delivered late RULE: if a problem is discovered, notify client within 24 hours RULE: even if the fix is underway, inform the client that there IS a problem and you ARE working on it RULE: update frequency during incidents: every 4 hours for SEV 2, every 60 minutes for SEV 1

SEE: client-relationship.md → BAD_NEWS_DELIVERY SEE: escalation-matrix.md → SEVERITY_LEVELS

PITFALL:OVER_COMMUNICATING

THE_PROBLEM

SYMPTOM: client receives 3 emails per day about minor details SYMPTOM: every small decision is escalated to the client for approval SYMPTOM: client feels overwhelmed and starts ignoring GE's emails

IMPACT

  • important communications get lost in noise
  • client feels GE cannot make decisions independently
  • client time is wasted on low-priority details

PREVENTION

RULE: batch non-urgent items into the weekly status update RULE: only contact client outside regular cadence for urgent items RULE: decision threshold: if the answer does not affect timeline, budget, or user experience, make the decision internally RULE: present decisions with a recommendation: "We recommend Option A because X. Do you agree, or would you prefer Option B?" RULE: if in doubt about whether to communicate something, ask: "Would the client want to know this right now, or can it wait for the weekly update?"

PITFALLS:AGENT_INSTRUCTIONS

FOR margot: - review this list monthly — are any of these happening in active client relationships? - when you detect a pitfall occurring, intervene proactively - maintain client preference profiles and remind team members

FOR dima: - during intake, be careful not to over-promise features or timelines - everything discussed in intake must be captured in writing for eric to review against the contract - never say "yes" to scope — say "let me check what is possible"

FOR faye, sytske: - you are most at risk for scope creep acceptance — follow the threshold rules - status updates are YOUR responsibility — never skip, never be late - before every client communication, ask: "Am I speaking their language or mine?"

FOR eric: - verify intake promises against contract terms before signing - flag any discrepancy between what dima discussed and what the contract covers - if a client raises a legal concern, respond promptly — silence on legal matters is particularly damaging

READ_ALSO: domains/client-communications/client-relationship.md, domains/client-communications/escalation-matrix.md, domains/client-communications/tone-guidelines.md