Backstory 用 AI 三天完成客户分层，过去需五个团队一季

Haya Kamola on running an account tiering analysis with connectors, custom signals, and four rounds of iteration, live at SaaStr AI Day

Haya Kamola leads customer success at Backstory, and spent her career in sales and sales leadership before that. The project she walked through at SaaStr AI Day is one most go-to-market leaders have either run or will run: take the customer base, figure out which accounts deserve the team’s time, and redistribute against that.

The ask came down from the board with a short turnaround. 141 accounts. Define what the best customers look like, measure everyone against that, and produce a tiering framework the executive team can act on.

In a previous life, that was her team plus four others, working a full quarter. This version took three to four days.

What the session covered:

• Defining the “golden customer” from account team judgment before touching any data
• Building the signals they had never measured repeatably, including a five-level AI maturity score generated per account with a rationale
• Replacing a cross-functional data pull with four connectors and one CSV export from Salesforce
• Four iterations to narrow eight signals down to four scoring buckets, including one signal that was scoring backwards

1. The definition came before the data

Kamola started by getting the full account teams and senior leadership to describe what made one or two specific customers feel different from everyone else. Not longest-tenured, not largest.

What they landed on: customers who treated Backstory as a core part of their tech stack, built systems around the platform, planned five years out with it at the center, cared about the roadmap and wanted to inform it, and kept finding new use cases to push the product into.

Everything else got measured against that definition. Without it you end up scoring accounts against whatever fields happen to be populated in your CRM.

2. Most of the signals that mattered didn’t exist yet

Stripping the golden customers down produced two sets of characteristics.

Internal to the customer: go-to-market process maturity, tech stack mix, AI maturity and how fast they were moving up that curve, and whether they ran partner motions.

Specific to the relationship: deployment velocity, meaning they landed on a small use case and expanded across the stack fast. Executive visibility, meaning Backstory data was being used by executives to make decisions. And total addressable market within the account, plus remaining white space.

A lot of that was sitting in silos across various tools. Several of those signals had never been measured repeatably across the full customer base, so the gaps got filled before the analysis started.

AI maturity was her example. Backstory had an internal five-level framework covering culture, investment level, technology stack, talent, and willingness to engage on hard problems. Maintaining it meant asking account teams to categorize customers by hand, which she described as grueling.

So they built it as a signal that runs on its own: a prompt executed systematically against every account, pulling specific CRM fields, public company information like AI-forward product launches and new investments, and the account’s full conversation history. Emails, meetings, and Slack, assembled into a chronological record. The output is a maturity level for each account plus the reasoning behind it.

They did the same for tech stack mix, where pre-sales scorecards from two or three years ago were badly out of date and the current picture was sitting in conversations nobody had systematically read.

3. The cross-functional data pull became four connectors

This is the part that used to consume the quarter. A project owner going to product, BI, finance, and several other functions to collect TAM, health, revenue, renewal rates, delivery risks, feature requests, and adoption levels for every account.

Kamola didn’t ask anyone. Four connectors covered it:

• Amplitude for utilization and usage data
• Atlassian and Jira for years of logged customer feature requests and gaps
• Backstory’s own MCP for the full conversation and engagement history
• Slack, because Backstory runs an internal channel for every single customer, and those channels are where account strategy, next steps, and risks get called out first

The Slack input is the one most teams could copy tomorrow. An account team’s internal dialogue is usually the earliest and most candid read on a customer, and it almost never makes it into any structured system.

The only manual step in the workflow was exporting the customer list from Salesforce: account name, executive engagement level, predicted account health, the AI maturity signal, upcoming renewal date, and renewal ACV.

4. Order mattered, so the workflow got written down

The analysis runs as a defined sequence in Claude rather than a single prompt, using Cowork specifically because the steps needed to execute in order.

The sequence: ingest and normalize the CSV so accounts match across sources. Start with the conversation history, treated as the primary source of truth for recent engagement, risks raised, and opportunities surfaced. Then utilization data. Then growth potential, combining Salesforce data with public research. Backstory prices per seat off go-to-market headcount, so the size of a customer’s go-to-market org is the TAM indicator, and the gap between that and current seats is the white space. Then the Jira and gap boards. Then a reconciliation step. Then the scoring model.

A full run takes about 20 minutes, sometimes more.

5. Four iterations, and one signal was scoring backwards

The version she demoed was not the first one. It took three or four rounds of revalidating how much weight each data point deserved, and she was direct that this is where the human belongs in the workflow.

Two things came out of that iteration.

She started with about eight signals and ended at four scoring buckets: growth potential in the account, AI maturity and the velocity of AI change inside it, engagement level (both the customer’s perception of Backstory and who they were engaged with at what seniority), and current account health. Too many signals produced contradictions between signals, and the narrative got lost.

The more useful finding came out of reconciling adoption against feature requests. The first version treated a high volume of feature requests as negative, docking points on engagement and health on the assumption that a customer asking for a lot is a customer who isn’t happy. The data said the opposite. Their highest-adopting customers correlated strongly with feature request volume, and deep adoption plus a stream of AI-forward requests turned out to be a positive signal.

An error like that survives indefinitely in a hand-built scoring model, because nobody ever runs the model across the full base and checks who ended up where.

6. Tier D customers are where the value is

The output was four tiers.

• Tier A: 8 accounts. Customers they believe can grow more than 10x in two to three years, scoring high across all four categories.
• Tier B: 21 accounts. Same 10x potential on a longer time horizon, with a separate playbook.
• Tier C. Accounts at a genuine juncture. They either come to see Backstory as core to their stack, or they don’t mature fast enough to keep up with where Backstory is going and drop.
• Tier D. The customers where the honest conclusion was that they may not be with the company in a couple of years, either because Backstory has evolved and they haven’t, or because the gaps have been insurmountable for years. The decision there is whether to cut losses and service them differently.

Plenty of tiering projects produce an A list and stop there. Kamola named the value of the bottom directly: it forced the company to look at real data and decide whether those customers were ones they believed would grow and stay.