I tracked one number for my first design partner program: did they reply to my emails. Four partners, four months, and I couldn't have told you which one was going to pay until the week it actually happened.
That's a bad way to run a program that's supposed to tell you, early, who your real buyers are. Somewhere around partner number seven, I stopped tracking sentiment and started tracking four specific numbers instead. Together they predicted conversion far more reliably than any read I ever got off a call.
The four metrics that actually predict conversion
None of these require a RevOps stack. All four come from your product analytics and your own inbox.
1. Weekly product sessions per seat
Not "have they logged in," but how many separate sessions show up in a rolling seven-day window, from any user with access. In my data, partners who converted averaged three or more sessions a week from at least one user by week three. Partners who didn't convert dropped below two sessions a week by week four and never came back, even while telling me on calls that things were going great.
2. The ratio of dated requests to undated ones
Every feature request gets one of two tags: dated ("we need this before our Q3 renewal") or undated ("would be nice to have eventually"). Partners who converted sent at least one dated request within the first 30 days. Partners who didn't convert sent zero, no matter how many undated ones piled up. Volume of feedback isn't the signal. A date attached to a request is the signal, because a date means someone internally is planning around your roadmap.
3. Number of distinct people who've actually touched the product
One person driving the whole relationship is a demo, not a partnership. I count distinct logins in the usage data, not names cc'd on an email thread, by day 45. Zero-to-one distinct users by day 45 correlated with zero conversions in my data. Two or more correlated with better than a 60 percent conversion rate. A second user showing up is someone internally deciding this is worth their own time, not just yours.
4. Reply-latency trend, not reply latency itself
The absolute number matters less than the direction. I log the hours between my message and their reply, every time, and watch the trend. A partner replying in four hours in week one and thirty hours by week six is telling me something, even though thirty hours still technically counts as responsive. A flat or improving trend line is a far better sign than any single fast reply ever was.
Why this beats the enthusiasm check
None of this is about whether a partner sounds happy on a call. Sounding happy is free, and every design partner learns fast that founders want to hear it. Usage, dated requests, user spread, and reply-latency trend all cost the partner something real: time, internal coordination, or admitting a deadline exists. That's what turns them from noise into signal.
The tracker, built in an afternoon
You don't need new tooling for this. A spreadsheet with one row per partner, updated every Friday, is enough. Five columns:
- Sessions this week, pulled from product analytics, not self-reported
- Dated requests received this week, yes or no, plus the actual date mentioned
- Distinct users to date, a running count that should never decrease
- Reply latency this week, in hours, averaged across everything they sent
- 30-day trend arrow for each of the above: up, flat, or down
Fifteen minutes on a Friday is the whole system. I've run it for the last dozen partners, and it's caught every disengagement I would have otherwise only found out about a month later, on a call where they finally told me they'd "gone in a different direction."
If you're running a design partner program right now, don't wait for your gut to tell you who's converting. Pull the last 30 days of usage data for each partner tonight and count sessions per week. If any partner is under two, you already have your answer. They just haven't said it out loud yet.
Frequently asked questions
How often should I update these metrics?
Weekly, same day every week. Anything less frequent and the trend lines, which are the actual signal, get too noisy to read.
What if a partner has great usage but no dated requests?
Keep going, but ask directly for a decision date rather than waiting for one to appear on its own. Heavy usage without a dated request usually means you're solving a real problem for someone who hasn't yet been asked to commit budget to it.
Should I share these metrics with the partner?
Not the raw tracker, but the underlying questions are fair to ask directly: who else on their team should be using this, and when do they expect to decide. Asking is often what produces the second user or the dated request in the first place.
What's a reasonable reply-latency target?
There's no universal number worth chasing. What matters is whether their latency is trending flat or improving over 30 days. A slow but steady partner beats a fast partner whose response times are quietly getting longer every week.