Cross-Functional Interfaces
Prism Customer Success Handbook — Section 2.5
Why this page exists
Most cross-functional failures aren't disagreements — they're two teams each assuming the other owned something. This page defines who CS works with, what each interface owes in both directions, and who owns what. The ownership matrix at the end is the one-glance version.
Who's on the other side
| Function | Shape at Prism | CS's primary counterpart |
|---|---|---|
| Sales | AEs closing new business; a sales manager | The AE on each account; sales manager for handoff escalations |
| Solutions Engineering | One or two SEs, shared with the sales org | The SE scoped at handoff for Enterprise deals |
| Support | Small team working a tiered queue (P1–P4 per 1.6 Health Scoring Methodology) | Support lead |
| Product | PM(s) plus engineering | The PM |
| Director of CS | The CSM's manager | Escalation point and executive-level contact |
CS ↔ Sales
Sales owes CS:
- A complete handoff per 2.1 Sales → CS Handoff Standard, gated on the checklist — before closed-won
- Availability for the handoff meeting (MM/Enterprise)
- Engagement on expansion opportunities CS surfaces — pricing and contracting are Sales' work
- No commercial promises to existing accounts without CS in the loop
CS owes Sales:
- Kickoff confirmation, flagging any material gap between what was sold and what the customer describes — this is how demo-gap problems change future selling
- Onboarding outcome: did the account reach Value Realization, and if not, why
- Expansion signals, qualified and routed with context
- Churn notice with root cause, always
Friction rule: one follow-up to the AE on an incomplete handoff, then escalate to the sales manager. Never delay the customer to win the process argument (2.1 Sales → CS Handoff Standard).
CS ↔ Solutions Engineering
SE owes CS:
- Enterprise onboarding technical work: warehouse integrations, SSO, security review support, custom Portal auth
- A defined exit: SE involvement ends when the integration is live and stable, handing back to CSM + Support
CS owes SE:
- Early scoping — SE need identified at handoff (2.1 Sales → CS Handoff Standard), not discovered at day 20
- Coordination of customer-side technical contacts so the SE isn't chasing credentials
- Context: what was sold, what the success criteria are, where the account is sensitive
Boundary: the SE solves integration problems during onboarding; Support owns break-fix after go-live. An Enterprise account emailing the SE six months post-launch gets redirected to Support — kindly, but redirected.
CS ↔ Support
The visibility/notification split — the core of this interface:
- All tickets are visible to the CSM. Support history is part of the account record, reviewed before any customer call and during the weekly risk review. Pull for awareness.
- Notifications fire selectively. Push interrupts the CSM only when it warrants interruption: every P1; any P2 aging past its resolution target; any ticket, any severity, on an account in At-Risk state or inside a renewal window. Push for action.
Why not notify on everything: across a book this size, a ping for every P4 means dozens of interrupts a week, and within a month all of them are ignored — including the one that mattered. Selective notification is what keeps notification meaningful.
Support owes CS:
- The notification rules above
- Severity honestly assigned per the tier definitions in 1.6 Health Scoring Methodology — severity inflation to get attention breaks the whole signal chain
- A heads-up when a pattern emerges (three accounts hitting the same bug is product feedback, not three tickets)
CS owes Support:
- Account context on demand: renewal proximity, At-Risk state, stakeholder sensitivities — so Support can calibrate tone and urgency
- No queue-jumping: the CSM doesn't reprioritize tickets by asking favors. If a ticket genuinely needs elevation, that's an escalation (2.7 Escalation Management), made explicitly and logged
- Flagging when a "support ticket" is actually a relationship problem wearing a technical costume
CS ↔ Product
CS owes Product:
- Feedback and feature requests, categorized and routed per 2.8 Voice of Customer & Product Feedback — with account context (segment, ARR, whether it's blocking a renewal), not raw forwarding
- Churn root causes that implicate product gaps
- Access to customers for discovery, brokered so accounts aren't over-asked
Product owes CS:
- Advance notice of anything that lands on customers: deprecations, breaking changes, UI overhauls, pricing changes. This is the direction that usually goes undocumented and then burns the account team — a CSM learning about a deprecation from an angry customer has been structurally failed.
- Disposition on routed feedback: shipped, planned, declined, or parked — so CS can close the loop with the customer (2.8 Voice of Customer & Product Feedback)
- A heads-up when a change might destabilize accounts mid-renewal
CS ↔ Director of CS
The Director is not a pure people-manager at this company size — they're the escalation point and the second executive in the room when it matters.
The CSM escalates to the Director for:
- Commercial exceptions: non-standard terms, concessions, anything beyond the CSM's authority
- Executive-to-executive contact on Enterprise saves — when the customer's leadership needs to hear from ours
- Cross-functional conflicts that peer-level escalation didn't resolve
- Capacity signals: the three-week roll rule (2.4 Account Prioritization Framework) and coverage-reality findings (2.3 Operating Rhythm)
The Director owes the CSM:
- Availability for Enterprise EBRs and save situations
- Air cover on process disputes (handoff quality, notification discipline)
- A decision when asked for one — escalations that go in and never come back teach people to stop escalating
Ownership matrix
Owner = accountable and does or drives the work. Partners = actively help. Notify = kept informed, no action expected.
| Activity | Owner | Partners | Notify |
|---|---|---|---|
| Sales handoff | Sales (AE) | CSM | — |
| Kickoff | CSM | AE (optional), SE (Ent) | Sales |
| Onboarding | CSM | SE (Ent), Support | Sales (outcome) |
| Technical issue / ticket | Support | CSM (context) | CSM (per notification rules) |
| Enterprise integration | SE | CSM | Support |
| Health decline response | CSM | Support, Product (as relevant) | Director (if severe) |
| Escalation | CSM | Support/Product/SE (by type) | Director |
| Expansion opportunity | CSM (identify) → Sales (transact) | CSM | Director |
| Renewal | CSM | Sales (if terms change), Director (Ent saves) | Finance |
| Churn | CSM | Sales, Product | Director |
| Product feedback | CSM (route) | Product (disposition) | — |
| Security review (Ent) | SE | CSM | Director |
| Pricing/packaging change | Product | CS, Sales | All account-facing teams — in advance |
Two rows worth reading twice:
- Expansion splits ownership mid-process: CSM owns identifying and qualifying; Sales owns transacting. The handoff point is when the customer confirms interest in a commercial conversation.
- Renewal is CSM-owned even when Sales joins — Sales enters for pricing and contract changes, but the relationship, the value case, and the forecast are CS's.
Related pages
- 2.1 Sales → CS Handoff Standard — the Sales interface's entry gate
- 2.7 Escalation Management — how escalation actually runs
- 2.8 Voice of Customer & Product Feedback — mechanics of the Product interface
- 1.6 Health Scoring Methodology — severity tiers Support assigns
- 2.4 Account Prioritization Framework — what P1 means for the CSM's day
- 3.7 Renewal Motion — where Sales joins the renewal