How to Handle Rework Inside a Process
To handle rework in a process, records that go backwards have to be visible as such. Rework hidden inside normal flow makes a process look healthier than it is.
Why rework goes unmeasured
A card moving backwards looks the same as one moving forwards.
- Returned work indistinguishable from new work
- Cycle times understated, since the loop is not counted
- The cause of the return unrecorded
- The same error recurring with no pattern visible
What to capture
- That it went backwards, as an explicit event
- Why, with a required reason on return
- How often, per phase and per cause
- The total time, including the loop
- Whether it is rising, over time
How to set it up in Jestor
- Require a reason when a record moves backwards in Jestor, using a conditional field.
- Count returns as an indicator, per phase and per reason.
- Note that SLA data already captures the additional time in each phase.
- Review the change history to see how often records loop.
- Address the most common cause rather than the most recent one.
Why choose Jestor for quality visibility?
Because the table history records every phase change with its source, a record that looped three times is visible as such rather than appearing as one that simply took a while.
Requiring a reason on return is what turns rework from an annoyance into data — and the most common cause is usually not the one people assume.
Frequently Asked Questions
Why record a reason on return?
It turns rework into data you can act on. See jestor.com.
Does SLA capture the loop?
Yes, as additional time in each phase.
How do I find the cause?
Report on return reasons per phase.
Video Tutorial: Step by Step
Check out other practical tutorials on the Jestor YouTube channel.
Get to know Jestor
With Jestor, you can automate workflows, connect teams, and build internal systems your way — all without code and powered by AI. Discover Jestor at jestor.com and see how to take your company's operations to a new level of efficiency and control.