Pull System Design: Turn a Diagnosed Cause Into a Pilot Worth Running

Pull System Design sits in the Improve phase of RDMAICS. Its job is described plainly in the product itself: design a pull system where downstream demand triggers upstream work to reduce WIP and overproduction.

That matters because most queue problems are not capacity problems. Work arrives on a schedule that ignores what the next step can absorb. Batches pile up. People look busy. Nothing finishes faster. A pull system reverses the logic. Upstream work starts because downstream capacity opened, not because a calendar said so.

You reach for this tool after Analyse, not before. By then you should have a cause you believe in, such as a step that releases work in large batches regardless of downstream load. Pull System Design is where you convert that belief into a specific, testable change with a written trigger and a written limit.

Everything below uses the sample worksheet that ships with the tool. The case is fictional. It exists so you can see the shape of a good entry before you type your own.

The scenario is a back office intake and approval process. Work arrives from vendors through a portal, gets captured, throws exceptions that need human resolution, then moves to an approval queue. The diagnosed cause is simple. Release into approval happens in large batches. Exception handling starts and stops. Capture waits on a scheduled sweep.

Three pull signals are proposed, one for each pressure point. Each has a trigger, an upstream action, a WIP limit and an expected result. That is the entire design. Three rows.

The worksheet asks for five things per row. Treat each column as a question you must answer in one line.

The pull signal is the observable condition. In the sample, row one is "Approval queue < 3". That is a count you can see, not a feeling. Row two is "Exception resolved". Row three is "Vendor submission". Each one is something a person or a system can detect without debate.

The trigger point names the moment the signal fires. Row one fires "Below min". Row two fires "On close". Row three fires "On portal submit". Separating the signal from the trigger point sounds pedantic. It is not. A queue can sit below three for an hour. The trigger tells you whether you act at the crossing or on a check.

The upstream action is what happens next, stated as a verb. "Release next batch to approval". "Pull next exception from queue". "Auto-ingest begins". Then the WIP limit caps how much can be in flight. Finally the expected result records what you think will change, in plain words.

The three limits in the sample are 5, 10 and 0. They are not arbitrary and they are not the same kind of number.

Row one carries a limit of 5. Approval is the constrained step, so the loop stays tight. The signal fires when the approval queue drops below 3, and no more than 5 items sit in flight for that release loop. The expected result is "Steady flow, no overload".

Row two carries a limit of 10. Exception resolution is more variable, so the buffer is larger. The expected result is "No starvation", which tells you the risk here is the opposite of row one. Too tight a limit and the resolvers run dry.

Row three carries a limit of 0. That is the tell for a true one-piece flow. A vendor submits, auto-ingest begins, nothing queues. The expected result is "Just-in-time capture". A zero limit is a design statement, not a missing value.

Run the tool and it produces an improvement design flow. The result is built from the worksheet, and the sequence is taken from the current editable worksheet order.

From the sample rows, the flow reads as three steps. Step one is "Release next batch to approval" with the expected result "Steady flow, no overload". Step two is "Pull next exception from queue" with "No starvation". Step three is "Auto-ingest begins" with "Just-in-time capture".

Two things are worth noticing. First, the result strips away the signals and limits and shows only the actions and their expected results. That is the pilot brief. Anyone reading it can see what will change and what you expect to happen. Second, the order is yours. Reorder the worksheet rows and the flow reorders. The tool does not decide sequence for you.

The tool also offers an AI review of the result. Use it as a second reader on your own design, not as the design itself.

This is the part people skip. The expected result column is not decoration. It is your hypothesis, and it is what lets you size the gain before you spend anything.

Take row one. The expected result is "Steady flow, no overload". Before the pilot, write down how you would know. Count how often approval sits above the current batch size. Count how often it sits idle. You now have a before picture against a WIP limit of 5 and a trigger of "Below min".

Row two expects "No starvation". That is measurable as time with no exception in hand. Row three expects "Just-in-time capture" against a limit of 0, so the measure is elapsed time from portal submit to ingest start.

Three rows, three claims, three measures. That is a pilot you can run on one queue for a short window. If the claims hold, you scale. If they do not, you have lost very little, and you know which row was wrong.

The failures here are consistent across processes. Most of them show up in the worksheet before they show up in the work.

Vague signals are the first. "When it gets busy" is not a signal. "Approval queue < 3" is. If you cannot write a count or a discrete event, you do not yet have a pull signal.

Copying one limit across every row is the second. The sample uses 5, 10 and 0 for a reason. Different steps have different variability and different risks. A single number applied everywhere is a schedule in disguise.

The third is designing a pull signal for a cause you never diagnosed. If Analyse did not point at batching or overproduction, a pull system will not help. You will add ceremony to a process that had a different problem.

Be honest about the boundary. Pull System Design is a structured way to write down a change. It is not a simulation and it is not a forecast.

It will not tell you whether a WIP limit of 5 is correct. It records that you chose 5. It will not calculate throughput, cycle time, cost or savings, because it holds none of those inputs. The sample produces an improvement design flow, nothing more.

It will not validate your diagnosis. If the cause you carried out of Analyse was wrong, the tool will faithfully design a pull system for the wrong problem. It will not check whether your systems can emit the trigger you described, and it will not tell you whether people will respect the limit when the queue grows.

Use it for what it is. A disciplined place to turn a cause into three testable rows, so you can size the gain, run a small pilot, and only then commit. Then take the result into Control, where you decide how the limits get held.