Key Takeaways
- Most Customer Success work is reactive because the data is fragmented. Usage lives in product analytics, sentiment lives in Gmail and Slack, payment health lives in Stripe, support tickets live in Zendesk or Pylon, and the QBR deck lives nowhere until the night before. The CSM finds out a customer is unhappy at the meeting. By then the decision is already made.
- Customer Success is not Customer Support. Support is reactive and inbound: a ticket is open, an answer is needed. Success is proactive and outbound: a renewal is in 90 days, a champion just left, a usage curve dropped 40 percent two weeks ago and nobody told the CSM. The job is to spot the pattern before the customer puts it in writing.
- An AI coworker reads every signal every week. Viktor watches usage in Mixpanel or PostHog, payment health in Stripe, sentiment in Gmail and Slack, ticket volume in Zendesk, and feature adoption in your product database. It assembles a per-account health view that updates on its own and posts it where the CSM already works.
- The playbook is the easy part once the signal is real. With a clear health view, the CSM walks into a QBR with a one-page brief, a draft expansion proposal, a list of stuck workflows the customer never reported, and three specific moves to make this quarter.
- The compounding gain is in renewals you keep and expansions you would have missed. A team of four CSMs covering 200 accounts will, on average, miss two churn signals and three expansion signals per quarter that the data was already telling them. Closing that gap is the entire point.
The short version
Customer Success teams spend their week on the wrong work. They prep for the QBR that's tomorrow. They jump on the call about the integration that's broken. They pull the usage report that the AE asked for. The strategic work, the kind that keeps a renewal alive, is supposed to happen in the gaps. The gaps don't exist.
The signals that predict churn or expansion are already in your stack. Login frequency dropped. Three of the five power users have stopped opening the product. The champion is now CC'd on every email instead of writing them. Support tickets shifted from feature questions to "is this still working?" The Stripe payment was 11 days late, which has never happened before.
A CSM cannot watch all of those signals across 50 accounts every week. An AI coworker can. Viktor is an AI coworker that lives in Slack, connects to 3,200+ tools through real OAuth, and assembles a per-account health view that runs on a schedule. Every Monday, every CSM gets the brief that took someone four hours to make and was usually skipped. The brief lists the accounts at risk, the accounts ready to expand, and the specific signal that triggered each call.
This is the job a CSM was hired to do. The data work is what gets in the way. Hand the data work to the coworker.
Why Customer Success is structurally harder than Customer Support
A support ticket has a clear shape. A customer has a problem, the problem is in writing, the resolution closes the ticket. The metric is straightforward: time to resolution, CSAT, ticket volume per agent.
Customer Success has none of that. The job is to keep an account alive and growing for years, and the work is invisible until the renewal hits. The customer rarely tells you they are about to leave. They get quiet. The champion changes jobs. Usage softens. The exec sponsor stops replying. Three months later, you get a polite email asking for the offboarding checklist.
The data exists. It is just spread across:
- The product database (usage, feature adoption, login frequency)
- The product analytics tool (Mixpanel, PostHog, Amplitude)
- Stripe (payment health, plan history, MRR changes)
- The CRM (HubSpot, Salesforce, Attio for account fields)
- The support tool (Zendesk, Pylon, Intercom for ticket volume and theme)
- Email (Gmail, Outlook for sentiment and engagement)
- Slack (shared channels, internal threads, mentions)
- The contract document (SignWell, DocuSign for renewal date)
A CSM with 50 accounts cannot pull and read all of that every week. So they don't. They pull it for the QBR, which means the data tells them what already happened. The work that matters, the call you should have made six weeks ago, never happens because the signal never surfaced.
This is the gap. AI is good at this gap.
What an AI coworker actually does for a CSM
Viktor is not a dashboard. Dashboards exist already and they are not solving the problem, because reading a dashboard is itself work the CSM doesn't have time for. Viktor is a coworker that does the reading and posts the conclusion.
Here is the shape of the work, in plain English.
Every Monday at 8 AM, Viktor pulls the last 30 days of usage from your product database (or PostHog, Mixpanel, Amplitude), payment events from Stripe, ticket data from Zendesk or Pylon, last-touch data from Gmail and HubSpot, and Slack channel activity from any shared channels. It compares each account to its own baseline (not a generic threshold) and posts a per-CSM digest in Slack listing the five accounts that need attention this week.
Every Friday at 4 PM, Viktor produces a one-page Friday brief per CSM listing what happened on each account that week, what the CSM did, and what they didn't get to. The brief is a memory aid, not a manager report. It is for the CSM, by the CSM's coworker.
Two weeks before any QBR, Viktor drafts the QBR deck and the talking points. It pulls the agreed success metrics from the contract or kickoff doc, populates them with the actual numbers, identifies the three things to celebrate and the three risks to address, and proposes the expansion path if the data supports one. The CSM reviews and adjusts. The four-hour Sunday-night QBR scramble disappears.
On any payment event (failed charge, downgrade, plan change, late payment), Viktor posts immediately in the CSM's channel with full context: who is the account, what just happened in Stripe, what does usage look like, what is the renewal date, who is the champion, when did they last engage, what is the recommended next move.
Whenever a champion's email signature changes (a sign they switched jobs or roles), Viktor flags it in Slack with a draft outreach to the new contact and a note to the CSM about the original champion, including their LinkedIn if they show a new role.
This is the kind of work a CSM was supposed to be doing and never had the hours to do. Hand it to the coworker. Get the hours back.
A real workflow: the weekly health digest
Here is the structure of a weekly health digest cron, simplified to the shape of the prompt. You set this up once. It runs every Monday at 8 AM forever.
@Viktor every Monday at 08:00 Europe/Amsterdam:
For every customer account where I am the assigned CSM (look in HubSpot field
"customer_success_owner"), pull these signals for the last 30 days vs the prior
30 days:
1. Active users count (from PostHog event "user_signed_in"), flag if down >25%
2. Total events count (from PostHog all events), flag if down >40%
3. Top 5 power users by event count, flag if any of them are now <50% their prior usage
4. Stripe payment events, flag any failed charges, late payments (>7 days),
or plan downgrades
5. Pylon ticket count and dominant theme, flag if ticket count up >50% or
theme shifted from "feature questions" to "broken"
6. Last meaningful email reply from any contact at the account (Gmail), flag
if >21 days since any reply
Group flags by account. Rank by severity (downgrade > 40% usage drop > champion
silence > ticket spike). For each flagged account, include: account name,
contract value (Stripe MRR), renewal date (HubSpot field "renewal_date"),
champion name and last contact date, the specific signal that fired, and a
proposed next move (call, email, internal sync).
Post the brief as a single message in #cs-mondays. Subject:
"CS Monday Brief, {{ today }}, {{ count }} accounts need a look this week."That is the entire setup. Once it runs, every CSM walks into Monday already knowing where to spend the week.
A real workflow: the QBR draft
Two weeks before any QBR, the customer's renewal date is in HubSpot, and Viktor is watching that field. When the date is exactly 14 days out, this fires:
@Viktor for {{ account_name }} (HubSpot ID {{ account_id }}), produce a QBR
draft deck:
1. Pull the success metrics defined at kickoff (look in Notion page for this
account, section "Success Criteria"). If none documented, use Viktor's
default CS metric set: active users, feature adoption, time-to-value,
support ticket volume, NPS if collected.
2. Populate each metric with the actual number from the last quarter (Q ending
{{ today - 14 days }}) and the change vs the prior quarter.
3. Identify the three biggest wins (largest positive deltas) and the three
biggest risks (largest negative deltas or red-flag signals).
4. Pull the last three customer-facing emails from this account (Gmail) and
summarize the sentiment. Quote the most signal-rich line from each.
5. Look at the customer's plan and usage. If they are using >70% of any plan
limit (seats, tasks, integrations, message volume), draft an expansion
proposal as Slide 8.
6. Look at any features they are NOT using that customers in the same segment
typically use heavily. Propose two of those as Slide 9 ("opportunities").
7. Output the deck as a Google Slides file in the shared "Customer QBRs" folder.
Format: 10 slides max. Notes section per slide with talking points.
8. Post a link in #cs-{{ account_slug }} with the draft and a checklist of
five things to verify before the meeting.The CSM reviews this draft with their morning coffee on the Monday two weeks before the QBR. Two hours of work becomes 15 minutes of review. The QBR that used to be a survival exercise becomes a strategic meeting.
A real workflow: the champion-leaving alarm
The single most reliable churn signal in B2B SaaS is the champion changing roles or leaving the company. It is also the one nobody catches until it's too late, because LinkedIn job changes do not page anyone.
@Viktor every weekday at 09:00:
For every active customer account, list the named champion (HubSpot field
"primary_champion_email"). For each champion:
1. Pull their LinkedIn profile (last updated within 30 days).
2. Compare current title and company to what we have on file.
3. If different, flag as "champion change."
For each champion-change flag, post in the assigned CSM's DM:
- Account name and contract value
- Renewal date
- Original champion (name, old title, where they went)
- Likely replacement (the person who has been most active in the account in
the last 60 days, pulled from Gmail thread participation and HubSpot
contact engagement)
- Draft outreach email (140 words max) introducing yourself to the new
champion, referencing the work the original champion led, and proposing
a 30-minute call to align on the next quarter
- A second draft (80 words) congratulating the original champion on the new
role, leaving the relationship warm
Both drafts wait for the CSM to send. Viktor does not auto-send.The first time this fires, you will catch a renewal you would have lost. After that, the value is obvious.
The accounts you would have missed: the expansion side
Customer Success that only watches risk is leaving half the value on the table. The same data that tells you which accounts are at risk also tells you which ones are about to expand.
The signal patterns that precede expansion:
- Usage growing faster than seat count. The account is hitting limits. They are absorbing the cost in workarounds. Surface this and propose the bigger plan before they ask.
- A power user pattern is forming in a new department. Marketing was the original buyer; now Engineering or Customer Support is using the product daily. Cross-sell into the new function.
- Ticket volume drops while usage stays flat or grows. They learned the product. They're past the support phase. Now is the time to introduce advanced workflows.
- A new senior contact appears in email threads. Someone at a higher level is being included. The economic buyer just got pulled in. This is the moment to propose the bigger commitment.
A weekly expansion-signals digest, dropped into a different channel from the risk digest, gives the CSM and AE pair a sharp view of where to push this quarter. The same Viktor cron pattern, different prompt.
@Viktor every Monday at 09:00 in #cs-expansion:
For every customer account in HubSpot pipeline stage "Active":
- Pull current seat usage vs plan limit. Flag if >80%.
- Pull total event volume last 30 days vs 90 days ago. Flag if up >40%.
- Pull top 10 most-active users this month. Flag any new departments
represented (compare email domain pattern and HubSpot contact dept tag).
- Pull last 30 days of Pylon tickets. Flag if ticket count down >30% AND
active users up, this is "they got past support."
- Pull last 30 days of Gmail thread participants on this account. Flag any
new senior contacts (VP+ in title).
Rank by expansion-likelihood score. Post top 10 with: account name, signal
that fired, suggested next move, and a draft email to the champion proposing
the conversation.Most CS teams have never measured how much expansion they leave on the table. The first month this runs you will see it.
Where to draw the line: the Customer Support boundary
This post is about Customer Success, not Customer Support, and the distinction is real. Support is a different function with a different rhythm. We wrote about that workflow separately in Your Support Queue Doesn't Need More People. It Needs Context..
Practically: support is reactive ticket triage, success is proactive account ownership. Both can use Viktor, but the workflows are different. Don't mix them in one Slack channel and don't ask one CSM to own both. The signals overlap, but the timing and the intervention are different.
If your team currently has CSMs answering support tickets because nobody else is, that is a separate org problem and the right answer is to fix the staffing, not to ask the CSM to context-switch faster. Viktor can help with the staffing case (it makes one support agent cover 4x the tickets) but it cannot make a CSM do two jobs well.
Safety and approval
Customer Success is high-trust work. A wrong email to a champion can blow a renewal. A premature expansion pitch can sour the relationship. Treat AI assistance the same way you would treat a junior CSM: helpful, fast, and reviewed before anything customer-facing goes out.
Hard rules we recommend for the Viktor setup on a CS team:
- No customer-facing email auto-sends. Drafts only. CSM reviews and clicks send. This is non-negotiable for the first six months.
- No CRM writes without confirmation. If Viktor identifies a stage change or pulls in a new contact, post the proposed change in Slack with a one-click "yes" button. Don't update the CRM silently.
- Internal Slack posts and Notion drafts are fine to auto-create. Internal artifacts with no external blast radius. Auto-approve.
- Quarterly review of every cron. Are the signals still meaningful? Did a baseline drift? Is anything firing too often or not enough? CS data shifts; the prompts should shift with it.
The same review-first principle that prevents the Chevrolet $1 Tahoe class of failure (an AI taking action without a human checking) applies here. Internal artifacts, automatic. Anything customer-facing, drafted and reviewed.
What this looks like at three account scales
A CSM covering 20 accounts. Probably already has the high-touch attention to spot risks manually. Viktor pays back the time on QBR prep and the Friday brief. Expansion-signal monitoring catches the one or two cases per quarter the CSM would have missed.
A CSM covering 50 accounts. This is the breakpoint. At 50 accounts, the manual signal-watching breaks down. Viktor here is the difference between a CS function that scales linearly with headcount and one that scales sub-linearly. Expect to catch 2-3 churn signals per quarter that would have been missed.
A CSM covering 100+ accounts (long-tail or PLG). Manual attention per account is below threshold. Viktor is the only way the function works at all. Risk and expansion digests become the operating cadence. The CSM's job becomes triage, response, and relationship rather than data assembly.
Frequently Asked Questions
Is Viktor a customer success platform like Gainsight or ChurnZero?
No. Gainsight and ChurnZero are dedicated CS platforms with their own data model, scoring engine, and dashboards. Viktor is an AI coworker that connects to whatever tools you already use (HubSpot, Stripe, Pylon, PostHog, etc.) and produces deliverables in Slack. If you have Gainsight, Viktor sits alongside it and does the cross-tool work and drafting that Gainsight does not. If you don't, Viktor covers the same job-to-be-done at a different shape.
Do we need a separate CS data warehouse for this to work?
No. Viktor pulls live from each tool through real OAuth. If you already have a warehouse (Snowflake, BigQuery), Viktor can read from it instead, which is faster for very large accounts. For most teams under 1,000 customers, direct API pulls are fine.
How does Viktor know which signals matter for our specific business?
You tell it once, in the cron prompt. The signals that matter for a Series B SaaS startup are different from the signals for an enterprise infrastructure company. The prompts above are starting points; you adapt the thresholds to your retention curve. Viktor remembers what worked from previous brief revisions and gets sharper.
What about quiet accounts that look healthy on data but the relationship is cold?
The Friday brief catches this. If a CSM has not been in the account in three weeks, Viktor flags it regardless of usage. Healthy data plus no human contact is a real risk pattern.
Can our AEs see the same expansion-signal feed?
Yes. Most CS-AE pairs run a shared expansion channel and Viktor posts to both. The AE owns the commercial conversation; the CSM owns the relationship. Same data, two perspectives.
Does this replace the QBR meeting itself?
No. It replaces the four hours of prep that used to happen the night before, which is what was making the meeting worse. The meeting itself becomes more strategic because both sides walk in with the same data and the same agreed-on view of where the account is.
How long until we see the first miss caught?
Usually within the first three weeks. Most CS teams have at least one account where a signal has been firing quietly for a month. The first time the digest surfaces it, the CSM either makes a call that saves the renewal, or learns something they should have learned earlier. Either way, the cron is paying back.
