Customer success teams can run onboarding, health scores and renewals in Salesforce when three things are in place. First, a named CSM owns each account. Second, a health score with visible inputs sits on the account record. Third, renewals are opportunities created from contract dates. Product usage arrives as summarized fields from your warehouse or Data 360. Build that core before adding playbooks or AI.
What does customer success need from Salesforce that sales and support do not?
CS needs a view of the whole customer after the sale: what they bought, whether they use it, how the relationship feels, and when it renews. Sales tracks deals and support tracks cases, but neither answers whether an account will stay.
That gap is why many CS leaders end up in spreadsheets. The data exists, but it is scattered across opportunities, cases, the billing system and the product database. A CS design in Salesforce mostly rearranges existing records around the account, rather than adding a new system.
- Sales wants pipeline, stages and close dates. CS wants adoption, risk and renewal timing on the same account.
- Support works case by case. CS needs case trends per account, such as volume, severity and repeat issues.
- Leadership wants gross and net retention. That requires renewals and churn recorded as data, not as missing deals.
How should onboarding be modeled in Salesforce?
Treat onboarding as a structured plan attached to the account, generated when a deal closes. Use standard features where they fit, and build a small custom object only for what they cannot hold.
Be careful with names here. Salesforce sells its own support tiers as Success Plans, so that term in Help refers to Salesforce's service to you. It is not an object for your CSMs to use.
For the plan itself, Sales Cloud now includes sales action plans, built from templates of tasks and events. Help lists them for Enterprise, Performance and Unlimited editions, attachable to accounts, contracts and opportunities. Sales Account Plans add objectives, metrics and a SWOT view for strategic accounts. Confirm both are switched on and licensed in your org with your Salesforce account team.
Many teams still add a custom onboarding object. It typically holds go-live target, kickoff date, implementation stage, blockers and sign-off. A flow creates it on closed-won, along with the right action plan template for the product sold. One example from our own work: a compliance-software company backed by private equity, migrating off HubSpot, added a custom Product Instance object to Sales Cloud. The object supports the company's post-sale customer success work.
Who owns the account once the customer signs?
Pick one owner model and write it down. Either the CSM becomes account owner, or the account executive stays owner and the CSM is named separately.
Changing the Account Owner field affects sharing, territory reports and commission logic, so many companies leave it with sales. In that case add a CSM lookup field on the account for reporting and routing. Account Teams, available in Enterprise edition and above, add named roles alongside it.
Account team roles are a picklist you define, and opportunity teams share the same list. Useful roles for CS include CSM, executive sponsor, implementation lead and support contact. A single CSM field is still worth keeping, because filtering a dashboard by one lookup is far simpler than by team membership.
What should go into a customer health score?
A health score should combine a few inputs you trust, each refreshed on a known schedule. If a CSM cannot explain why an account turned red, the score will be ignored.
| Input | Source system | How often it updates | Pitfalls |
|---|---|---|---|
| Product usage: active users, seat use, key feature adoption | Product database or analytics tool, through a warehouse | Daily or weekly batch | Raw events flood storage; agree on what counts as active first |
| Support cases: volume, severity, open escalations | Service Cloud or another help desk | As cases change | A busy account may be engaged, not unhappy; weigh severity over count |
| NPS or CSAT responses | Salesforce Feedback Management or a survey tool | Per survey cycle or after closed cases | Low response rates; one detractor can swing a small account |
| Engagement: meetings, last contact, sponsor activity | Activities logged in Salesforce, or synced from email and calendar | As activity is logged | Patchy logging makes quiet accounts look at risk |
| Billing status: overdue invoices, failed payments, downgrades | Billing or finance system | Daily or on each billing event | Late payment can be process noise in the customer's finance team |
| CSM judgment | A picklist and comment set by the CSM | Reviewed on a set cadence | Goes stale unless a report flags old values |
Store each input as its own field on the account, then compute the overall score from those fields. That way a red score always shows which component caused it.
Where should the health score be calculated?
Calculate it where the inputs already live. For most companies that is the data warehouse, with Salesforce receiving the components and the result.
When usage, billing and support data already share a warehouse, scoring there keeps the logic in versioned, testable SQL. A scheduled sync then writes the fields to the account. If most inputs are already in Salesforce, a formula or a scheduled flow can calculate the score inside the org.
Data 360, formerly Data Cloud, offers calculated insights that compute metrics across unified data on a set schedule. It suits teams that also want usage segments, automation or AI grounding from the same data. Consumption pricing and packaging vary. Check them with your Salesforce account team before adopting it for scoring alone.
How should product usage data reach Salesforce?
Send account-level summaries on a schedule, not individual product events. CSMs act on trends such as falling active users, not on raw clicks.
The usual route is a reverse sync from the warehouse into account fields or a custom usage object. Use a custom object when one customer runs several workspaces or products. Key everything on a stable customer ID held in both systems. Matching on company name always breaks eventually.
How should renewals and expansion be handled?
Model renewals as opportunities with their own record type, created automatically from contract dates. Route expansion through a defined handoff so sales and CS do not argue over credit.
Standard Salesforce does not create renewal opportunities from contracts on its own. Salesforce CPQ can, through the Renewal Forecast setting on a contract, and Revenue Cloud has its own renewal handling. Without either, a scheduled flow can create the renewal from the contract end date. When we configured Sales Cloud for an IT and cybersecurity firm operating in several regions, renewal alerts fired automatically at 60 and 30 days.
Give renewals their own stages, such as confirm usage, propose terms, negotiate and signed. Track the renewal amount against the expiring amount, so the forecast shows expected contraction. Our guide on why forecasts drift covers forecast categories in more depth.
For expansion, agree on who creates the opportunity and when. A common rule: CS logs the signal, sales owns the opportunity, and the CSM sits on the opportunity team. Then commission disputes rest on a written rule rather than memory.
How do you track QBRs, executive sponsors and churn reasons?
Use standard records with a few required fields. QBRs become events or a small custom object, sponsors become contact roles, and churn reasons become a required picklist on lost renewals.
- QBRs: log each review with date, attendees, outcomes and next review date. A report of accounts with no review recently becomes a coverage list.
- Executive sponsors: mark them through account team roles on your side and contact roles or a flag on theirs. Alert the CSM when a sponsor contact is deactivated.
- Churn and contraction: require a primary reason and a short comment when a renewal closes lost or smaller. Keep the picklist short so answers stay comparable.
- Saves: record accounts that were at risk and renewed, with what changed. These teach more than the losses.
When does a dedicated customer success platform make more sense?
Choose a dedicated CS platform integrated with Salesforce when playbook automation, complex scoring and CSM workflow outgrow what your admin team can maintain. Build natively when the team is small and the motions are simple.
Signs a dedicated platform fits: high account counts per CSM, digital-touch programs for the long tail, and heavy use of in-app or lifecycle signals. Signs native fits: a few CSMs, renewals already in Salesforce, and leaders who want one system. Either way, keep renewals and account ownership in Salesforce, so finance and sales see the same numbers.
Which reports do customer success leaders need?
Start with a handful of reports tied to decisions: coverage, risk, renewals and outcomes. Add more only after these are trusted.
- Renewals due by quarter, with health score and forecast category.
- At-risk accounts by CSM, sorted by renewal date and contract value.
- Onboarding in progress, with stalled plans and overdue tasks.
- Gross and net retention by segment, built from closed renewal and expansion opportunities.
- Churn reasons over time, by segment and product.
- Accounts with no QBR or sponsor contact in the agreed window.
Our article on dashboards leadership will use covers layout and adoption of these views.
What belongs in a customer success phase one?
Phase one should give every account a clear owner, a basic health view and forecastable renewals. Playbooks, AI and a platform decision can follow once that base is stable.
- A CSM field on the account and agreed account team roles.
- A renewal record type with stages, created automatically from contract dates.
- Required churn and contraction reasons on lost renewals.
- Onboarding created from closed-won, using action plan templates or a small custom object.
- Four or five health components synced from the warehouse, with a visible overall score.
- The renewal and at-risk reports above, reviewed in a weekly CS meeting.
Ownership after launch matters as much as the build. At that IT and cybersecurity firm, the project closed with its customer-success manager ready to administer the org after handover.
