{"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-09-23T08:59:18.691Z"},"content":[{"type":"documentation","id":"fa56e740-e458-4ff4-8cb3-3ce0ab3c230b","slug":"research-intake-process-guide","title":"How to Build a Research Request and Intake Process","url":"https://www.koji.so/docs/research-intake-process-guide","summary":"A step-by-step guide to designing a research request and intake process: the 6-9 request-form fields that force good scoping, a weekly triage ritual, a transparent prioritization rubric (decision impact, reversibility, timing, effort), SLAs, and method routing across researcher-led, AI-moderated, and self-serve template studies. Shows how AI-native platforms like Koji move the bottleneck from research capacity to question routing.","content":"## The short answer\n\n**A research intake process is the front door to your research function: a standard request form plus a triage workflow that turns vague \"can you research this?\" asks into well-scoped, prioritized studies.** A good intake process does three things — it captures enough context up front to scope the work, it makes prioritization transparent so stakeholders trust the queue, and it protects researchers from becoming an order-taking help desk.\n\nThe minimum viable intake process is a **single request form, a weekly triage ritual, and a published prioritization rubric.** Start there before you buy any tooling. The form forces requesters to articulate the decision they're trying to make; triage converts requests into a ranked queue; the rubric keeps \"whoever shouts loudest\" from setting the agenda.\n\nThe deeper shift in 2026: with AI-native platforms like Koji, the bottleneck moves. When a single researcher can run dozens of AI-moderated interviews in parallel, intake stops being about rationing scarce research capacity and starts being about routing the *right* questions to the *right* method — including self-serve studies that requesters can run themselves under a researcher's guardrails.\n\n## Why you need an intake process at all\n\nWithout intake, research requests arrive as Slack DMs, hallway asks, and meeting tangents. The symptoms are familiar: researchers can't plan because work appears at random, stakeholders feel ignored because there's no visible queue, duplicate studies get commissioned because nobody checks the [research repository](/docs/research-repository-guide) first, and the highest-paid-person's-opinion quietly sets priorities. An intake process replaces all of that with one visible, fair pipeline.\n\nIt also raises the quality of the research itself. Half of a study's success is decided before a single interview happens — in how well the question is framed. A structured intake form forces that framing to happen at request time, not three meetings later.\n\n## The research request form: what to actually ask\n\nThe request form is the heart of intake. Too short and you get unscoped asks; too long and nobody fills it out. The sweet spot is 6–9 fields that force the requester to think:\n\n1. **What decision will this research inform?** The single most important field. If a request can't name a decision, it isn't ready — it's curiosity, not research. This one question filters out most low-value asks.\n2. **What do you already believe, and how confident are you?** Surfaces the hypothesis and the stakes of being wrong.\n3. **Who needs to be studied?** Segment, persona, or specific accounts — this seeds participant recruiting.\n4. **When do you need the answer, and what happens on that date?** Separates a real deadline (a launch) from a soft \"soon.\"\n5. **What's the impact if you're right vs. wrong?** Feeds the prioritization score.\n6. **What's already known?** A pointer to existing research prevents duplicate studies.\n7. **Preferred or required method (optional).** Useful signal, but researchers should own the final method choice.\n\nKeep these fields stable so you can compare requests on the same axes. The form output should drop straight into your triage queue.\n\n## Triage: turning requests into a ranked queue\n\nRun intake triage on a fixed cadence — weekly works for most teams. In each session you do four things:\n\n- **Clarify.** Send underspecified requests back with specific questions rather than guessing.\n- **Deduplicate.** Check the repository; if the answer already exists, link it and close the request. This is often the highest-leverage move in the whole process.\n- **Score.** Apply a simple, published rubric so prioritization is transparent.\n- **Route.** Decide the method and whether it's researcher-led or self-serve.\n\n### A simple prioritization rubric\n\nScore each request on three-to-four factors and rank by total. A common, defensible rubric:\n\n| Factor | Question | Weight |\n|---|---|---|\n| **Decision impact** | How big is the decision this informs? | High |\n| **Reversibility** | How costly is it to get this wrong? | High |\n| **Timing** | Is there a hard, dated deadline? | Medium |\n| **Effort** | How much research time does it need? | Medium (inverse) |\n\nPublish the rubric. When stakeholders can see *why* their request is third in line, they argue with the rubric instead of with the researcher — which is a far healthier conversation.\n\n## SLAs and expectation-setting\n\nAn intake process is a promise. Back it with light service levels so requesters know what to expect:\n\n- **Acknowledgement SLA:** every request gets a response within, say, two business days — even if the response is \"this is queued.\"\n- **Triage SLA:** every request is scored and routed at the next weekly triage.\n- **Transparency:** the queue is visible to everyone, with status (new, clarifying, queued, in progress, done).\n\nThese commitments are what separate a research function from a black box. They cost almost nothing and buy enormous trust.\n\n## Routing to the right method — including self-serve\n\nThe classic intake assumption is that every request becomes a researcher-led study, which makes research capacity the hard ceiling on how many requests you can serve. AI-native research breaks that ceiling. At triage, route each request to the lightest method that answers the question:\n\n- **Researcher-led deep study** for high-stakes, ambiguous, strategic questions.\n- **AI-moderated interview study** for the large middle — Koji's AI interviewer runs voice or text interviews with adaptive follow-up questions, no moderator, and writes the analysis automatically. A PM can get genuine conversational depth without booking a researcher's calendar.\n- **Self-serve template study** for well-understood, recurring questions, where a requester launches a pre-approved study built on Koji's [structured questions](/docs/structured-questions-guide) (open_ended, scale, single_choice, multiple_choice, ranking, yes_no) under guardrails the research team set.\n\nThis tiering is the single biggest lever on intake throughput. Instead of saying \"no, we're at capacity,\" the research team says \"here's the safe way to get that answer this week\" — and reserves its scarce human hours for the questions that truly need them. This is how [research democratization](/docs/research-ops-guide) actually works in practice: not abandoning rigor, but encoding it into templates and AI workflows that non-researchers can use safely.\n\n## From request to brief\n\nOnce a request is prioritized and routed, it becomes a [research brief](/docs/research-brief-template) — the bridge between the intake form and the actual study. A strong intake form does most of the brief's work already: the decision, hypothesis, audience, and timing are all captured. In Koji, much of the brief can be generated from that intake context, so the researcher refines rather than starts from a blank page. See [understanding the research brief](/docs/understanding-the-research-brief) for how the brief drives the AI interviewer and the eventual report.\n\n## Rolling it out: a 30-day plan\n\n- **Week 1:** Draft the request form (6–9 fields) and the prioritization rubric. Pick one intake channel and announce it.\n- **Week 2:** Run your first weekly triage. Migrate any in-flight ad-hoc requests into the queue.\n- **Week 3:** Add SLAs and make the queue visible to stakeholders. Build your first self-serve template study.\n- **Week 4:** Review what came through. Tune the rubric weights and trim or add form fields based on what actually predicted value.\n\nStart lightweight. The goal isn't a bureaucratic gauntlet — it's a fair, visible front door that makes research faster to request and easier to trust.\n\n## Related Resources\n\n- [Process Capability for Research Metrics](/docs/process-capability-research-metrics) — whether a stable process is actually good enough for the requirement it was given\n- [Structured Questions Guide](/docs/structured-questions-guide) — the question types that power self-serve template studies\n- [Research Operations Guide](/docs/research-ops-guide) — where intake fits in the broader ResearchOps function\n- [Research Brief Template](/docs/research-brief-template) — what a prioritized request becomes\n- [Understanding the Research Brief](/docs/understanding-the-research-brief) — how the brief drives the AI interviewer and report\n- [Research Repository Guide](/docs/research-repository-guide) — the source you check to deduplicate requests\n- [Finding Research Participants](/docs/finding-research-participants) — recruiting once a request is scoped\n- [The Re-Research Audit](/docs/re-research-audit-duplicate-studies) — the pre-commission check that belongs in this process\n- [Research Lead Time: Why a Six-Day Study Takes Six Weeks](/docs/research-lead-time-littles-law) - what the queue this process builds does to the answer date\n","category":"Research Operations","lastModified":"2026-09-21T03:26:24.837806+00:00","metaTitle":"Research Request and Intake Process: A Step-by-Step Guide (2026)","metaDescription":"Build a research intake process that works: the request form fields that matter, a transparent prioritization rubric, SLAs, and how to route requests to researcher-led, AI-moderated, or self-serve studies.","keywords":["research intake process","research request form","research request template","research operations intake","how to prioritize research requests","researchops intake"],"aiSummary":"A step-by-step guide to designing a research request and intake process: the 6-9 request-form fields that force good scoping, a weekly triage ritual, a transparent prioritization rubric (decision impact, reversibility, timing, effort), SLAs, and method routing across researcher-led, AI-moderated, and self-serve template studies. Shows how AI-native platforms like Koji move the bottleneck from research capacity to question routing.","aiPrerequisites":["research-ops-guide","research-brief-template"],"aiLearningOutcomes":["Design a research request form with the 6-9 fields that force good scoping","Run a weekly triage ritual: clarify, deduplicate, score, route","Apply a transparent prioritization rubric so stakeholders trust the queue","Set acknowledgement and triage SLAs that build trust in the research function","Route requests to researcher-led, AI-moderated, or self-serve template studies"],"aiDifficulty":"intermediate","aiEstimatedTime":"12 min read"}],"pagination":{"total":1,"returned":1,"offset":0}}