How should a shop-floor improvement mini program connect proposals, ownership, acceptance and rewards?
Do not begin by digitising a suggestion form or building a leaderboard. A useful first release takes one improvement through submission, review, ownership, execution, acceptance and reward settlement. The mini program should make short shop-floor actions easy; the administration console should govern rules, exceptions and review. Rewards must come from verified business events, not from a manually repaired score.
Who this is for
This guide is for manufacturers already collecting improvement ideas through meetings, paper, spreadsheets or chat groups. Management wants more participation, but also needs to know who owns each action, whether it was accepted and why a reward was issued.
Wavesteam's published lean-manufacturing mini-program case shows one implemented product boundary: employees submit issues, an industrial-engineering role reviews them, approved work enters an ownership pool, contributors record the action, the originator accepts the result and points are posted. An administration console governs assignment, adjustments, rewards and reporting. The case supports this workflow shape; it does not promise the same participation or financial result for another plant.
The Design Council's Double Diamond asks teams to understand and define the problem before developing and testing solutions at a small scale. Applied here, that means proving one improvement loop with real work before expanding across plants, award schemes and knowledge programmes.
Settle five operating decisions first
What qualifies as a proposal? Capture location, problem or opportunity, consequence, evidence, desired result and originator. Decide whether safety, maintenance and quality events use this workflow or must be transferred immediately to an existing controlled process.
Who decides whether it is actionable? Review should identify duplicates, request missing evidence, route specialist work and record a reason for rejection. One central administrator should not become the permanent bottleneck for every site and discipline.
Who may claim work? Open ownership suits collaborative tasks. Work requiring certification, a controlled area or a named duty holder should be assigned. Unclaimed and overdue work needs escalation.
Who accepts completion? A contributor's completion statement is not acceptance. Define evidence such as a site inspection, before-and-after records, a measurement or an observation period. Separate delivery and acceptance where the consequence or conflict of interest warrants it.
What earns a reward? Submission, a valid idea, implementation, timely completion, accepted benefit and reuse are different events. Choose the recipient, posting point, cap, reversal and appeal policy before coding.
One state model, two working surfaces
A first state model might include Draft, Under Review, Available or Assigned, In Progress, Awaiting Acceptance and Completed. Return for Information, Rejected, Withdrawn, Overdue, Reopened and Cancelled need explicit transitions rather than free-text notes.
| Stage | Mini program | Administration | Evidence to retain |
|---|---|---|---|
| Submit | Location, category, description, photo, intended result | Field and category rules | Original submission and time |
| Review | View decision, add information | Merge, return, route, approve | Decision, reason and reviewer |
| Own | Browse authorised work, claim | Assign, reassign, escalate | Owner, due date and changes |
| Execute | Progress and action evidence | Manage blockers | Measures, files and declaration |
| Accept | Confirm or explain rejection | Set acceptance role, reopen | Criteria, result and retest |
| Reward | View ledger and fulfilment | Rule versions and adjustments | Source event, value and approval |
The mobile surface should optimise photography, scanning, location selection, claiming, updating and confirmation. Organisation, bulk maintenance, duplicate handling, reward policy and cross-site analysis usually belong in the console. Both surfaces must use the same record and state.
Treat points as a ledger
Do not store only a total against each employee. Every credit, debit, hold, reversal and redemption should identify the proposal, task, acceptance or reward order that caused it, together with the rule version and operator. Merged ideas need an attribution rule. Reopened work may need a hold or reversal; silently editing the balance destroys trust.
If reward inventory, finance and fulfilment policies are not ready, deliver the points ledger first and postpone the store. A visible balance that cannot be reconciled or redeemed is worse than a deliberately limited first release.
Implementation path
Review one or two months of real proposals and identify duplicates, missing information, unowned work, acceptance disputes and reward corrections. Select one line or improvement theme. Define roles, evidence, transitions and time limits. Replay five to ten historical examples through a paper flow or prototype, including exceptions. Then configure the mini program, console, organisation sign-in, notifications and points ledger. Run for a complete improvement cycle before expanding.
The statement of work should name the collaboration platform, organisation synchronisation, attachment retention, notification ownership, operating roles, reward fulfilment, history migration and support boundary. For links to maintenance, quality or production software, distinguish read-only references, creation of linked work and state write-back.
Acceptance checklist
- One real proposal reaches accepted completion and a traceable points entry.
- Duplicate, incomplete, cross-team, unclaimed, overdue, failed-acceptance and reopened cases all have usable paths.
- A completion declaration does not bypass required acceptance.
- The balance can be recalculated from immutable entries; adjustments retain reason and approval.
- Mobile and administration surfaces show the same business state without spreadsheet repair.
- Organisation changes, leavers and delegation do not orphan work or expose unrelated records.
- Notification failure does not alter state or make the task undiscoverable.
- Reporting separates volume, valid proposals, completion time, rejection, reopening and reuse.
Common mistakes
Building the reward store first. Without verified source events, the team inherits gaming and reconciliation disputes.
Making every task open for claiming. Certification, safety responsibility and controlled areas still require assignment rules.
Auto-completing when evidence is uploaded. Upload proves an action was reported, not that the agreed result was achieved.
Treating proposal count as impact. Volume must be interpreted with validity, completion, acceptance and reuse.
Ongoing ownership
Clear unclaimed, overdue and awaiting-acceptance queues weekly. Review duplicate categories, point anomalies and disputes monthly. Revisit roles, evidence and reward policy quarterly. Before adding a plant, verify that locations, categories and accountable owners can be configured independently.
Sources
- Wavesteam: lean-manufacturing mini-program case — implemented proposal, review, ownership, acceptance, points and dual-surface workflow; not a performance promise for another organisation. Accessed September 14, 2026.
- Design Council: Framework for Innovation — discovery, definition, small-scale testing and iteration. Accessed September 14, 2026.
This guide addresses product scope and software acceptance. Safety, quality, employment incentives and financial treatment remain decisions for the relevant business owners.