I think this is what you are saying but to reword it for how we do it.
We have one "on duty" person each week/half-week/two-weeks. Their priorities are:
1. Support tickets.
2. Whatever they want (usually code cleanup).
They aren't expected to get any project work done. We also track the amount of time that they are spending on support tickets. If it is getting high we move more cleanup tasks into the regular project work cycle.
If you have oncall you can often co-locate these as well (oncall is priority 0).
The main risk is that if your support load gets high than there is no room for cleanup/automation which can become a feedback loop causing more support load. I haven't seen a good solution for this other than keeping track of the load and scheduling proper "project work" to address it when it gets too high.
The only sane approach. If someone is on support they also work to lessen the support load permanently. Recurring issues with no root cause analysis and fixes are deadly to a team.
We have one "on duty" person each week/half-week/two-weeks. Their priorities are:
1. Support tickets.
2. Whatever they want (usually code cleanup).
They aren't expected to get any project work done. We also track the amount of time that they are spending on support tickets. If it is getting high we move more cleanup tasks into the regular project work cycle.
If you have oncall you can often co-locate these as well (oncall is priority 0).
The main risk is that if your support load gets high than there is no room for cleanup/automation which can become a feedback loop causing more support load. I haven't seen a good solution for this other than keeping track of the load and scheduling proper "project work" to address it when it gets too high.