By KYN AI Advisory Team — AI implementation specialists, Singapore
Cross-sell agents misfire because they score the wrong person. Product usage tells you who is enthusiastic. It does not tell you who can approve more spend, or when. An account can show high engagement and still be unfundable this quarter. The fix is to score two questions separately, "is this account engaged?" and "is this account fundable, and by whom?", and to send an account forward only when both are answered.
What goes wrong in a usage-driven expansion agent?
Most expansion agents watch seat activation, feature adoption, login frequency and support volume. These are reasonable proxies for readiness. The trouble is who produces them. A power user adopting a new module is not the finance director who finds room in next quarter's budget.
An agent built on usage alone optimises for enthusiasm it can measure and misses the approval it cannot. The pipeline shows high engagement, no closed deal and no stated reason.
Assumption: this describes how such systems are typically wired. We have not measured it in a documented campaign, so test it against your own closed-lost expansion deals before acting on it.
Which two data trails does an account model need?
Two different people leave two different trails. Most account models track one.
| Signal type | Examples | Who it describes | |---|---|---| | Persona (engagement) | Usage growth, feature adoption, support tickets, seat requests | The daily user | | Budget holder (fundability) | Prior deal size and approver, renewal and procurement timing, title and spend authority | The person who signs |
An agent that reads only the first trail escalates accounts where the second is silent. It answers "is the account active?" when the question standing between you and a signed order is "who funds this, and when?"
Why does rewriting the message not fix it?
When expansion underperforms, teams rewrite copy. If the targeting was never wired to detect the budget holder, better copy lands in the wrong inbox. The first repair is data, not wording.
What signals would a budget-holder-aware agent need?
Treat these as a design target, not a validated feature set. They differ for every sales organisation.
- Approver history. Who signed the last deal, for how much, under which entity.
- Cycle timing. When the renewal window opens and when budgets lock.
- Authority data. Titles or roles that carry spend authority, held on a record separate from the day-to-day contact.
- Change events. A new finance contact or a changed approver.
None of this exists in a generic playbook. It comes from your own contract history and your own approval thresholds. Pull those first.
Which design rules transfer from other agents?
Three rules from reconciliation and integration work apply directly.
- Master data first. An integration rejects any transaction whose reference record is wrong. Expansion logic has the same dependency: if the CRM does not distinguish the engaged user from the approver on an account, every sequence inherits the error.
- Ask over assume. A reconciliation agent treats a false match as worse than an open item. A cross-sell pitch fired at the wrong contact burns a relationship and a rep's credibility on a deal that could not be approved. When the budget-holder signal is missing or conflicts with the usage signal, route to a person.
- Widen tolerance only with a second signal. Accept a looser match, such as a different title or department, only when an independent data point confirms it, like a prior deal reference or shared account ID.
How do you audit an agent-led expansion motion?
Run this sequence before an account escalates.
- Verify the CRM separates the user record from the approver record for the account.
- Compute engagement and fundability as two scores. Do not blend them.
- Check whether the engaged contact matches the account's known approval path. A mismatch is a flag, not a rejection.
- If the budget-holder signal is weak or absent, send it to a named person for verification instead of generating a pitch.
- Cap automated back-and-forth at a fixed number of rounds. After the cap, the account goes to a person, not to the customer.
- Review closed-lost expansions monthly. Record whether the approver was ever contacted.
Step 6 is the measure that matters: the share of lost expansions where nobody reached the approver.
What do two separate scores look like?
The accounts below are illustrative. They show why one blended score misleads.
| Account | Engagement score (0-100) | Fundability score (0-100) | Blended average | Right action | |---|---|---|---|---| | A | 90 | 20 | 55 | Hold; find the approver | | B | 60 | 80 | 70 | Contact the approver with a use-case from the users | | C | 85 | 85 | 85 | Send to a rep for a proposal | | D | 30 | 70 | 50 | Nurture the users first |
Account A has the highest engagement and a middling blended score, which a rule such as "above 50 qualifies" would pass. It is the wrong account to pitch. The users love the product, and no budget exists. Account B looks average on engagement, but the budget is open and an approver is known. Two scores catch both cases. One does not.
Send an account to a rep only when both scores clear a threshold you set. Choose the thresholds from your own history of won and lost expansions, not from a benchmark.
How do you score fundability?
Build the score from fields you can check. The points below are illustrative; set your own.
| Signal | Points | Where it comes from | |---|---|---| | Approver of the last deal is known and still in role | 30 | Contract record, stakeholder map | | Renewal or budget window opens within a set period | 25 | Contract end date, budget calendar | | The account has paid for a previous expansion | 20 | Order history | | A finance or procurement contact exists on the account | 15 | CRM contacts | | Spend authority threshold known for this account | 10 | Notes from past deals |
A total above your threshold is "fundable". Below it, the account goes to a person to find the missing piece. The points make the gap visible: an account at 40 with no known approver tells the rep exactly what to find.
What should the agent say to the engaged user?
The user is a useful ally, not the buyer. The agent can draft a message that helps the user make the case internally, and a person approves it before it goes.
- Share a short summary of usage the user can forward: what changed since last quarter, in numbers.
- Ask who else reviews tools like this, and when budgets are set.
- Offer an introduction call with the person who handles spend.
The agent should not pitch the module to the user as if they signed the order. That sends the message to the person who cannot say yes, and it tells the approver nothing.
A worked example of a misfire
This example is illustrative. It describes a pattern, not a real client.
An expansion agent watches a software account. Usage of a reporting module doubles in a quarter. The agent drafts a pitch for the premium reporting tier and sends it, after approval, to the power user who drove the usage.
The user forwards it to their manager, who says there is no budget until the next financial year. The thread ends. The CRM logs "engaged, no response". The agent keeps the account on its high-engagement list and drafts another pitch.
With a fundability score, the account would have scored low on timing and unknown on approver. The agent would have held the pitch and sent the account to a rep with a note: "Usage up. Approver unknown. Budget window unknown." The rep would have asked the user two questions and learned about the financial-year timing. The follow-up would have been scheduled for the right quarter, with the approver included.
What edge cases confuse the model?
- Shared logins. One login used by five people looks like one engaged user. Count named users, not logins.
- Usage spikes from onboarding. New users produce high activity that fades. Compare to a baseline of the account's own history.
- Parent and subsidiary. Usage sits in one entity and budget in another. Link accounts to a parent record.
- Reseller or partner accounts. The buyer is not the user. Mark these and route them to a different flow.
- Contract in dispute. An account in a billing dispute should not receive expansion messages. Add a block field.
- Recent churn signals. A rise in support tickets can mean enthusiasm or frustration. Read ticket content before counting volume as a positive.
What should a person review before an expansion message goes out?
A short checklist, shown beside the draft:
- Who is the recipient, and what is their role on the account?
- Is the recipient the approver, a user or a go-between?
- Which fundability signals are present, and which are missing?
- Is there a billing issue, a support escalation or a recent complaint?
- Does the message contain a price, a discount or a date? If so, a named person confirms them.
The reviewer approves, edits or rejects. Each decision is logged with the name and the time.
How do you measure whether the change worked?
Use your own baseline from the last two quarters of expansion deals.
- Share of expansion deals where the approver was contacted before a proposal.
- Share of agent-flagged accounts that became opportunities.
- Time from first expansion message to reply from an approver.
- Messages sent per closed expansion deal.
- Complaints or opt-outs after an expansion message.
If the share of contacted approvers rises and messages per closed deal falls, the two-score design is working. If neither moves, check that the approver field is filled in, because most failures start with missing data.
Where KYN fits
KYN builds sales and marketing agents on top of the CRM a client already uses, in a cloud account in the client's name. For an insurance brokerage, outreach runs from one checkable first line at about S$0.02 per email, and a reply desk sorts replies at about S$0.01 each. Every action is logged with the actor. Outbound messages wait for a named person, and agents work from their own restricted accounts.
The first 14 days are a review of your stack and interviews with the team. A full build ships in under 90 days. See sales systems and marketing systems.
Frequently asked questions
Can an AI agent identify the budget holder on an account?
It can propose one from deal history, titles and org data. It cannot confirm authority. Treat the proposal as a flag for a named person to check.
Is high product usage a bad signal?
No. It is a necessary signal and an incomplete one. It shows readiness to use more. It does not show readiness to pay for more.
What is the first thing to fix?
The account and contact records. Mark who uses the product and who approves spend, as separate fields. Without that, scoring and routing both rest on one blurred contact.
Checked 30 October 2026.
Curious whether Marketing agents fits your business? Talk to KYN on WhatsApp — no forms, just a conversation.
