DOMAIN:PROJECT_MANAGEMENT:CLIENT_INTERACTION_FRAMEWORK

OWNER: faye (Team Alfa PM), sytske (Team Bravo PM) UPDATED: 2026-03-28 SCOPE: all client touchpoints across the delivery pipeline PREREQUISITE: delivery-lifecycle.md (the 11-phase pipeline this framework overlays) STATUS: LIVING DOCUMENT — updated as we learn from real client interactions

---

PURPOSE

GE's delivery pipeline (delivery-lifecycle.md) defines 11 internal phases with gates. This framework defines when, how, and why we interact with the client across those phases.

The goal: make the client feel like they're working with a senior, communicative agency — not a black box of agents. Predictability breeds trust. Trust unlocks enterprise.

---

THE THREE DIALS

Every client interaction serves one of three purposes. Get the balance wrong and the client loses confidence:

1. QUESTIONS (information we need from them)

Too few	Just right	Too many
Client feels left out, worries we're guessing	Client feels heard, sees their input shaping the product	Client doubts our seniority, wonders why they're paying us

RULE: every question must be one we genuinely cannot answer from the materials provided. RULE: batch questions into coherent packages — never drip-feed one question at a time. RULE: always present our recommendation alongside the question. "We suggest X. Do you agree, or do you prefer Y?"

2. COMMUNICATION (information we push to them)

Too little	Just right	Too much
Client feels like they're in the dark, GE is a black box	Client feels informed, confident the project is moving	Client feels spammed, starts ignoring updates

RULE: communicate at phase transitions, not during phases. RULE: every update must contain something the client cares about (progress, a decision, a preview) — never just "still working on it." RULE: match the client's communication style. Some want detail, some want headlines. Track this.

3. DECISIONS (choices they must make or approve)

Too few	Just right	Too many
Client feels powerless, delivery happens TO them	Client feels in control, co-creating the product	Client feels burdened, "why am I making all the decisions?"

RULE: only surface decisions the client is uniquely qualified to make (brand, priorities, trade-offs). RULE: never ask the client to make technical decisions. That's our job. RULE: always present options with a clear recommendation. "We recommend A because X. Alternative B trades off Y."

---

STOP/GO MARKERS

These are the mandatory client interaction points overlaid on the 11-phase pipeline. Each marker has a type (Q=question, C=communication, D=decision), a purpose, and an adaptive confidence threshold.

MARKER MAP

PHASE 1: INTAKE (Dima)
  ├── SG-01  [Q+D] REQUIREMENTS ALIGNMENT         — mandatory, never skip
  │
PHASE 2: CONTRACT (Eric)
  ├── SG-02  [D]   COMMERCIAL TERMS                — mandatory, never skip
  │
PHASE 3: SCOPING (Aimee)
  ├── SG-03  [Q]   DESIGN PREFERENCES CHECKLIST    — adaptive (skip items at 90%+ confidence)
  ├── SG-04  [D]   SCOPE APPROVAL + SIGNOFF        — mandatory, never skip
  │
PHASE 4: SPECIFICATION (Anna)
  │         (no client interaction — internal quality phase)
  │
PHASE 5: DESIGN (Alexander)
  ├── SG-05  [C+D] DESIGN PROPOSAL + SIGNOFF       — mandatory, never skip
  │
PHASE 6: PLANNING (Faye/Sytske)
  ├── SG-06  [C]   PROJECT PLAN SUMMARY             — adaptive (skip at 85%+ returning client confidence)
  │
PHASE 7: DEVELOPMENT (Team)
  ├── SG-07  [C]   PROGRESS UPDATE                  — adaptive (frequency adjusts to client preference)
  │
PHASE 8: INTEGRATION (Marije + pipeline)
  │         (no client interaction — internal quality phase)
  │
PHASE 9: UAT (Client)
  ├── SG-08  [Q+D] USER ACCEPTANCE TESTING          — mandatory, never skip
  │
PHASE 10: DEPLOYMENT (Jorrit)
  ├── SG-09  [D]   GO-LIVE APPROVAL                 — mandatory, never skip
  │
PHASE 11: HANDOFF (Joost)
  ├── SG-10  [C+D] DELIVERY + SATISFACTION           — mandatory, never skip

---

MARKER DEFINITIONS

SG-01: REQUIREMENTS ALIGNMENT

PHASE: 1 (Intake) OWNER: dima TYPE: question + decision ADAPTIVE: never — this is always the first interaction CHANNEL: chat (Dima chatbot) or human call

PURPOSE: Capture what the client wants, in their words. Understand the business, not just the feature list.

DIMA MUST CAPTURE: - Business context (who they are, what they do, who their customers are) - The problem they're trying to solve - Desired outcome (what does success look like?) - Any existing brand identity, assets, or prior work - Timeline expectations - Budget range (ballpark, not binding — feeds Eric) - Technical constraints they know about - Inspirations (what they like) and anti-inspirations (what they don't)

DIMA MUST NOT: - Promise timelines or pricing - Make technical recommendations - Suggest scope changes - Discuss other clients

OUTPUT: Creative Brief (CB-*) with all fields populated. See CREATIVE-BRIEF-TEMPLATE.md. GATE: Client confirms the Creative Brief reflects their intent.

---

SG-02: COMMERCIAL TERMS

PHASE: 2 (Contract) OWNER: eric TYPE: decision ADAPTIVE: never — payment is always required CHANNEL: document (contract) + payment link

PURPOSE: Formalize the engagement. KYC, pricing, terms, payment.

OUTPUT: Signed contract, confirmed payment method. GATE: Contract signed and first payment received.

---

SG-03: DESIGN PREFERENCES CHECKLIST

PHASE: 3 (Scoping) OWNER: aimee TYPE: question ADAPTIVE: per-item confidence threshold (see ADAPTIVE GATING below) CHANNEL: structured questionnaire (via Dima relay or direct)

PURPOSE: Capture every design-critical preference BEFORE Alexander starts work. This is the gate that prevents the dark-mode class of bugs.

MANDATORY QUESTIONS (grouped by domain):

A. Brand Identity

#	Question	Format	Skip threshold
A1	Do you have existing brand guidelines? If yes, provide them.	file upload / "no"	never skip
A2	What are your brand colors?	hex values / "define for us"	3 projects same brand, 0 changes
A3	Do you have a logo? Provide all variants.	file upload / "no"	3 projects same brand, 0 changes
A4	What is your brand personality? (e.g., professional, playful, minimal, rich)	multiple choice + freetext	3 projects same brand, 0 changes

B. Color & Mode

#	Question	Format	Skip threshold
B1	Default color mode: Light, Dark, or Both with toggle?	single choice	never skip on first project
B2	If both: which is the default?	single choice	follows B1
B3	Should the app respect the user's OS dark/light preference?	yes/no	2 projects same answer
B4	Any colors that must NOT be used?	freetext / "none"	2 projects same answer

C. Typography

#	Question	Format	Skip threshold
C1	Do you have preferred fonts?	file upload / name / "no preference"	3 projects same brand, 0 changes
C2	If no preference: serif, sans-serif, or mixed?	single choice	follows C1

D. Layout & Platform

#	Question	Format	Skip threshold
D1	Primary platform: web, iOS, Android, or all?	multiple choice	per-project (always ask)
D2	Primary device: desktop-first or mobile-first?	single choice	per-project (always ask)
D3	Must it work on tablets?	yes/no	per-project (always ask)

E. Content & Tone

#	Question	Format	Skip threshold
E1	What language(s) must the product support?	list	2 projects same answer
E2	Do you have existing copy/content to use?	yes + files / "no, create for us"	per-project (always ask)
E3	Tone of voice preference? (formal, casual, technical, friendly)	multiple choice	3 projects same brand, 0 changes

F. Accessibility & Compliance

#	Question	Format	Skip threshold
F1	WCAG compliance level required? (A, AA, AAA) — default: AA (EU law)	single choice	2 projects same answer
F2	Any specific accessibility requirements?	freetext / "none beyond standard"	2 projects same answer
F3	Industry-specific compliance? (HIPAA, PCI-DSS, etc.)	freetext / "none"	per-project (always ask)

G. Inspiration

#	Question	Format	Skip threshold
G1	Share 2-3 products/sites you admire visually	URLs	per-project (always ask)
G2	Share anything you explicitly dislike	URLs / description	per-project (always ask)

EXTRACTION RULE: If the client provided a detailed brief (like GE PA's specification), Aimee MUST extract answers from the brief first. Only ask the client questions the brief doesn't answer. Present extracted answers for confirmation: "From your brief, we understand X. Correct?"

OUTPUT: Completed Design Preferences Checklist attached to the project record. GATE: All mandatory items answered. Checklist attached to functional spec.

---

SG-04: SCOPE APPROVAL + SIGNOFF

PHASE: 3 (Scoping) OWNER: aimee TYPE: decision ADAPTIVE: never — scope must always be approved CHANNEL: document review (functional spec) + explicit approval

PURPOSE: Client confirms that what we're about to build matches what they want.

WHAT THE CLIENT RECEIVES: - Functional Specification (plain language, not technical jargon) - Feature priority matrix (MVP / Phase 2 / Future) - Completed Design Preferences Checklist (their answers reflected back) - A "Decisions Summary" — every choice we made or extracted, listed explicitly:

DECISION LOG:
- Color mode: Light primary, dark secondary (from your brief, section 3)
- Brand color: #FF6B2B electric orange (from your brand guidelines)
- Platform: Native iOS only (from intake conversation)
- Typography: System fonts (SF Pro) — our recommendation for native feel
- Compliance: WCAG AA (EU default)
...

WHAT THE CLIENT MUST CONFIRM: - [ ] The feature list matches what I want built - [ ] The priority order (MVP vs later) is correct - [ ] The design preferences are correct (especially: color mode, brand, platform) - [ ] The scope boundary is clear (I understand what is NOT included) - [ ] I approve this specification as the basis for design and development

SIGNOFF: recorded in database with timestamp, client identifier, and version hash of the functional spec.

AFTER SIGNOFF: scope is frozen. Changes require a Change Request (CR) per delivery-lifecycle.md.

---

SG-05: DESIGN PROPOSAL + SIGNOFF

PHASE: 5 (Design) OWNER: alexander TYPE: communication + decision ADAPTIVE: never — visual direction must always be approved CHANNEL: design review package (mockups + decisions doc)

PURPOSE: Client sees what the product will look like before any code is written. This is the last chance to catch visual misalignment cheaply.

WHAT THE CLIENT RECEIVES: - All key screen mockups (Stitch output or equivalent) - A "Design Decisions Document" that explicitly maps every visual choice back to the approved Design Preferences Checklist:

DESIGN TRACEABILITY:
- B1 (color mode): You specified "light primary" → all screens use light backgrounds ✓
- A2 (brand colors): #FF6B2B as primary accent throughout ✓
- D2 (device): Mobile-first, all screens at iPhone 15 dimensions ✓
- C1 (typography): SF Pro system fonts as approved ✓
...

- Any deviations from the checklist, with rationale: "You specified X, but we recommend Y because Z. Do you approve this change?"

ALEXANDER'S PRE-SUBMISSION CHECKLIST (internal, before showing client): - [ ] Every screen uses the color mode from checklist item B1 - [ ] Brand colors match checklist items A2 exactly (hex comparison) - [ ] Typography matches checklist items C1/C2 - [ ] Platform matches checklist items D1/D2 - [ ] All priority screens from the functional spec are represented - [ ] Tab bars / navigation is consistent across ALL screens - [ ] Accessibility contrast ratios pass WCAG level from F1 - [ ] No element contradicts any item in the approved functional spec

WHAT THE CLIENT MUST CONFIRM: - [ ] The visual direction matches my brand - [ ] The color mode is what I requested - [ ] The layout makes sense for my use case - [ ] I have reviewed ALL screens (not just the first one) - [ ] I approve this design as the basis for development

ALLOWED RESPONSES: - APPROVE — gate passes, proceed to specification + development - REQUEST CHANGES — specific feedback, returns to Alexander for revision (max 3 rounds) - REJECT — fundamental misalignment, escalate to Aimee for re-scoping

SIGNOFF: recorded in database with timestamp and version hash of design package.

---

SG-06: PROJECT PLAN SUMMARY

PHASE: 6 (Planning) OWNER: faye / sytske TYPE: communication ADAPTIVE: skip for returning clients with 85%+ satisfaction on prior projects CHANNEL: summary document or brief message

PURPOSE: Set expectations on timeline, cost, and what happens next.

WHAT THE CLIENT RECEIVES: - Estimated delivery timeline (range, not single date) - Estimated cost (range, based on WP count) - High-level breakdown: "We'll build authentication first, then the main screens, then integrations" - What they'll hear from us next (SG-07 progress update or SG-08 UAT invite)

NOTE: no approval required. This is a communication, not a decision. Client can ask questions but doesn't need to sign off.

---

SG-07: PROGRESS UPDATE

PHASE: 7 (Development) OWNER: faye / sytske TYPE: communication ADAPTIVE: frequency adjusts per client preference (see ADAPTIVE GATING) CHANNEL: message via preferred channel (email, chat, admin portal)

DEFAULT CADENCE: - Small project (< 20 WPs): one update when 50% complete, one when done - Medium project (20-50 WPs): daily summary - Large project (50+ WPs): daily summary + weekly client call option

CONTENT: - Progress percentage (WPs completed / total) - What was completed since last update - Any blockers or decisions needed - Expected completion date (updated if changed) - Cost tracking vs estimate

ADAPTIVE: if client never reads updates (no clicks, no responses), reduce frequency. If client asks for more detail, increase. Track per-client.

---

SG-08: USER ACCEPTANCE TESTING

PHASE: 9 (UAT) OWNER: faye / sytske TYPE: question + decision ADAPTIVE: never — client must test and approve CHANNEL: staging URL + test guide + feedback form

PURPOSE: Client verifies the product works as specified. See delivery-lifecycle.md Phase 9 for full UAT process.

---

SG-09: GO-LIVE APPROVAL

PHASE: 10 (Deployment) OWNER: faye / sytske TYPE: decision ADAPTIVE: never — deployment requires explicit approval CHANNEL: explicit go/no-go message

PURPOSE: Client confirms they want to go live.

---

SG-10: DELIVERY + SATISFACTION

PHASE: 11 (Handoff) OWNER: faye / sytske TYPE: communication + decision ADAPTIVE: never — every project ends with this CHANNEL: handoff package + satisfaction survey

WHAT THE CLIENT RECEIVES: - Production URL and access credentials - Operations documentation - Maintenance terms (if applicable) - Satisfaction survey (5 questions, 1-10 scale + freetext)

SATISFACTION SURVEY: 1. How well did the final product match your expectations? (1-10) 2. How was the communication throughout the project? (1-10) 3. Did you feel in control of key decisions? (1-10) 4. How likely are you to use GE for another project? (1-10) 5. What would you improve about the experience? (freetext)

OUTPUT: Satisfaction score stored per-client. Feeds adaptive gating and internal improvement.

---

ADAPTIVE GATING

The framework learns from every client interaction. The goal: skip questions we already know the answer to, increase communication where clients want it, decrease where they don't.

HOW IT WORKS

Every checklist item (SG-03) and every communication preference (SG-07) has a confidence score per client.

CONFIDENCE MODEL:
- New client, first project:     confidence = 0%   → ask everything
- Same answer 1 project in a row: confidence = 33%  → still ask (confirm)
- Same answer 2 projects in a row: confidence = 66%  → ask with pre-fill ("Last time you chose X. Same?")
- Same answer 3 projects in a row: confidence = 90%  → auto-fill, show in decisions summary only
- Client corrects an auto-filled answer: confidence resets to 0% for that item

WHAT CAN BE SKIPPED

• Individual checklist questions (SG-03) when confidence exceeds the item's skip threshold
• Project plan summary (SG-06) for returning satisfied clients
• Progress update frequency (SG-07) adjusts to client behavior

WHAT CAN NEVER BE SKIPPED

• SG-01: Requirements alignment (every project is unique)
• SG-02: Commercial terms (legal requirement)
• SG-04: Scope approval (the contract)
• SG-05: Design proposal + signoff (visual alignment)
• SG-08: UAT (client must test)
• SG-09: Go-live approval (their production)
• SG-10: Delivery + satisfaction (close the loop)

TRACKING

Per-client record in database:

client_interaction_history:
  client_id       -- the client
  project_id      -- which project
  marker_id       -- which SG-nn
  item_id         -- which checklist item (e.g., B1)
  asked           -- boolean: did we ask this time?
  answer          -- what they said
  confidence      -- current confidence score
  auto_filled     -- was this auto-filled from history?
  corrected       -- did client change an auto-filled answer?
  timestamp       -- when

Per-client communication preferences:

client_preferences:
  client_id
  preferred_channel        -- email, chat, portal, phone
  update_frequency         -- daily, twice-weekly, weekly, milestone-only
  detail_level             -- headlines, standard, detailed
  satisfaction_history     -- array of scores from SG-10
  last_updated

---

IMPLEMENTATION

WHO ENFORCES THIS

FAYE and SYTSKE are the gate owners. Before any project enters Phase 6 (Planning / WP decomposition), the PM verifies:

PRE-PLANNING CHECKLIST (PM enforcement):
[ ] SG-01 complete — Creative Brief approved by client
[ ] SG-02 complete — Contract signed, payment confirmed
[ ] SG-03 complete — Design Preferences Checklist fully answered
[ ] SG-04 complete — Functional Spec approved by client (signoff recorded)
[ ] SG-05 complete — Design approved by client (signoff recorded)
[ ] All mandatory items have answers (no blanks in non-skippable fields)
[ ] Design traceability document shows zero contradictions

If ANY of these are incomplete: project is blocked from entering dev pipeline. No exceptions. No "we'll clarify during development."

ORCHESTRATOR INTEGRATION

The ge-orchestrator enforces this programmatically: - Work type planning requires pre_planning_gate: passed in project metadata - The gate is set to passed only when Faye/Sytske mark it in the admin UI - The admin UI shows a checklist view of all SG markers with completion status

CONTRADICTION SCAN

Before SG-05 (Design Proposal), an automated check runs:

For each item in Design Preferences Checklist:
  Compare against DESIGN.md values:
  - B1 says "light" → DESIGN.md surfaces use light palette?
  - A2 says "#FF6B2B" → DESIGN.md primary color = #FF6B2B?
  - D1 says "iOS" → DESIGN.md targets iOS?
  - F1 says "AA" → all contrast ratios pass AA?

If ANY contradiction: BLOCK. Alexander must resolve before client sees designs.

---

COMMUNICATION TEMPLATES

SCOPE APPROVAL REQUEST (SG-04)

Subject: [Project Name] — Scope Review & Approval

Hi [Client Name],

We've completed the scope analysis for [project name]. Here's what we're proposing to build:

[FEATURE SUMMARY — 3-5 bullets, plain language]

Key decisions we've captured:
[DECISIONS SUMMARY — from checklist answers]

What's NOT included (to be clear on boundaries):
[OUT OF SCOPE — 2-3 items]

Please review the attached Functional Specification and confirm:
1. Does this match what you want built?
2. Are the design preferences correct? (especially: [highlight the items most likely to cause misalignment])
3. Anything missing or incorrect?

Once you approve, we'll move to visual design.

[PM Name], Growing Europe

DESIGN APPROVAL REQUEST (SG-05)

Subject: [Project Name] — Design Review & Approval

Hi [Client Name],

Alexander has created the visual designs for [project name]. Attached are mockups for all key screens.

Design decisions (traced to your preferences):
[TRACEABILITY TABLE — checklist item → design choice]

Please review ALL screens and confirm:
1. Does the visual direction match your brand?
2. Is the [color mode / layout / typography] what you expected?
3. Any screens that need changes?

If you approve, we'll begin development. Changes after this point may affect timeline and cost.

[PM Name], Growing Europe

---

METRICS

CLIENT HAPPINESS SCORE

Target: 90%+ across all clients.

Measured via: - SG-10 satisfaction survey (direct) - Revision rounds at SG-04 and SG-05 (indirect — fewer rounds = better alignment) - Time to signoff (indirect — faster = more confident) - Return rate (indirect — repeat clients = trust earned)

ALIGNMENT QUALITY

Measured via: - Contradiction scan pass rate at SG-05 (target: 95%+) - Design revision requests at SG-05 (target: < 1.5 rounds average) - Scope change requests after SG-04 freeze (target: < 0.5 per project) - UAT bug severity distribution (target: zero CRITICAL, < 3 HIGH)

---

RELATIONSHIP TO OTHER DOCUMENTS

• delivery-lifecycle.md — the 11-phase pipeline this framework overlays
• intake-methodology.md — Dima's conversation approach (SG-01 detail)
• scope-architecture.md — Aimee's scoping process (SG-03/04 detail)
• design-system-engineering.md — Alexander's design process (SG-05 detail)
• work-package-design.md — Faye/Sytske's WP decomposition (post SG-05)
• CREATIVE-BRIEF-TEMPLATE.md — the CB format Dima produces
• client-lifecycle.md — older document, superseded by delivery-lifecycle.md + this framework

---

The best system in the world is worthless if the client doesn't trust it. Predictability breeds confidence. Confidence breeds trust. Trust unlocks enterprise. — Growing Europe Client Interaction Framework v1.0