Want context before filling out the form? Read the full intake guide below.
Problem is real, but not clean yet?
That is normal. Send the messy version. We'll help separate current state, owner, metric, and first proof point.
About the intake process
Intake is the front-door control surface for the entire operating model. It is built for real, sponsored transformation opportunities — not general requests, and not help-desk tickets. Every submission should have an owner, a measurable outcome, and a plausible path to adoption.
It is also designed to respect your time. The central tension in any intake is user effort vs. decision-quality information: too light and we chase context for weeks; too heavy and good opportunities never get submitted. The resolution is progressive disclosure — a short, low-effort set of essentials first, with deeper questions layered in only as the case advances into discovery.
Want the 10-question intake template?
Get the lightweight version you can use to frame a case before submitting.
How to work with the Lab
Bring a business problem, not just a tool request. The strongest opportunities usually sound like one of these:
- This process takes too long.
- We have the data, but not the visibility.
- Our team is doing this manually every week.
- We are missing opportunities because the handoff is slow.
- We need a better way to qualify, route, or act on this information.
- This workflow works for one team, but does not scale across many.
- We cannot easily measure whether this is working.
- We have an idea, but need help turning it into an executable plan.
Common intake use cases
The same intake structure flexes across the shapes a request usually takes. A request type up front toggles the depth required later.
New opportunity / idea
A recurring manual process, a data gap, or an inconsistent workflow that someone wants help shaping into a solution.
Discovery / assessment
A suspected transformation area where structured discovery can quantify value and define a roadmap.
PoC / Pilot
A tangible idea ready for a safe, time-boxed experiment to validate impact before scaling.
Automation / AI enablement
Fragmented workflows that should be standardized and automated behind a single, governed layer.
The ten intake questions
At minimum, intake answers ten core questions. Keep early effort low — ranges and plain language beat false precision.
Always answer
- Name of use case?
- What type of use case is this? (Discovery, PoC / Pilot, Scaleup / Program, Automation)
- Who is the business owner and contact?
- What is the business function? Which P&L and who owns this?
- In plain language, what is the problem statement and current state?
- Who is affected and how?
- What are the primary value type(s) and rough impact scale?
- What does success look like?
- Are there any hard deadlines or timing constraints?
Helpful if known
- What systems, data sources, and workflows are involved?
- What dependencies and related initiatives exist?
- Have there been prior attempts? What are the lessons learned?
- What's the sponsorship level and funding status?
- Are there any attachments or links to supporting artifacts?
What each core question is really capturing
| Core question | What we capture |
|---|---|
| Who owns the business problem? | Named owner, role, contact, accountability. |
| What team / event / function / P&L does this impact? | Business function, events / programs, P&L tag. |
| What is happening today? | Current workflow / process description. |
| What is the pain point or opportunity? | Problem statement, symptoms, frequency, severity. |
| How is success currently measured? | Existing KPIs, metrics, or proxies. |
| What would improve if this worked? | Desired outcome, directional targets, value hypothesis. |
| What data, systems, or workflows are involved? | Systems, datasets, tools, high-level workflow notes. |
| Who needs to be involved in decision / implementation? | Stakeholders, SMEs, approvers, partner teams. |
| What is the expected business value? | Rough value type and magnitude (ranges, not precise ROI). |
| How quickly can we test or prove the idea? | Timing constraints, deadlines, candidate pilot scope. |
The intake structure
Five short sections, single-column and multi-step, moving from essentials to optional depth. The first sections are all you need to submit; the later ones are helpful if known.
Basic Request Info
Low effort — all required- Title / short name
- Request type: Discovery, PoC / Pilot, Scaleup / Program, Automation / AI enablement, Other
- Business owner name & role
- Submitter name & role (if different)
- Business function / P&L
Problem & Impact
Depth with guidance- Current state: what happens today
- Problem / pain statement: what's going wrong
- Who is affected: teams, roles, customers, partners
- Impact focus: time, cost, revenue, risk, experience
- Rough impact scale: from low (annoying but manageable) to critical (revenue, compliance, or major delivery at risk)
Desired Outcomes
Feel-heard focus- What does success look like? (1–3 sentences)
- How is success currently measured?
- What would improve if this worked? (e.g. reduce manual effort by ~30%)
- Priority & timing: must-have vs nice-to-have, any hard deadlines
Context & Constraints
Optional — helpful if known- Systems / tools involved
- Data sources (if known)
- Constraints and risks (time, regulatory, contractual)
- Dependencies / related initiatives
- What's been tried already?
Additional Notes & Attachments
Open space- Anything else we should know?
- Attach or link artifacts (slides, spreadsheets, diagrams, dashboards)
- A quick note on how this intake felt to complete
Triage essentials vs. analysis details
A two-tier strategy keeps submission fast while still feeding prioritization and measurement. Triage essentials are required to submit; analysis details are expanded later during discovery — they can be “N/A” at intake without penalty.
Required to submit; support go / no-go and routing.
Title, request type, business owner, function / P&L, problem summary, primary value type, rough impact scale, timing constraint (if any).
Optional at intake; expanded during Discovery.
Detailed workflow, systems list, data sources, dependencies, prior attempts, risk considerations, preliminary metrics.
Questions designed to make you feel heard
Intake works better when it speaks to lived experience, not procurement. Alongside the structured fields, there is room for narrative — a low-friction space to make sense of the problem in your own words:
- What frustrates you most about the current process?
- If we did nothing for the next 6–12 months, what would happen?
- What does success look like for you and your team?
- Is there a recent example that captures this problem?
- How did you first notice this — who was in the room, and what surprised you?
One well-placed story plus a few structured fields beats five overlapping text boxes every time.
How the intake is designed
The form follows a few hard-won rules, drawn from established form-design and UX best practice:
- Plain, jargon-free labels — “What’s the problem?” beats “Describe the operational inefficiency.”
- Single-column, multi-step layout with a clear sense of progress.
- Fewer than eight required fields to submit; everything else is optional.
- Examples and sentence starters to lift answer quality without adding fields.
- Required vs. “helpful if known” clearly marked, so nobody stalls on a field they can’t answer.
- Ranges over false precision — “10–50 hours/month” and “Low / Medium / High” are perfect at intake.
Simplified, focused, single-column forms reliably improve completion and reduce drop-off — so this one is deliberately light at the front and deep only where it earns its keep.
We look forward to collaborating with you. A well-formed intake reliably captures the who, what, and why of a transformation opportunity — and gives the Lab the best possible chance of turning “we should do this” into “this is live, adopted, measured, and producing value.”