Ic Internal Notifier

Internal Notifier

Automates internal notifications when account events occur. Keeps cross-functional teams informed without CSM manual effort. Part of the Internal Coordination pillar.

This is an event-driven notification skill. It sends structured updates to defined recipients when specific triggers fire. It does not make decisions about what to communicate -- it executes a notification ruleset.

When to Run

• Event-driven: Fires when a defined trigger condition is met (from any pillar skill)
• Scheduled: Daily digest of account status changes for configured recipients
• On-demand: When a CSM requests a manual notification to a specific internal audience

Core Execution Logic

Step 1: Monitor Event Streams

Listen for events from all pillar skills:

Step 2: Match Against Notification Rules

Each event maps to a notification rule that defines recipient, channel, urgency, and content:

Step 3: Format and Deliver

Slack notifications (immediate and same-day):

• Maximum 4 lines
• First line: event type and account name (bold)
• Second line: key data point
• Third line: action or urgency indicator
• Fourth line: who should act

Email notifications (weekly digest):

• Subject: "CS Weekly Digest: [date range]"
• Body: grouped by category (renewals, health changes, expansions, escalations)
• Each item: one line with account, event, and status

Formatting rules:

• Never use passive voice in notifications ("Health dropped" not "Health was observed to have dropped")
• Always include the account name, the data point, and who should act
• Always include a link to the full account brief or the relevant CRM record if platform supports it

Step 4: Deduplicate and Manage Fatigue

Deduplication rules:

• Same event, same account, within 24 hours: do not re-notify. Include in daily digest instead
• Related events on the same account (e.g., health decline + usage decline): consolidate into a single notification noting both signals
• Persistent conditions (health below 65 for multiple days): notify once on first detection, then include in daily digest only

Suppression:

• Recipients can mute specific notification types (managed in notification preferences)
• CSMs on PTO: hold non-critical notifications until they return; route critical notifications to their backup
• Weekends and holidays: batch all non-immediate notifications for delivery Monday morning

Step 5: Log and Track

For each notification:

• Log: timestamp, event, recipient, channel, content
• Track: was it acknowledged? (For Slack: was it read? For email: was it opened? If platform supports this)
• Report: weekly notification volume per recipient, acknowledgement rate, most common event types

Output Format

Individual Slack notification:

🔴 Risk Alert: Acme Corp
Health score dropped to 58 (was 72 last week). Primary driver: support ticket volume 3x segment average.
Action: CSM review recommended today.
Owner: Jane Doe

Daily digest:

{
  "digest_date": "2026-03-10",
  "recipient": "jane.doe@company.com",
  "items": [
    { "account": "Acme Corp", "event": "health_below_65", "detail": "Score 58, declining. Driver: support", "urgency": "same_day" },
    { "account": "Beta Inc", "event": "milestone_missed", "detail": "Onboarding config 3 days overdue", "urgency": "this_week" },
    { "account": "Gamma Corp", "event": "expansion_signal", "detail": "Licence utilisation 91% for 30 days", "urgency": "this_week" }
  ],
  "summary": "1 urgent, 2 this week. 0 escalations pending."
}

Weekly notification report (for CS Ops):

{
  "week_of": "2026-03-10",
  "total_notifications_sent": 47,
  "by_channel": { "slack_immediate": 12, "slack_same_day": 18, "email_digest": 17 },
  "by_event_type": { "health_alerts": 8, "risk_signals": 5, "milestones": 6, "escalations": 3, "renewals": 4, "other": 21 },
  "suppressed": 6,
  "acknowledgement_rate": 0.82,
  "busiest_recipient": "jane.doe (14 notifications)",
  "fatigue_risk": ["jane.doe -- 14 notifications this week, up from 8 last week"]
}

Handoff to Human

This skill is fire-and-forget for the notification itself. Human decisions happen after delivery:

• CSM decides how to respond to each alert
• Manager decides whether to intervene or let the CSM handle it
• Leadership decides whether to redirect resources based on aggregate signals
• CS Ops tunes the notification rules based on the weekly report (too many? too few? wrong thresholds?)

Confidence and Limitations

• High confidence for event detection and notification delivery -- rule-based triggers with structured output from verified data sources
• High confidence for deduplication -- timestamp-based logic with defined windows
• Medium confidence for notification relevance -- the rules define when to notify, but not every notification warrants action. Some are informational. The recipient must triage
• Cannot assess whether a notification was acted on (only whether it was delivered and, if platform supports, read)
• Notification fatigue is the primary risk. If a CSM receives 15+ notifications per day, they will start ignoring all of them. The weekly report tracks volume per recipient specifically to detect this
• Cannot route to the right person if CRM ownership data is stale (e.g., account reassigned but CRM not updated)
• Daily digest consolidation may delay awareness of related signals that individually are not urgent but collectively signal a pattern

Dependencies

Required:

• Slack or email integration (notification delivery)
• Event streams from all pillar skills (notification sources)

Strongly recommended:

• All Book Intelligence skills (primary event sources)
• All Lifecycle Orchestration skills (workflow event sources)
• CRM API (account ownership for recipient routing)

Downstream consumers:

• CSMs, managers, and leadership (notification recipients)
• CS Ops (weekly notification report for rule tuning)

References

• references/notification-rules.md -- Complete rule table, deduplication logic, suppression policies, and digest formatting