A&A INSIGHTS
Expansion signals: pick which self-serve users to pitch by usage change
Pick which self-serve users get your limited proposal time by traces that responsibility changed, not usage volume: three tests, a four-column sheet, no-contact rules.
日本語で読む
THE STARTING POINT
Choose who gets an individual proposal by traces that responsibility scope changed on the customer's side, not by descending usage volume. Accept only changes you can decide as a before-and-after difference from your own records, and write the no-contact conditions on the same sheet.
The answer: pick by traces that responsibility changed, not by usage rank
A&A perspective
Choose who gets an individual proposal by traces that the responsibility scope changed on the customer's side, not by descending usage volume. Concretely: a second person started working on something one person used to handle alone, the kinds of objects being handled increased, or the person responsible was replaced. These are accounts where such a change already appears in your own records. Usage volume indicates that the current plan and the current responsibility scope fit each other; it is not a reason to propose anything.
A&A perspective
Once you have defined your signals, write the no-contact conditions on the same sheet. You do not reach out even when a signal fires if a route already exists for the customer to contact you, if they are carrying an unresolved defect, or if the change originated in your own outreach. If you define only the conditions for making contact, your judgement stalls in the week when several signals fire at once.
From the sources
The Lovable case-study page Clay publishes describes, as what comes next for its self-serve user base, "identifying expansion signals, scoring for enterprise readiness, and routing high-potential accounts to sales" - naming the identification of signals, the scoring of readiness and the routing to sales as three separate steps. Note, however, that the same sentence says "plans to use": this is not an operation already in place.
Sorting by volume puts the accounts that are already fine at the top
A&A perspective
Descending usage volume tells you that the current arrangement is working for that account. They use a lot because what they are allowed to do and what they need to do coincide. What a proposal requires is a reason on the customer's side - something happened that the current arrangement does not cover - and a state of coincidence is not that reason.
A&A perspective
When volume keeps growing inside the same scope, it eventually hits a plan ceiling or a limit. At that point the customer contacts you. In other words, growth in volume is the kind of change that turns itself into an inbound message if you leave it alone. The design on the receiving side - splitting arriving inquiries between self-serve and an individual proposal - is covered in "Don't Route Every AI SaaS Inquiry to a Sales Call: Separating Self-Serve From Tailored Proposals". This article runs in the opposite direction: deciding, from your side, which accounts that have sent you nothing deserve your time.
A&A perspective
What does not turn into an inbound message is a change of responsibility scope. A second person starts touching the same objects; the kinds of objects widen; the responsible person is handed over. Each of these is, from the customer's point of view, an event outside their current way of working, and they do not know that your product has anything for it. So they file no request and settle for a manual workaround.
| Candidate signal | Result of the three tests | Verdict |
|---|---|---|
| A high number of runs per month | A level, not a change. Visible in records, but indicates no change of responsibility | Reject. Volume rephrased; not a reason to propose anything |
| A second or later person started working on the same objects | A change. Decidable from invitation and first-login records. Work moved from one person to several | Accept. A good candidate for one of your first three |
| A kind of object never seen before appeared in the input (a new department, product class or language) | A change. Decidable from input records. The scope of objects has widened | Accept |
| They hit a plan ceiling or a limit | A change, but hitting it gives the customer a route to contact you | Reject. No need to pick them from your side; handle it in receiving-side routing |
| A dormant object resumed under a different person's name | A change. Decidable from the name and resumption date in records. A handover has happened | Accept |
| A previously unused feature was used for the first time (right after our announcement) | A change, but it originated in our own outreach, so it is not a change on the customer's side | Reject. Record days since the announcement and exclude it mechanically |
| Inquiries shifted from how to use it to how to roll it out internally | A change. Decidable from the wording of inquiries. More people are now responsible for adoption | Accept |
Source: Clay's case study separates researching from deciding to reach out
From the sources
The same Lovable page states, about its recruiting workflow, that "The human is always in the loop. Recruiters review Clay's research and make every outreach decision themselves." The split is explicit: the system does the research, and the person decides whether to make contact.
From the sources
On the same page, AI Ops Engineer Ludvig Widmark says "When I spot a bottleneck, I go into Clay, experiment a bit, and see if it works", and elsewhere "What I love about Clay is how easily you can test something new at a small scale, validate what works, then scale it as big as you want." The signal design is described not as a one-off configuration but as a small test run each time a bottleneck is spotted.
A&A perspective
For a solo or small company, the important thing about this split is its cost structure. The step that gathers records and lists the accounts whose signal fired costs almost nothing to run each week once it is written. The judgement about whether to make contact costs something every single time. While you have only a few dozen customers, there is no mechanism for recovering the trust lost by one badly aimed individual proposal. So automate up to the listing, and keep the decision to send in your own hands.
Source: brand.ai's outcomes are written as objects per person and time to get started, not volume
From the sources
The brand.ai case-study page Anthropic publishes describes the outcomes as "Enables one copywriter to manage 600 pieces of content", "Accelerates agency onboarding from months to days" and "Reduces brand guideline creation and rollout from 24 months to just days". The page lists Industry: Professional services and Company size: Small. All of these figures are self-reported by brand.ai and its customers; no population, period, definition or independent verification is given.
From the sources
On the same page, co-founder Chelsey Susin Kantor says "Teams end up with a culture of 'it's good enough' because they simply don't have the time to do better. They're trapped in a cycle of managing brand compliance instead of growing their brands."
A&A perspective
Put those two together and you get a hint about how to build signals. The outcomes brand.ai lists are not written as usage volume; they are written as the number of objects one person can cover and the time it takes a newly involved party to get going. If value shows up in that shape, then the observable traces of a customer's situation changing should have the same shape - objects per person moved, a new party arrived. That inference is ours; neither page says it. Kantor's remark is also the vendor's view of a customer's difficulty, and it does not say "therefore customers file no requests". Still, a team that has settled for "good enough" because it has no time is unlikely to go out of its way to send you a feature request, and the conclusion that a wait-for-inbound design cannot reach this group is reasoning on our side.
Three tests for a candidate signal: a change, visible in your own records, about responsibility
A&A perspective
Test one: can you write it as a change? "500 runs a month" is a level. "A second person joined an account that one person used alone" is a change. Wherever you put a threshold on a level, everyone above it looks like a signal the moment you set it. Write signals as a before-and-after difference.
A&A perspective
Test two: can you confirm it from your own records alone? Anything you cannot establish without asking the customer is not a signal; it is an interview question. A signal has to be decidable from records you already hold - invitations and first logins, the kinds of objects appearing in the input, the wording of support messages. Otherwise it will not run every week.
A&A perspective
Test three: does it indicate a change of responsibility? "The same person did more of the same kind of work" is volume rephrased. Accept a signal only when one of two things moved: who is responsible, or what kinds of objects are in scope.
A&A perspective
Keep only the candidates that pass all three. Starting with about three is better. The more signals you have, the more fire each week, and a few hours a week cannot process them - at which point you go back to serving whoever shouts loudest.
The four columns on one sheet, and the no-contact conditions
A&A perspective
The four columns are these. One: the signal, written as a before-and-after difference. Two: the record you look at - which table, which screen, which wording. Three: who makes first contact and when, written as a named person and a number of days after the signal fires. Four: the no-contact conditions. Do not start running the sheet with the fourth column empty.
A&A perspective
As default values for the no-contact conditions, here is what we would set. If you have sent that account an individual message within the last 30 days, wait for the next signal. If they are carrying an unresolved defect or an unanswered inquiry, fix it first and do not sell. If the change originated in your own announcement, campaign or hands-on configuration, it is a signal you manufactured, so do not count it. If they are on a free tier or still evaluating and have not reached first value, confirm that arrival first. If they merely hit a plan ceiling or a limit, do not pick them from your side, because a route already exists for them to contact you. Set the day counts and the lines to your own cycle; the values listed here are an illustration with stated assumptions.
A&A perspective
The fourth column earns its place when signals overlap. It is not unusual for two or three signals to fire on the same account at once. If the no-contact conditions are already written, you can decide mechanically to pass this time even when they overlap. The overall arrangement from acquisition through retention is set out in "AI-native GTM: a practical guide for solo founders and small teams".
Run the tests and two kinds of candidate drop out: volume rephrased, and signals you made yourself
A&A perspective
The comparison table in this article lists seven candidates. Two kinds drop out. The first is volume rephrased: "a high number of runs" fails test one, because it is a level and not a change.
A&A perspective
The second is a signal you manufactured. "Used a feature for the first time" looks like a good change, but if you sent an announcement just before, the origin is on your side. It is not evidence that the customer's situation changed, so exclude it before test three. Keeping "days since our announcement" in your records makes that exclusion mechanical.
A&A perspective
What remains is four: a second person joined, the kinds of objects increased, the responsible person was replaced, and the content of inquiries shifted from how to use it to how to roll it out internally. Each is a trace that who is responsible has moved, and none of them has a route by which the customer would contact you.
Hypothetical: 60 paid accounts, three hours a week available for sales
Hypothetical example
The following is a hypothetical example with stated assumptions. It is not our own result and not a customer's result. The assumptions: an AI service run by one person, 60 paid accounts, three hours a week available for sales, and three signals (a second person joining, an increase in the kinds of objects, a handover of the responsible person).
Hypothetical example
Looking at the top five by descending usage, four were single-user accounts that had been running for more than twelve months. These are accounts using the product steadily over a long period, and the only reason to change the arrangement sits on our side.
Hypothetical example
Sorted by signal, three fired that week. One of them had received an individual message from us 20 days earlier, matched a no-contact condition, and was passed over. One was carrying an unresolved defect and was also passed over. For the one that remained, one of the three hours went into preparing a proposal. Whether that proposal was accepted is not something this example decides: what this article designs is the choice of recipient, and whether a proposal lands is a separate variable.
A&A perspective
What to notice in this example is that introducing signals reduces the number of contacts. Two of the three were passed over. A signal sheet is not a mechanism for making more contact; it is a mechanism for changing who receives it. If you want the count to go up, the lever is the hours available for sales, not the number of signals. How to protect those hours while delivery is underway is covered in "Turn solo-founder sales into a weekly system: keep buyer-specific reasoning alive while shipping".
When this way of deciding does not hold, and the first step today
A&A perspective
While you have only a few dozen users, reading each account one by one can be faster than defining signals. As a rough line: if you can read the last 30 days of activity across every account within an hour, read it instead of building a signal sheet. Writing down one line per thing you noticed carries more information at this stage. Move to signals at the point where you can no longer read it all. This line does not come from the sources; it is our own practical hypothesis.
A&A perspective
A signal cannot fire unless the records exist. To decide that a second person joined, you need participants and join dates recorded per account. If you do not have that, adding the record comes before defining the signal. Most cases of "we built the sheet and it fires zero times a week" are this.
From the sources
Check the premises on the source side as well. Lovable is a product of a scale where "Over 40 million projects have been built on the platform since launch", so there is a population large enough to treat signals statistically. And what that page says about expansion signals is "plans to use" - it is not presented as an operating record.
A&A perspective
Neither source states that choosing recipients by signal increases additional orders. Do not infer improvements in close rate, expansion revenue or churn from this article. It is not a record of work we have performed either.
A&A perspective
The first step today is to narrow to three signals and count, in the last 90 days of records, how many times each one fired. Do not make contact yet. If more fire than you can process in a week, the signals are too broad. If zero fire, either the records are missing or the change is not actually happening, and you should establish which before anything else. If the choice of recipient itself is what you cannot settle, a free initial consultation can work through the candidate signals with you.
Choose who gets an individual proposal by traces that responsibility changed, not by usage rank. Write each signal as a before-and-after difference, make it decidable from your own records alone, and accept it only when either who is responsible or what is in scope has moved. Then write the no-contact conditions on the same sheet. Introducing signals reduces the number of contacts you make. The hours you get back go to the accounts where something happened that the current arrangement does not cover.
Sources & editorial note
Primary pages read for this article. Publication dates below belong to the sources; access dates record our research.
- How Lovable uses Clay to scale one of the fastest-growing startups in history
Clay · undated customer-story page; no visible publication date
Accessed 2026-10-06 - Brand.ai uses AI to make brands more human with Claude
Anthropic · no publication date shown on page
Accessed 2026-10-06
AI-assisted editorial production
A&A uses AI for research, writing, translation and editorial checks. Source facts, our analysis and hypothetical examples are labeled separately.
Editorial check: 2026-10-06