Why employee suggestion programs fail, and the elements that make one work

Employee suggestion programs fail on the reply, not on the submission. Ideas arrive, no decision comes back inside a window anybody considers reasonable, and participation collapses inside two quarters. Every other cause on this page is downstream of that one, and every fix that works is a fix to how fast and how honestly the organization answers.

The literature on suggestion schemes is oddly quiet about this, because most of it is written by people selling submission tools. Submission is the part that is already solved. Nobody in a company of four hundred people is struggling to write down that the changeover procedure on line three wastes eleven minutes. They are struggling to believe that writing it down will produce anything.

Why do employee suggestion programs fail?

Seven failure modes account for nearly all of it, and they are not equally common. The first one on this list causes more dead programs than the other six combined. Each has a symptom that shows up before the program is obviously dead, which is the useful part, because all of them are cheaper to fix at the symptom stage.

Read the middle column on its own. Six of the seven symptoms are visible in the program's own data within a quarter, and almost nobody looks, because the metric that gets reported upward is total submissions. Total submissions is the one number that hides all of this: it stays flat while the mix underneath shifts from repeat contributors to a thinning stream of first-timers who will not come back.

A formal employee suggestion program is likely to fail when

A formal program is likely to fail when the organization commits to responding and is not resourced to do it. That is the precondition. Every other risk factor is a variation on it: no named owner, no published turnaround, a review body that meets when convenient, or a launch sized for a company twice as engaged as yours actually is.

The trap is specific to formal programs and worth naming, because informality protects you from it. An unstructured culture where people mention improvements to their manager makes no promise, so it cannot break one. The moment you launch a program with a logo and an all-hands announcement, you have made a public commitment to every employee that their submission will be handled. Breaking that commitment costs more trust than never having asked for ideas, and it does the damage in front of an audience.

So the honest sizing question before launch is not how many suggestions you hope to get. It is how many you can genuinely answer, with reasons, every week, given the people you have. If that number is eight, launch something that will produce roughly eight. A narrow campaign in one department that works is worth more than a company-wide program that buries itself in week three.

The elements for a successful employee suggestion program are

Five elements, and they are all on the response side rather than the collection side: a named owner, a published response window that is actually met, a reason attached to every rejection, an implementation owner and date assigned at approval, and public credit to the suggester when something ships.

• A named owner. One person whose job description includes the queue. Shared inboxes have no owner by construction, which is why they are where programs go to die.
• A published response window. Two weeks to a first decision is a reasonable promise for most organizations. The number matters far less than publishing one and hitting it. A kept two-week promise beats a missed 48-hour one by a wide margin.
• Reasons on every no. Three minutes of a reviewer's time. An unexplained rejection does not just lose that idea, it loses that person and usually their immediate team, because they will hear about it.
• An owner and a date at approval. The gap between approved and shipped is where programs lose credibility most quietly. An approval with no date is a polite no with extra steps.
• Public credit. One shipped improvement with the suggester named recruits more submissions than any amount of internal marketing, because it is the only evidence anybody actually trusts.

Notice what is not on that list. No cash award scheme, no gamification, no software. Those are all real things you can add, and none of them substitutes for the five above. A payout scheme layered on a program that does not reply just adds a dispute about valuation to a problem of trust.

How fast do you actually have to respond?

Acknowledge automatically the same day, and give a first decision inside two weeks. Same-day acknowledgment costs nothing because a system sends it, and it removes the immediate worry that the submission went nowhere. The two-week decision is the promise that carries real cost, and it is the one that determines whether a second idea ever arrives.

The reason the window matters more than its length is that employees are not measuring you against a benchmark. They are measuring you against what you said. A program that publishes four weeks and answers in three feels responsive. One that publishes 48 hours and answers in nine days feels broken, despite being three times faster. Set the number you can defend on your worst week, not your best.

What happens in year two, when the queue dries up

Volume falls in the second year of nearly every suggestion program, and it usually gets blamed on culture or on the tool. It is neither. The obvious improvements were submitted in the first few months, because they were already sitting in people's heads waiting for somewhere to go. Once that backlog is cleared, the program has nothing that produces new observations, so the queue thins.

This is a structural limit rather than a performance problem. A suggestion program is a collection mechanism, and collection can only ever surface what somebody already noticed. There is no divergence step anywhere in the process. Nothing in the workflow asks a group to look at a problem from an angle they had not considered, which is the thing that generates ideas that were not already there.

Two responses work. The first is campaigns: instead of a permanently open box, run time-boxed drives against a specific stated problem, which gives people a reason to look at something fresh rather than waiting to notice something. The second is to add a generation step in front of the queue, so options get produced deliberately rather than harvested. Running one problem through a structured technique like reverse brainstorming or brainwriting with the team closest to it will produce more usable material in forty minutes than the open box produces in a slow month.

Does software fix any of this?

Software fixes the administration and none of the trust. Routing, deduplication, status tracking and reporting are genuine work once you are past a few hundred employees, and a platform does them well. What a platform cannot do is write the reasoned rejection, ship the approved idea, or care that the review meeting keeps slipping.

The honest way to decide is to look at which column of the failure table your program is dying in. If decision times are lengthening because nobody can see what is in the queue, tooling helps immediately. If decision times are lengthening because the review group has three other priorities, a dashboard will simply make that visible on a chart, which is useful for the conversation and does nothing for the employees waiting. It is worth being straight about which of those you have before a procurement cycle starts, and an outside read that scores how your culture and processes actually handle commitments like this is often more diagnostic than another tool evaluation. We cover what the category does and does not do on idea management software, with the numbers on idea management software pricing.

How do you restart a program that already died?

Do not relaunch the same thing with a new name. Everyone remembers, and a second broken promise is much harder to recover from than the first. Restart small and visibly: pick one department, one stated problem, a closing date, and a commitment to answer every submission within two weeks with a reason.

Then clear the old debt before you ask for anything new. Go through whatever is left in the previous queue and reply to all of it, including the ideas that are now two years stale, saying plainly what happened and that nothing came back. That exercise is uncomfortable and it is the single most effective thing you can do, because the people who submitted are precisely the people you need in the new program, and they are the only ones with direct evidence that it did not work last time.

Ship one thing from the new campaign fast, even a small one, and name the person who suggested it. The whole rebuild rests on producing a single piece of evidence that contradicts what everyone already believes. The practical structure for running the new version, stage by stage with who owns what, is on our employee suggestion program page, and the method for comparing what comes back is idea prioritization.