Designing a pull-based onboarding flow with STATIK
A 14-person customer onboarding team at a business bank handles new merchant accounts. Requests come from sales, partners, and compliance. There is no board; work is tracked in a shared inbox and spreadsheets. Onboarding takes 9-14 days; sales says 5. The team has six specialists, three analysts, three compliance reviewers, and two team leads. Compliance review is a mandatory gate and often sends files back for missing documents. Sales representatives email team leads directly to 'prioritize' accounts. The team wants to introduce a kanban board but disagrees on columns: some want by role, some by process stage. There is no agreed definition of 'done' or 'ready.' A regulator requires evidence of review within 24 hours for high-risk accounts. The team has two weeks to present a design.
1. Apply STATIK. What would you do first, and what outputs would you produce before designing columns?
Read the worked answer
STATIK starts with purpose and demand, not columns. First, interview sales, partners, compliance, and team members to understand what the service is for and what customers need. Analyze three to six months of onboarding requests: volume by source, arrival pattern, risk tier, rework causes, and elapsed time. Model the actual workflow by walking a sample of accounts through each handoff, decision, and wait; include the compliance gate and the missing-document loop. Identify classes of service from risk and cost of delay, such as high-risk regulatory review with a 24-hour requirement, standard, complex, and expedite. Then design the board, policies, and measures. Outputs: purpose statement, demand profile, workflow model, classes, explicit ready and done definitions, WIP limits, pull rules, and a measurement plan. Do not let the team vote on columns first; role-based columns hide handoffs. The regulator's 24-hour requirement is a class policy, not a separate board. Present the design as a system, with the compliance gate as a capacity-constrained step.
2. How would you design the board and pull policies?
Read the worked answer
Design the board around the flow of the account, for example Intake → Documents Ready → Risk Review → Compliance Review → Activation → Done, with explicit queues and ready criteria between stages. Avoid role columns such as specialist, analyst, and reviewer as the primary structure; they obscure handoffs and encourage local optimization. Add a separate expedite lane for high-risk accounts with a 24-hour policy and a WIP limit of one or two. Pull rules: an item enters Documents Ready only when required documents are present and verified; compliance pulls only when below its WIP limit and the file is complete; activation pulls when compliance signs off. Set WIP limits from capacity: compliance has three reviewers and a 24-hour obligation, so reserve capacity for high-risk work and cap standard review WIP at six to nine. Make policies visible on the board: class definitions, entry criteria, escalation, and what to do when a limit is reached. Use a daily flow review to manage aging and blockers. The pull intention is to stop starting accounts that cannot be completed and to protect the compliance gate.
3. What would you pilot in the first four weeks, and how would you measure it?
Read the worked answer
Pilot one class, such as standard merchant accounts, for four weeks. Baseline: lead time at the 50th and 85th percentiles, WIP by stage, blocked time, rework rate from missing documents, and high-risk review time against the 24-hour requirement. Hypothesis: explicit ready criteria plus a compliance WIP limit will reduce 85th-percentile lead time by 20% and rework by 30% without breaching the 24-hour rule. Measure weekly and keep a simple experiment log. Decision rule: adopt if lead time and rework improve and regulatory timing holds; adapt if rework falls but lead time does not; stop if high-risk timing breaches. Run a daily 10-minute board walk and a weekly service review with sales and compliance. Do not automate or buy tooling during the pilot. Capture qualitative feedback from specialists and reviewers. At the end, decide whether to extend to other classes and whether the board design needs to change. This makes the first improvement an intentional experiment, not a board launch.