Process Improvement Survey Template
Pinpoint where your process slows down, breaks at handoffs, or creates rework using a short internal survey built around real stages (intake, triage, execution, review, handoff). Use the question bank and rollout checklist to collect consistent baseline data now, then re-run after changes to track cycle time, waiting, defects, and tool friction over time.
Trusted by 5000+ Brands
Choose the Right Respondents (Stakeholder Map + Sampling Mix)
Outcome: Get feedback from the people who see delays, rework, and handoff failures first -- without averaging away the real problem.
- Pick one process name (for example, "Purchase request to PO") and write the start/end triggers.
- List 5-8 stages you will reuse everywhere (intake, triage, execution, review, handoff).
- Map roles into doers, approvers, suppliers/inputs, and internal customers.
- Set a respondent mix so every handoff is covered.
- Tag each response with role + stage touched so you can cut results by handoff.
Respondent map: Start by writing the four groups on a whiteboard (or in your invite doc) and add actual job titles under each. Do this before you write questions because the doers will talk about waiting and tool workarounds, while internal customers will talk about SLA misses and unclear ownership.
- Doers (execute the work): people who process cases, build, test, pack, schedule, or close tickets.
- Approvers (gatekeepers): people who approve intake, budgets, reviews, or QA sign-off.
- Suppliers/inputs: teams that provide requirements, data, parts, or upstream tickets.
- Internal customers (downstream): teams that receive the output at handoff (billing, shipping, customer support, next production cell).
Respondent mix starter targets (adjust after your baseline): Use a simple mix first, then adjust if your process is approval-heavy.
- 60-70% doers (internal starter target; most issues live in execution and rework loops).
- 20-30% internal customers (internal starter target; they see late handoffs and quality escapes).
- 10-20% support functions like IT/QA/procurement (internal starter target; they see tool constraints, controls, and policy bottlenecks).
Split surveys when variants are real: If Site A uses a different system, or night shift has different staffing, split the survey (or at least branch by variant) because one blended score hides where waiting time and defects actually start.
Do this next: Add 3-5 required fields at the top of the survey, then reuse them in every follow-up run.
- Site/team/shift: for example, "Plant 2 -- Shift B".
- Role: doer, approver, supplier/input, internal customer.
- Process stage(s) touched: intake, triage, execution, review, handoff (multi-select).
- Work type variant (if needed): standard path vs exception path.
Use AAPOR's best practices for survey research as a quick gut-check: define your target groups, invite them deliberately, and document how you sampled so you can explain what the results represent.
If you want a lightweight way to document who you invited (and why), build a one-page sampling plan that lists each role group, the count invited, and the stage coverage you expect (intake vs review vs handoff).
Question Bank: Bottlenecks, Handoffs, Quality, Tools, and Ownership
Outcome: Pinpoint which stage creates the most waiting, which handoff breaks, and what causes rework -- with questions you can trend over time.
- Lock 4-6 core questions you will keep the same at baseline and follow-up (internal starter target; adjust after your baseline).
- Add 1-2 diagnostic modules for your process right now (tools, compliance, training) (internal starter target).
- Use two ratings for issues: frequency + severity (cycle time, defects, rework).
- Force prioritization with one "pick top 3" bottlenecks question.
- Collect one example per major pain point (short open text).
Keep your rating formats consistent across runs. If you need a quick default, pick one set of Likert scale options for agreement and use the same 1-5 labels every time.
Stable for trending (keep these): overall process score, handoff clarity, rework frequency, and time lost to waiting. Customize freely: tool names, stage labels, compliance controls, and exception-path questions.
"Overall, this process works well end-to-end."
Why it matters: This is your baseline outcome score. When it drops after a change, you know cycle time, defects, or handoffs got worse somewhere.
When to use: Include in every run (baseline, 30/60/90-day pulse, quarterly) (internal starter cadence; adjust to your change cycle).
"Handoffs between intake, triage, execution, review, and handoff are clear and predictable."
Why it matters: Low scores usually mean unclear inputs/outputs or unclear ownership at a specific stage transition (for example, triage to execution).
When to use: Keep stable for trending. Pair with an open-text example question if the score is low.
"How often do you lose time waiting for an approval, input, or handoff in this process?"
Why it matters: Waiting time is invisible in many trackers. A frequency read tells you where to look for cycle-time spikes.
When to use: Keep stable for trending. If you branch, ask approvers about review wait and doers about intake wait.
"How much time do you typically lose to waiting per case/item?"
Why it matters: This turns "it feels slow" into a usable proxy for cycle time impact.
When to use: Use after the waiting-frequency question. Keep the buckets stable across runs.
"How often do you have to redo work because inputs were incomplete or incorrect?"
Why it matters: Rework drives cost and late handoffs. Frequency points you to the stage where defects enter (often intake or review).
When to use: Keep stable for trending. Add a follow-up open-text question for examples.
"Which 3 stages create the most delay for you?"
Why it matters: Ranking prevents "everything is broken" responses and gives you a clean top-3 list for the improvement backlog.
When to use: Use in every baseline run. Update stage labels only if the process truly changed.
"The tools/systems I use in this process help me move work forward without workarounds."
Why it matters: Tool friction shows up as manual re-entry, missing data, and late status updates at handoff.
When to use: Keep stable for trending. Add a separate question listing your actual tools (customize freely).
"When work is blocked, I know who can make the decision to unblock it."
Why it matters: Slow decisions create waiting time, especially in review and approval stages.
When to use: Use when escalation paths are unclear or when exceptions pile up.
"What is the most common handoff that breaks down, and what happens next?"
Why it matters: One concrete story (missing fields, unclear acceptance criteria, wrong queue) tells you where to fix the handoff checklist or system rule.
When to use: Use after the handoff-clarity rating to explain low scores.
"For the bottleneck you ranked #1, how severe is the impact on cycle time or customer SLA?"
Why it matters: Severity separates annoyances from true drivers of late handoffs, backlog growth, and missed SLAs.
When to use: Use right after the top-3 bottlenecks question. Combine with frequency to rank drivers.
"What one change would reduce waiting time or rework within the next 30 days?"
Why it matters: This gives you quick-win candidates (template fix, clearer intake fields, simpler review checklist) without turning the whole survey into solution brainstorming.
When to use: Use at the end. Ask for one change only to keep answers specific. (The 30-day window is an internal starter prompt; adjust to your planning cycle.)
Deployment Plan: Cadence, Messages, Reminders, and Anonymity
Outcome: Get enough honest responses to spot where work waits (intake/review) and where rework starts (intake/execution) -- then re-run on a cadence you can actually keep.
-
Baseline first, then pulse: Send a baseline now, run a 30/60/90-day pulse after changes, then go quarterly (or after each major process/tool release) so you can trend waiting time, rework, and handoff clarity. (Internal starter cadence targets; adjust after your baseline and change calendar.)
-
Keep it 8-10 minutes: Cap it at ~25-35 questions total (including branching). (Internal starter targets; shorten if your audience is on the floor/on shift.) If you need more diagnostics, add them as optional modules by role (doers vs approvers).
-
Use a simple invite message (copy/paste): "We are surveying the [process name] to find where work waits, where rework starts, and which handoffs break (intake/triage/execution/review/handoff). It takes about 8-10 minutes (internal starter estimate). We will publish the top 5 issues and the actions we are taking within 2 weeks (internal starter commitment). If you choose to share your name, we may follow up for details; otherwise results will be reported in groups."
-
Schedule 2 reminders: Send the first reminder after 2-3 business days, and a final reminder 1-2 days before close (internal starter timing). Avoid peak cutovers (month-end close, major releases, inventory counts) because response quality drops when people rush.
-
Pick anonymous vs identified on purpose: Run anonymous when you expect people to sugarcoat delays, rework, or escalation failures. Survey-methods research has found anonymity can reduce social desirability pressures in self-report questionnaires (see Joinson, 1999: Social desirability, anonymity and Internet-based questionnaires).
-
Use identified mode only when you will act on follow-ups: If the process owner needs to contact someone about a specific breakdown (for example, a handoff from review to handoff), ask for name/team at the end and say exactly who will see it.
-
Set a minimum target per segment: Aim for enough responses per site/shift/role to compare (not just a total count). (Internal starter rule: do not report a cut you cannot staff with enough responses to protect confidentiality and interpret differences.) Use internal sample size guidance to pick a practical minimum for each cut you plan to report.
Do this next: Put the baseline send date, close date, and reminder dates on your calendar now, then draft the "we heard / we are doing" update before you launch so you actually close the loop.
Turn Results Into an Improvement Backlog (Balanced Scorecard + Impact/Effort)
Outcome: Convert survey scores into a prioritized backlog that reduces waiting time, rework, and tool friction at the exact stage where the process breaks.
- Tag and cut results by stage (intake/triage/execution/review/handoff) and role (doer/approver/customer).
- Score in 4 buckets (Customer, Process, Learning, Cost) so you do not chase only quick wins.
- Rank drivers using frequency x severity, then confirm with examples.
- Write backlog-ready actions with an owner, due date, dependencies, and KPI.
-
Step 1: Clean and label your cuts (before you look at comments)
Cut results first by stage touched and role so you can see where pain clusters.
- Example cut: doers working in execution vs approvers working in review.
- Minimum hygiene: suppress very small groups before sharing results.
-
Step 2: Score results in 4 buckets (Customer, Process, Learning, Cost)
Assign each question to one bucket, then average within bucket so leaders see a balanced view (not just one overall score).
- Customer: internal customer satisfaction, SLA experience at handoff.
- Process: flow, handoffs, defects, waiting.
- Learning: training, cross-training, tool adoption.
- Cost: rework time, duplicate entry, scrap/waste proxies.
-
Step 3: Build a stage heatmap (where the pain sits)
Create a simple heatmap with stages across the top and measures down the side, then highlight the areas that consistently score worst.
- Stages: intake -> triage -> execution -> review -> handoff.
- Measures: handoff clarity, waiting frequency, rework frequency, tool friction.
- Starter focus: flag the worst 1-2 stages per measure (internal starter rule; expand if needed).
-
Step 4: Rank the top drivers (frequency x severity)
Combine frequency and severity to rank what is actually driving cycle time and late handoffs.
- Example: a review delay that happens weekly at severity 5 outranks an intake annoyance that happens monthly at severity 2.
- Comment review: read open-text examples for the top-ranked drivers first (internal starter target: top 3).
-
Step 5: Turn drivers into backlog-ready actions
Write each action as a one-line problem statement plus enough execution detail to assign and track it.
- Include: process stage, owner (process owner/site leader/IT), due date, dependencies.
- Link to KPIs: expected movement (for example, reduce waiting-time bucket by one level; reduce rework frequency by one level).
-
Step 6: Prioritize and close the loop (impact/effort + publish-and-remeasure)
Prioritize with an impact/effort grid, then publish what you are changing and remeasure using the same core items.
- Starter portfolio: 2-3 quick wins and 1-2 structural fixes (internal starter targets; adjust to capacity).
- Close the loop: publish the plan within about 2 weeks (internal starter target), then rerun the core questions at 30/60/90 days (internal starter cadence) to confirm movement.
Common Pitfalls (and Better Wording) in Process Improvement Surveys
Outcome: Avoid vague feedback and blame-heavy wording so you can fix the stage and handoff that drives delays and rework.
- Scope one process with clear start/end triggers and 5-8 stages (starter guideline).
- Ask where/when first (stage, frequency, severity), then ask for ideas.
- Segment every response (site/shift, role, stage touched) so you can cut by handoff.
- Rewrite double-barreled items into one concept per question.
- Interpret quiet teams carefully and add reminders before you over-explain results.
What goes wrong: People answer based on different workflows, so your average score hides the real bottleneck (for example, intake for one product line vs review for another).
Do this instead: Run one survey per true variant (site/region/product/exception path) or branch early with a "Which variant do you work on most?" question, then show variant-specific stage labels.
What goes wrong: You get a grab bag of fixes that do not tell you which stage causes the cycle-time spike.
Rewrite example: Replace "How can we improve the process?" with "Which 3 stages create the most delay? (pick top 3)" + "For your #1 stage, how often does the delay happen?" + "Give one example from a recent case (for example, in the last 2 weeks)."
What goes wrong: People defend themselves, or they cannot answer because the question mixes two ideas.
Rewrite examples:
- Replace "Why do people fail to follow the process?" with "How clear are the steps and acceptance criteria at review? (1-5)"
- Replace "Tools and training are adequate" with two questions: "Tools support the work without workarounds" and "I received enough training to do this stage".
Use simple question-writing rules (one idea per question, avoid loaded wording) from established methods references such as the Pew Research Center survey methods guidance.
What goes wrong: Quiet teams can skew your view (for example, one shift answers heavily and another does not), and people may sugarcoat issues if they do not trust how results will be used.
Do this next: Add one extra reminder to the low-responding role/site, suppress reporting for very small groups, and write a one-paragraph note in your results deck about response bias (who answered, who did not, and what that could mean).
Pew Research's explainer on what low response rates mean for surveys is a useful reminder: response rate alone does not tell you everything, so focus on coverage of the key roles and stages you need to compare.
Frequently Asked Questions
How do I pick the right process scope for this survey?
Pick one named process with a clear start trigger and end trigger (for example, "request submitted" to "work handed off"). Use 5-8 stage labels as a starter guideline (intake/triage/execution/review/handoff) and reuse them consistently so you can see where waiting and rework start. If sites, regions, product lines, or exception paths operate differently, split the survey or branch early so you do not average away the real bottleneck.
Who should I include: doers, approvers, or internal customers?
Include all three because each group sees different failures: doers see tool friction and rework loops, approvers see review queues and decision delays, and internal customers see late handoffs and quality escapes. If you need a starting point, use an internal starter mix target like 60-70% doers, 20-30% internal customers, and 10-20% support (IT/QA/procurement), then report results by role and stage touched. Adjust the mix after your first baseline run if one role group is under-represented.
Should the survey be anonymous or identified?
Run anonymous when you need candid feedback about delays, rework, and escalation because people may sugarcoat issues if they fear blame. Run identified only when you will follow up on specific cases, and set clear confidentiality boundaries (who can see names, how comments will be quoted, and small-group suppression for tiny teams). State the anonymity rule in the invite message and repeat it on the first survey page.
How many responses do I need for a process improvement survey?
Set targets by the comparisons you plan to make: enough per site/shift/role (and sometimes per stage) to see meaningful differences in waiting, rework, and handoff clarity. Consistency over time matters more than chasing a single total count, so keep the same core questions and rerun on a repeatable cadence. Use the internal sample size guidance to pick practical minimums for each segment you will report.
What questions should stay the same from baseline to follow-up?
Keep a stable core: overall process score, handoff clarity, waiting/delay frequency (and time lost), rework/defect frequency, and tool friction. Change stage labels or tool names only if the process truly changed, and keep response options identical so you can compare before/after. Add one-off diagnostic modules (for example, compliance controls in review) as optional blocks so you do not break your trend lines.
How do I turn survey feedback into a prioritized improvement plan?
Rank problems using frequency x severity, then confirm the top drivers with a few open-text examples tied to a specific stage (intake vs review vs handoff). Convert each driver into a backlog item with a clear problem statement, process stage, owner, due date, dependencies, and the KPI you expect to move (less waiting time, fewer rework loops, fewer late handoffs). Balance quick wins and structural fixes by scoring in 4 buckets (Customer, Process, Learning, Cost) and prioritizing with an impact/effort grid.
Related Survey Templates
FREE TO START -- NO CREDIT CARD REQUIRED