{"site":{"name":"Koji","description":"AI-native customer research platform that helps teams conduct, analyze, and synthesize customer interviews at scale.","url":"https://www.koji.so","contentTypes":["blog","documentation"],"lastUpdated":"2026-07-30T18:11:11.340Z"},"content":[{"type":"documentation","id":"9eb5dc0d-9592-42ba-8201-147e45f9a85b","slug":"proxy-research-guide","title":"Proxy Research: How to Run User Research When You Can't Talk to Your Users","url":"https://www.koji.so/docs/proxy-research-guide","summary":"Proxy research means learning about users from people who are not those users — support agents, customer success staff, solution engineers, domain experts, internal stakeholders. It is defensible only under one rule: ask proxies about behavior they have personally observed, never about preferences they imagine users hold. Proxies are witnesses, not stand-ins. Rank them by observational proximity (frontline support highest, internal stakeholders and synthetic personas lowest) and apply each tier's systematic bias correction. Use the critical incident technique to convert generalization into observational data, and tag every claim as observed, reported, or inferred. Most proxy research is a cost workaround rather than a methodological choice; asynchronous always-on AI interviews remove the scheduling blocker that causes most substitution.","content":"## Can you do user research without access to users?\n\nYes — but only under strict discipline, and never as a permanent substitute. Proxy research means learning about users from people who are not those users: support agents, solution engineers, domain experts, account managers. Done well, it is a legitimate bridge that keeps a team evidence-led while access is negotiated. Done badly, it manufactures confident, wrong beliefs that are harder to dislodge than ignorance.\n\nThe single rule that separates the two: **ask proxies about behavior they have personally observed, never about preferences they imagine users hold.** A support lead who has handled 400 tickets about an error state is a genuine source of evidence about that error state. The same person guessing whether users would prefer a redesigned dashboard is not evidence at all.\n\n## Why teams end up without access\n\nBlocked access is common enough to be a structural condition of the job rather than an excuse. Recruiting remains the dominant operational constraint in the field: User Interviews' *State of User Research 2025* found **54% of researchers struggle with time-to-recruit**, **62% report difficulty recruiting for specialized studies**, and **57% report participant quality concerns**. Those numbers describe teams who are *allowed* to recruit.\n\nGenuine blockers usually fall into five categories:\n\n1. **Enterprise gatekeeping.** Sales or account management controls the relationship and will not risk a customer conversation, particularly mid-renewal.\n2. **Regulated or vulnerable populations.** Clinical, financial, or child-facing users where access requires approvals that take months.\n3. **Security and contractual restrictions.** Air-gapped environments, classified deployments, or NDAs that forbid direct contact.\n4. **Pre-launch products.** There are no users yet — only a target market.\n5. **Low-incidence populations.** The role you need represents a fraction of a percent of any panel.\n\nWhich category you are in determines the right response. Categories 1 and 5 are usually *recruiting* problems with real solutions. Only 2, 3, and 4 genuinely justify sustained proxy work.\n\n## Check first: is the blocker real, or just the calendar?\n\nBefore accepting proxy evidence, exhaust the channels that reach real users without requiring a scheduled meeting. Most access complaints are really scheduling complaints — the objection is to an hour of a customer's time on a specific Tuesday, not to research itself.\n\n- **In-product intercepts** reach real users at the moment of the behavior, with no calendar involved.\n- **Support and cancellation flows** already contain real users who have volunteered a problem.\n- **Lapsed and churned users** are frequently outside the account team's protection and unusually candid.\n- **Asynchronous interviews** remove the scheduling constraint entirely — the participant answers at 11pm on their own time.\n\nThis matters because the asymmetry is enormous: a mediocre thirty-minute conversation with one real user typically outperforms three excellent conversations with proxies.\n\n## The proxy ladder: ranked by evidence quality\n\nNot all proxies are equivalent. Rank them by how directly the person has observed real user behavior.\n\n| Tier | Proxy | What they can tell you | Systematic bias |\n| --- | --- | --- | --- |\n| 1 | **Frontline support agents** | Failure modes, error frequency, exact language users use | Skewed to users who complain; over-weights broken paths |\n| 2 | **Customer success / onboarding staff** | Adoption blockers, workflow sequence, org politics | Optimistic; incentivized to report the account as healthy |\n| 3 | **Solution engineers / trainers** | Where users get stuck in live demos and training | Sees the guided path, not the unguided one |\n| 4 | **Domain experts (SMEs)** | Regulatory constraints, industry workflow norms | Expert blind spot — fluent users cannot see novice friction |\n| 5 | **Internal stakeholders** | Company intent and constraints — *not* user reality | Strongest bias; history with the product distorts judgement |\n| 6 | **Synthetic / AI personas** | Hypothesis generation only | No ground truth whatsoever |\n\nNielsen Norman Group is direct on the bottom of this ladder: colleagues and stakeholders are not representative of your audience, and employees hold unusually strong views because of their relationship with the organization. Bloomberg's UX team, writing on when proxies are defensible, notes that asking proxies to imagine a scenario produces invalid results — while support and technical sales staff genuinely did help surface pre-launch issues when treated as observers.\n\nThe pattern in both: proxies are useful as **witnesses**, useless as **stand-ins**.\n\n## How to interview a proxy correctly\n\nThe interview technique for proxies is different from a user interview, because the failure mode is different. With users you fight memory and social desirability. With proxies you fight *generalization* — the smooth, confident summary that averages away every specific.\n\n**Use the critical incident technique.** Never ask \"what do users struggle with?\" Ask:\n\n- \"Walk me through the last three times a customer hit this. What happened first?\"\n- \"What exact words did they use in the ticket?\"\n- \"What did they try before contacting you?\"\n- \"Tell me about one where you were surprised by what they did.\"\n\nAnchoring to specific, recent, countable incidents converts a proxy's opinion into observational data. Then apply the correction: for every claim, ask yourself which users this person never meets. Support hears from complainers; success managers hear from champions. Neither hears from the silent majority who simply left.\n\n**Separate the three claim types.** In your notes, tag every statement as *observed* (they saw it), *reported* (a user told them), or *inferred* (they are theorizing). Only the first two are evidence. In most proxy transcripts, the third category is the largest — and it is the category most likely to end up in a slide deck as a user need.\n\n## What proxies can never give you\n\nBe explicit in every readout about the ceiling of this evidence:\n\n- **Preferences and desirability.** No proxy can tell you whether a user would want something.\n- **Emotional response and trust.** Second-hand emotion is anecdote.\n- **Anything about the silent majority.** Proxies systematically over-represent the vocal ends of the distribution.\n- **Willingness to pay.** Account managers guess this constantly and are reliably wrong.\n\nLabel proxy-derived findings as such in the repository, with the tier attached and an explicit expiry date. Proxy insight should be treated as a loan against future real-user research, not as a permanent asset.\n\n## The modern approach: make real access cheap enough that proxies become rare\n\nMost proxy research is not a methodological choice. It is a cost workaround — the traditional research pipeline (screen, schedule, moderate, transcribe, code) is expensive enough that teams substitute the nearest available human. Change the cost and the substitution stops making sense.\n\nThis is where an AI-native platform changes the calculus:\n\n- **Asynchronous, always-on interviews.** Koji's AI moderator runs interviews 24/7, so the participant chooses the moment. This dissolves the most common real blocker — the calendar — without asking a customer to give up a scheduled hour.\n- **In-product and CRM-triggered recruiting.** Launch interviews directly from product events or an imported CRM cohort, reaching real users in the workflow rather than negotiating through an account team.\n- **Low-incidence populations become viable.** When the marginal cost of an interview approaches zero, you can leave a study open for weeks and accumulate the fifteen rare-role participants that a scheduled study could never justify.\n- **Multi-language moderation.** Access blockers are often linguistic; AI moderation removes the interpreter from the critical path.\n- **Structured questions keep proxy sessions comparable.** When you *do* interview proxies, Koji's six structured question types (open_ended, scale, single_choice, multiple_choice, ranking, yes_no) let you quantify frequency and severity across many support agents rather than collecting six irreconcilable narratives — turning scattered proxy anecdote into something you can actually count.\n- **Quality scoring flags thin evidence.** Every Koji interview is scored on response quality, which makes it visible when a session produced generalization rather than specifics — exactly the failure mode proxy interviews are prone to.\n\nLegacy platforms optimize for the scheduled, moderated session, which is precisely the format blocked customers cannot accommodate. Removing the scheduling constraint is what converts \"we can't reach our users\" into \"we reached eleven of them last week\".\n\n## A five-step proxy research plan\n\nWhen proxy work is genuinely justified, run it as a designed study rather than a series of hallway conversations.\n\n**Step 1 — Write down what you would ask a real user.** Start from the real research question. This keeps the proxy study anchored to the decision rather than drifting into whatever the proxies find interesting.\n\n**Step 2 — Mark each question as proxy-answerable or not.** Behavioral and frequency questions survive the translation. Preference, desirability, and emotional-response questions do not. Delete the second group rather than asking them anyway — asking an unanswerable question of a cooperative proxy is how invented findings enter a repository.\n\n**Step 3 — Recruit across tiers, not within one.** Three support agents will agree with each other and give you false confidence. One support agent, one onboarding specialist, and one solution engineer will disagree productively, and their disagreements map precisely onto the segments each of them sees.\n\n**Step 4 — Quantify the qualitative.** Ask every proxy the same closed questions about frequency and severity alongside the open discussion. Ten proxies rating the same twelve failure modes on a consistent scale produces something you can rank; ten narrative conversations produce something you can only summarize.\n\n**Step 5 — Convert findings into hypotheses with an owner and an expiry.** Every proxy finding should leave the study written as a testable claim, tagged with the tier it came from and the date it must be validated against real users. This is what stops proxy evidence from silently becoming permanent.\n\n## Getting back to real users\n\nProxy research should always come with an exit plan, because the access blocker rarely disappears on its own. Two moves work in practice.\n\nThe first is to use the proxy findings as the business case. A support-derived estimate that a specific failure mode generates a measurable share of tickets is a far stronger argument for customer access than a generic request for research time, and it converts the account team from gatekeeper to collaborator.\n\nThe second is to lower the ask. Most gatekeeping objections are about the cost imposed on the customer — an hour of a named executive's time. An asynchronous interview the customer completes at their convenience is a materially smaller request, and account teams approve it far more often than a scheduled call. The blocker was never research; it was the meeting.\n\n## Related Resources\n\n- [Structured Questions in AI Interviews](/docs/structured-questions-guide) — quantify severity and frequency across multiple proxy interviews\n- [How to Find and Recruit Research Participants](/docs/finding-research-participants) — solve the access problem properly\n- [Recruiting B2B Participants for User Research](/docs/recruiting-b2b-participants) — getting past enterprise gatekeeping\n- [Secondary Research: The Complete Guide](/docs/secondary-research-guide) — evidence from published sources rather than human proxies\n- [Support Ticket Analysis](/docs/support-ticket-research-analysis) — mining the record instead of interviewing the agent\n- [Sales Call to Customer Insight](/docs/sales-call-to-customer-insight) — extracting real user voice from existing conversations\n- [Synthetic Users in Research](/docs/synthetic-users-research-methodology) — where AI personas are and are not trustworthy\n\n## Frequently asked questions\n\n**Is proxy research better than no research?**\nOnly when it is labelled honestly and restricted to observed behavior. Unlabelled proxy findings presented as user needs are worse than no research, because a confident wrong belief blocks the real study that would have corrected it.\n\n**Can I test a prototype with colleagues?**\nFor catching broken flows and typos, yes — that is quality assurance. For evaluating whether the design works, no. Colleagues know too much and are socially constrained from being harsh about work their peers did.\n\n**How long can a team run on proxy evidence?**\nTreat it as a single cycle. If you are still proxying after one planning period, the access problem has become an organizational one, and the fix is escalation rather than another round of internal interviews.","category":"Research Methods","lastModified":"2026-07-28T03:21:59.800611+00:00","metaTitle":"Proxy Research: User Research When You Can't Talk to Users (2026) | Koji","metaDescription":"Blocked from real users? Learn the proxy ladder ranked by evidence quality, the critical incident technique for interviewing proxies, the bias each proxy type carries, and how async AI interviews make real access cheap again.","keywords":["proxy research","user research without users","research when you cant talk to users","proxy users","internal stakeholder interviews","user research access","subject matter expert interviews","critical incident technique","B2B research access","Koji"],"aiSummary":"Proxy research means learning about users from people who are not those users — support agents, customer success staff, solution engineers, domain experts, internal stakeholders. It is defensible only under one rule: ask proxies about behavior they have personally observed, never about preferences they imagine users hold. Proxies are witnesses, not stand-ins. Rank them by observational proximity (frontline support highest, internal stakeholders and synthetic personas lowest) and apply each tier's systematic bias correction. Use the critical incident technique to convert generalization into observational data, and tag every claim as observed, reported, or inferred. Most proxy research is a cost workaround rather than a methodological choice; asynchronous always-on AI interviews remove the scheduling blocker that causes most substitution.","aiPrerequisites":["finding-research-participants","ux-research-methods-guide"],"aiLearningOutcomes":["Decide whether an access blocker is genuine or merely a scheduling problem","Rank proxy sources by evidence quality using the proxy ladder","Apply the correct bias correction for each proxy type","Run proxy interviews using the critical incident technique","Separate observed, reported, and inferred claims in proxy transcripts","Label and expire proxy-derived findings responsibly"],"aiDifficulty":"intermediate","aiEstimatedTime":"13 min read"}],"pagination":{"total":1,"returned":1,"offset":0}}