Brainforge Knowledge

email-communication-standards

7 min read

Email Communication Standards

Last updated: 2026-03-19
Applies to: Client-facing email and calendar workflows created by humans or agents

1) Purpose

This standard keeps Brainforge client communications consistent across:

  • Calendar event titles
  • Meeting links (Zoom/Meet)
  • Client email subject lines and body structure

Use this together with:

  • standards/02-writing/Communications/email-update-template.md
  • standards/04-prompts/email-client-comms-sop.md
  • standards/03-knowledge/engineering/setup/google-workspace-cli-setup.md

2) Calendar title standard

Required format

Use this exact pattern for client meetings:

[Client] | [Meeting Type] | [Cadence or Phase]

Examples

  • LMNT | Weekly Delivery Sync | Weekly
  • CTA | Data Platform Review | Sprint 4
  • ABC Home and Commercial | Executive Check-In | Monthly
  • Eden | AI Service Standup | Weekly

Rules

  1. Put the client name first.
  2. Use title case for each segment.
  3. Keep labels specific; avoid vague names like “Client call” or “Meeting”.
  4. Do not include ticket IDs in calendar titles.
  5. Keep to three segments unless the third segment adds no value.

Edge cases and examples

SituationHow to title
Two Brainforge attendees, one clientStill lead with client: LMNT | Architecture Review | Ad Hoc (attendees do not change the pattern).
Client + partner/vendor on the lineName the paying/primary account first: CTA | Vendor Onboarding (with Acme) | Sprint 4 — keep third segment cadence/phase when it still applies.
Internal-only prep (no client)Do not use this doc’s client pattern; use an internal title (e.g. Internal | LMNT Delivery Prep | Weekly).
Very long legal client nameUse the vault folder / Linear team name short form consistently: ABC Home | Executive Check-In | Monthly if that is how the account is labeled everywhere.
Same meeting type twice in one dayAdd a disambiguator in segment 2: Eden | Data Model Review (AM) | Weekly vs Eden | Data Model Review (PM) | Weekly, or use date: … | Mar 19.
One-off / no recurring cadenceUse Ad Hoc or the date as segment 3: LMNT | Contract Discussion | Ad Hoc or LMNT | Contract Discussion | Mar 19.
Workshop or multi-hour working sessionBe explicit in segment 2: Eden | Workshop: Prompt Library | Phase 1.
Escalation or exec-onlyKeep professional and specific: ClientX | Executive Escalation | Ad Hoc — never put severity or internal codes in the title.

3) Meeting link standard (Zoom / Google Meet)

Primary rule

A calendar event should have one canonical join link. Do not include multiple competing links.

Placement rules

  1. Put the canonical link in the event Location field.
  2. In the event description, include a short “Join” line that repeats the same canonical link:
    • Join: https://...
  3. If there is a fallback dial-in or backup link, put it below as “Backup” and label it clearly.

Examples

Good

  • Location: https://zoom.us/j/1234567890
  • Description:
    • Join: https://zoom.us/j/1234567890
    • Backup: https://meet.google.com/abc-defg-hij

Bad

  • Location has Zoom, description has a different Zoom link
  • Both Zoom and Meet included with no indication of primary link
  • Link buried in long notes with no “Join:” label

Zoom preference

If the client has an established Zoom room, keep using it unless explicitly changed.

4) Client email writing standard

Subject line format

Use:

[Client] - [Topic] - [Action or Timeframe]

Examples:

  • LMNT - Weekly Update - March 11
  • CTA - Dashboard QA Follow-Up - Action Needed
  • Eden - Standup Recap - Next Steps

Subject line edge cases

SituationPattern
Multiple distinct topicsPick the single primary topic for the subject; put the rest in the body: LMNT - Weekly Update - March 11 with bullets for each thread inside.
Urgent / time-sensitiveKeep format; put urgency in segment 3: CTA - API Outage Mitigation - Response Needed Today — avoid ALL CAPS.
FYI only (no ask)Segment 3 states that: Eden - Platform Metrics - FYI or … - No Action Needed.
Forwarding / continuing a threadPrefer Re: / existing thread in the mail client; if a new subject is required, still use [Client] - [Topic] - [Action or Timeframe].
External recipient who does not know “Brainforge” jargonTopic in plain language: LMNT - Summary of Today’s Call - Next Steps not LMNT - EP Audit Closeout - SHIP.
Same topic, second email same weekAdd specificity in segment 2 or 3: LMNT - Dashboard QA - Follow-Up #2 or include a date in segment 3.

Body structure (default)

  1. Context (1-2 lines)
    Why you are writing now.
  2. Key updates (bullets)
    What changed, completed, or unblocked.
  3. Decisions / asks (bullets)
    What the recipient needs to approve, decide, or provide.
  4. Next steps (bullets with owner/date when possible)
    Keep this explicit.
  5. Scheduling line (optional)
    Confirm next sync date/time or propose options.

Tone and style rules

  • Clear, direct, and professional.
  • Prefer short paragraphs and bullets.
  • Avoid inflated or promotional language.
  • Do not include internal-only notes, ticket IDs, or internal debates in client-facing email.
  • If an item is uncertain, label it as tentative instead of presenting it as final.

Length guideline

  • Default target: 120-250 words.
  • Longer only when decisions, risks, or asks require more detail.

5) Agent-specific requirements

When an agent drafts email/calendar content:

  1. Output the draft in chat first.
  2. Do not send email automatically unless the user explicitly asks.
  3. Ask whether the user wants the draft saved as markdown in the appropriate repo path.
  4. Follow CLI-first (gws) and use MCP as fallback.

6) Exceptions and special cases

Use this section when the default patterns would confuse the client or misrepresent the meeting.

  1. Client-mandated naming — If the client’s IT or exec office requires a specific calendar prefix or subject pattern, follow their rule for their invites and document the exception in the engagement README or internal notes.
  2. Slack Connect vs email — If the “email” is really a long Slack post copied to email, still use the subject-line standard for anything that lands in Gmail; keep Slack-specific shorthand out of the subject.
  3. Legal / procurement / security reviews — Titles and subjects should name the artifact or gate (e.g. CTA - MSA Redlines - Review by March 20), not internal ticket keys.
  4. Incidents — Subject should reflect impact and ask, not internal severity codes: good: LMNT - Reporting Delay - Status Update; avoid: LMNT - P1 INC-442 - UPDATE.
  5. White-label or partner-led comms — When sending as or through a partner, align with partner branding rules; if Brainforge is visible, keep [Client] as the end customer name.
  6. Ambiguous client name — When two subsidiaries share a calendar, use the name that matches Linear team / vault path so search and reporting stay consistent.

When in doubt, prefer clarity for the recipient over strict three-part formatting—but default back to the standard for all routine syncs.

7) Quality checklist

Before finalizing, confirm each item that applies.

Calendar

  • Title follows [Client] | [Meeting Type] | [Cadence or Phase] (or documented exception in §6)
  • Client name matches vault / Linear naming for searchability
  • Meeting type is specific (not “Meeting” / “Sync” alone)
  • Third segment adds value (Weekly, phase, Ad Hoc, or date)—or omitted only when redundant
  • No ticket IDs, internal codes, or severity labels in the title
  • Exactly one canonical join link is obvious (Location + matching Join: line)
  • Any backup/dial-in is labeled Backup: and is secondary
  • No conflicting Zoom/Meet URLs between Location and description

Email subject

  • Subject follows [Client] - [Topic] - [Action or Timeframe] (or documented exception)
  • Topic is plain language for the recipient
  • Action/timeframe in segment 3 matches the primary ask or FYI intent

Email body

  • Opening context states why you are writing now
  • Bullets for updates, decisions/asks, and next steps are scannable
  • Every ask has an owner and due date or timeframe where applicable
  • Tentative items are labeled tentative; no false certainty
  • Word count fits the situation (default 120–250; longer only when needed)

Safety and polish

  • No internal-only details (ticket IDs, internal debate, other clients’ names)
  • Tone is direct and professional (no inflated marketing language)
  • If drafted by an agent: draft shown in chat first; send only after human approval unless explicitly automated

Graph View