Every citizen development program needs a single intake path. Most organizations design one that is so heavy it becomes the first thing builders learn to avoid.
The intake process is the front door to your citizen development program. It routes demand to the right delivery path, gives the CoE visibility into what is being built, and ensures minimum documentation before resources are committed. Get it right and the CoE has a clear picture of organizational demand. Get it wrong and builders go around it, creating exactly the shadow IT the program was meant to prevent.
This guide covers the design principles for an intake process that works, the specific fields to include (and why each one earns its place), the four delivery paths that intake should route to, and the critical distinction between intake and exploration that most programs get wrong.
The Principle: Friction Kills Adoption
BJ Fogg's Behavior Model offers the clearest framework for intake design. The model states that behavior happens when motivation, ability, and a prompt converge. For citizen development intake, the insight is this: reducing friction is more effective than increasing motivation.
You can send all the emails you want encouraging people to use the intake process. If the form takes 30 minutes and requires a full business case, builders with real problems to solve will skip it. They will build on personal accounts, in unsanctioned tools, or in the default environment without telling anyone.
The design constraint for intake is ruthless simplicity. Every field you add is friction. Only include a field if it would actually change the routing or review decision. If removing a field would not change how the CoE triages the request, the field should not exist.
The intake form should take no more than five to ten minutes to complete.
Intake vs. Exploration: A Critical Distinction
Here is a design principle that is easy to get wrong: the intake form is not for everyone who wants to learn or experiment. It is specifically for people who have identified a real business problem and are ready to pursue a solution through the program.
Exploration and learning should have a separate, even simpler path. A citizen developer who wants to try building something in a sandbox, take a training module, or attend office hours should not need to fill out an intake form. Requiring intake for exploration creates two problems: it discourages experimentation (which is how builders develop skills) and it floods the CoE with requests that are not yet ready for triage.
Exploration path: Self-service access to sandbox environments, training resources, office hours, and community channels. No form required. The goal is to lower every possible barrier to learning.
Intake path: A structured submission for people with a specific business problem who want CoE support routing it to the right delivery path. The form captures enough information for triage and tier assignment.
These two paths serve different needs at different stages of the builder journey. Conflating them is one of the most common intake design mistakes.
The Intake Form: Fields That Earn Their Place
Every field below serves a specific triage or routing purpose. Fields that exist only for reporting or that duplicate information available elsewhere have been excluded.
Request title (text): A short name for the solution or problem. Used for tracking and communication. One line.
Problem description (textarea, two to three sentences): What business problem does this solve? This is not a requirements document. It is a brief description of the pain point. Enough for the CoE to understand the context and assess whether citizen development is the right path.
Department (text): Which business unit or function is requesting this? Used for demand tracking and for routing to the right CoE contact or Champion in a hybrid model.
Business owner (text): The person accountable for the solution's outcomes. Every solution needs an owner from day one. The no-orphans principle starts here.
Primary contact (text): The person the CoE should contact for follow-up. Often the same as the business owner, but not always.
Estimated users (number): Approximately how many people will use this solution? This is the first input to tier assignment. A solution for 5 people and a solution for 500 people have fundamentally different governance requirements.
Data sensitivity (multi-select: customer data, financial data, PII, regulated/PHI, none): What types of data will this solution access or process? This is the second and often most important input to tier assignment. Any selection other than "none" triggers at minimum a Tier 2 review.
Current tools or workarounds (textarea): How is the team handling this problem today? This field serves two purposes. It helps the CoE understand the current state and assess complexity. It also identifies potential shadow IT: if the team is already using an unsanctioned tool, the intake becomes a shadow IT conversion opportunity.
Desired outcome (textarea): What does success look like? Not technical specifications, but the business outcome the requestor wants. "Approval process takes 2 days instead of 2 weeks" is more useful at intake than "build a Power Automate flow with three approval stages."
Hard deadline (date, optional): Is there a regulatory, contractual, or business deadline driving urgency? Most requests do not have one, and that is fine. When a hard deadline exists, it affects prioritization and routing.
Regulatory driver (text, optional): Is this request driven by a compliance requirement? If so, which one? This field, combined with data sensitivity, determines whether the solution automatically escalates to Tier 3.
What Is Notably Absent
The intake form does not include lengthy technical specifications, full business cases, ROI calculations, or architecture diagrams. Those come later, for the appropriate tier, not as entry barriers. A Tier 1 personal tool should never require a business case. A Tier 3 enterprise solution will develop a full business case during the structured delivery lifecycle, not at intake.
The Four Delivery Paths
On submission, the CoE performs a quick triage, ideally within one to two business days, and routes to one of four delivery paths. Where possible, auto-routing logic based on intake responses should suggest the initial path.
Path 1: Self-Service (Tier 1)
The requestor is directed to build independently using sandbox environments, templates, training resources, and community support. The CoE provides guidance if requested but does not review the solution before deployment. This path applies to low-risk, small-scope solutions with non-sensitive data.
Most intake requests should route here. If the majority of your intake volume is going to Paths 2 through 4, your Tier 1 criteria may be too narrow or your intake form may be capturing requests that should be on the exploration path instead.
Path 2: Coached Build (Tier 2)
The requestor builds the solution with structured CoE support. This includes a design review before development begins, access to a department-specific sandbox, and a CoE review before production deployment using the App Review Checklist. This path applies to departmental solutions with moderate complexity or data sensitivity.
Path 3: CoE-Partnered Build (Tier 2-3)
The CoE assigns a team member or Champion to work directly with the requestor. This path applies when the solution is within citizen development scope but the builder needs significant technical guidance or the solution touches multiple systems. The citizen developer remains the builder, but with close CoE partnership throughout.
Path 4: Handoff to IT (Tier 3)
The request exceeds citizen development scope and is routed to professional development teams. The CoE facilitates the handoff, ensuring the business context from the intake form transfers to the IT project team. The original requestor may remain involved as a subject matter expert.
The CoE should track handoff volume. A high proportion of requests routing to Path 4 may indicate that scope boundaries need adjustment or that the program needs more advanced training to extend citizen developer capabilities.
Triage: Making It Fast
The triage process should be lightweight and fast. One to two business days from submission to routing decision. Longer triage times are the most visible signal that the intake process is becoming a gate.
The triage decision tree is straightforward. Assess data sensitivity from the intake form. If regulated or PHI data is involved, route to Path 3 or 4. Assess estimated users and business criticality. If departmental scope or above, route to Path 2 or 3. If low-risk across all dimensions, route to Path 1 with a welcome message pointing to sandbox access and training resources.
For programs with sufficient volume, auto-routing based on intake responses can suggest the initial path. The CoE reviews and confirms but does not need to make every routing decision from scratch.
Measuring Intake Health
Track these metrics to ensure your intake process is serving its purpose.
Submission volume per month: Is demand growing? Flat or declining submission volume may indicate that builders are going around the process.
Triage time: How long from submission to routing decision? Target one to two business days. Anything longer indicates a bottleneck.
Distribution across delivery paths: What percentage goes to each path? A healthy distribution has the majority in Path 1, moderate volume in Paths 2 and 3, and a small percentage in Path 4.
Abandonment rate: If your intake form is digital, track how many people start but do not finish. A high abandonment rate signals too much friction.
Bypass rate: How many solutions are discovered in production that never went through intake? This is the most important metric. If builders are regularly deploying without going through the front door, the intake process has failed the seventh principle.