Start from the work that came back
A rework code list should be built from real returned work, not from a theory about why mistakes happen. Pull the tasks that were reopened, corrected, or sent back in the last month. Read the note that came with each return and the message that followed. The pattern in those notes is the raw material for the codes.
Separate a return from a new request. A client who changes their mind is creating new work, while a reviewer who rejects an output is sending work back. The two need different measures and different fixes. Coding a scope change as a quality error will make the process look worse than it is and hide the real cause.
Write a one-line description of each case before naming the code. The description should say what was wrong and what had to happen next. A short description keeps the coding grounded in evidence. It also helps a second person apply the same code later.
Choose five codes and define them
Most assistant queues can be described with five causes: unclear instruction, missing evidence, wrong source, tool or access failure, and judgment outside the role. Each code points to a different repair. An unclear instruction needs a better brief, while a wrong source needs a source map. Keep the list small enough to remember.
Write an example and a counterexample for each code. A return because the client's name was misspelled is a missing evidence or wrong source issue, depending on where the name came from. A return because the client wanted a different tone is a judgment or preference issue. The examples settle the boundary before the coding starts.
Add a code for cases that do not fit, but review it every week. A large unknown group means the list is incomplete or the descriptions are unclear. Do not force a case into a code just to keep the report tidy. The unknown group is a useful signal that the process needs another look.
Apply the code when work returns
Code the return at the moment it happens, not at the end of the month. The person who handled the return usually knows the reason and can record it in a few seconds. A monthly reconstruction will produce guesses. Put the code field on the same form that records the return.
Record the stage where the problem was found and the stage where it was created. A missing approval may be found at delivery but created at intake. The two stages tell different stories about where to invest. The creation stage is usually the better place to fix the process.
Keep the code separate from the person. The code describes the work and the process, not the character of the assistant. If a name is needed for coaching, store it in the private review record. The shared queue report should show causes, not a ranking of people.
Review the codes each week
Count the codes and compare the shares with the previous week. A single large group is easy to act on, while a flat distribution may need a broader review. Look for codes that are growing, not only the largest code. A small but rising cause can become the main problem next month.
Read a sample of the coded cases with a second reviewer. Check whether the code matches the description and the evidence. Disagreement is normal at first and usually points to a vague definition. Revise the definition rather than arguing about individual cases.
Compare the rework count with the volume of work. A rising count may reflect more work rather than worse quality. Report the share of completed items that came back, and separate the returns caused by the client from the returns caused by the process. Both numbers are needed for a fair view.
Connect each code to one fix
Give each code an owner and a likely repair. Unclear instruction may need a task card, missing evidence may need an intake field, and tool failure may need an access review. The owner should be the person who can change the cause, not the person who found the error. A code without a repair path becomes a label.
Change one thing and watch the code for two weeks. If unclear instruction falls after a new brief, the repair probably worked. If it does not move, the brief may not be reaching the work. Test the fix on the actual queue rather than in a meeting.
Retire a code only after the cause has disappeared for a sustained period. A quiet month may be a seasonal effect rather than a solved problem. Keep the definition in the archive so a later reviewer can understand old reports. The history is part of the quality record.
Keep the list stable enough to compare
Resist adding a new code for every unusual case. A stable list lets the team compare months and see whether a fix worked. Add a code only when a real group of cases cannot be described by the existing options. Record the date of the change and the reason.
Publish the current definitions where the team can find them. A code list in a manager's notebook will be applied differently by each person. Put the definitions beside the return form and link them in the weekly note. The same words should appear in the training and the report.
Review the list with the client when the service changes. A new deliverable may bring a new failure mode that the old codes cannot describe. Update the list before the first month of the new work. The codes should describe the current process, not the process from last year.
Sources
Open the original publisher and confirm the current version, definition, and scope before using a source for a business decision.
Turn the reading into a role brief
Bring the recurring tasks, tools, schedule, access limits, and owner-only decisions. Start with one work sample and one clear review path.
Plan a Philippines-based role