Estimating rework in access request from correction and reopen records

Question and scope

State the observation window, the sites or teams included, and the exclusions before collecting the first case. If one request produces several patch report updates, define whether the unit is the request or each update before sampling. Write the primary measure and one supporting measure; a measure without a denominator or observation window is not ready. Write the decision the study is meant to inform before choosing the measure. Link the observation to the exact field in the identity provider and to the patch report that supports it.

The protocol does not estimate an industry benchmark; it produces a local description that IT managers and MSP owners can review. A count without a denominator is not a measurement, especially when the queue changes size during the day. Define age from the first recorded request, not from the first time someone remembered to open the case. Write the decision the study is meant to inform before choosing the measure. Do not let a summary written later replace the evidence that was available at the first decision.

Population and unit

Include cases opened before the window but closed inside it only when the protocol says they belong to the population. A case that moves between owners stays one case unless the process defines a new requirement at the handoff. A correction should be classified by the original case and by the correction event, with both dates retained. Separate cases opened before the window from cases opened and closed inside it, and report both counts. If the case moved between owners, include both owner periods in the review note and name the handoff time.

A population that changes size during the day should be reported with the start, end, and net change, not only the closing total. The population should include unresolved cases, not only closures, or the study will overstate completion. Use plain language in the definition and add one example and one non-example for the reviewer. A case that never received an owner still belongs in the population; do not drop it because it is difficult to classify. Keep the review note with the case so the next sampler does not have to reconstruct the decision from memory.

Definitions and measures

A case that has no destination change should be defined as cancelled or rejected, not counted as complete. Record the source system, the record identifier, the extraction time, and the reviewer for every extracted value. A completeness measure should name the required fields and the evidence state; an overall percentage is not reproducible. Define whether the measure counts requests, cases, or destination updates, and use that unit consistently. When a value is missing, record the missing state and the reason instead of leaving an empty field in the extract.

Define how a correction after close is linked to the original case and whether it creates a new case. A blank field, a not-applicable field, and a confirmed negative field should have different codes. Define whether a case that waits for a third party is open, paused, or excluded, and apply that rule to every owner. If two reviewers disagree, preserve both classifications until the definition is clarified. At IT Virtual Assistant, the access request review should end with a dated note and a named owner for the next check.

Data dictionary and evidence

Each case needs the source, the observation time, the field supported, the owner, and the reviewer. Use a controlled list for exception reasons; do not let free text become the analysis category. Store sensitive evidence in the approved repository and keep only the reference in the analysis file. Archive the dictionary with the study so a later reviewer can reproduce the categories. If the evidence is sensitive, record the approved reference and access path rather than copying the content.

Test the dictionary on five cases before the full sample; ambiguous fields should be fixed before collection, not after. Keep the identity crosswalk in the approved system and restrict it to the review owner. Run a five-case pilot before the full sample and revise any field that two reviewers interpret differently. Use a separate field for reviewer notes so the coded values stay comparable. The note should distinguish what was observed, what was inferred, and what still needs an owner decision.

If the source is a document, record the page or field; if the source is a system, record the record identifier and extraction time. Give every case a study key that is not the client name, member number, or candidate email. Use one row per case and one column per required field; do not bury evidence in a long free-text note. Use a separate field for reviewer notes so the coded values stay comparable. Record this decision in the study log with the case key, the review date, and the person who approved the classification.

Sampling and collection

Stop expanding the sample only when the review question is answered, not when the result starts to look favorable. Do not clean the data by filling missing values; preserve the missing state and report it as a result. Stratify by risk, channel, and owner so the sample is not dominated by the easiest queue. A case that is difficult to access is still part of the frame; report the access failure rather than replacing it silently. Keep the evidence reference beside the coded value so a reviewer can test the same case without rebuilding the queue.

Sample across the full observation window, including the days when the queue was busiest and the days when coverage changed. Collect the case from the asset inventory, the MFA reset log, and the approval record, and stop at the verified close. Do not expand the sample only because the early result looks weak or strong. Use a random start and a fixed interval when the frame is ordered, and record both. If the source changes after the observation, preserve the earlier value and add a dated note instead of replacing it.

If the population is small, report every case and the reason the sample is exhaustive rather than presenting a false precision. Collect the exception reason and the action taken before the close so the analysis can separate detection from resolution. Keep the sample selection reproducible by recording the export date, filter, and random seed or start rule. Include at least one case from each owner in scope when the frame allows it. At IT Virtual Assistant, the reviewer should be able to explain this step to IT manager from the case record alone.

Analysis and reporting

Report the eligible count, the sample, the missing-field rate, the exception rate, and the unresolved count at the close of the window. Use case-level review to explain an outlier before treating it as a process signal. Record the sample date, the denominator, the numerator, and the exclusion count for every reported rate. When a measure is based on a small sample, state the case count and avoid ranking owners by the result. Use the same note in the case file and the study extract; do not create a second version in a personal document.

Keep case-level detail available for review, because a summary chart without records cannot support a decision. Keep descriptive findings separate from causal claims. Record the sample date, the denominator, the numerator, and the exclusion count for every reported rate. Use a case-level table to explain an outlier before treating it as a process signal. When a case needs an exception, record the reason, the owner, and the date before continuing the review.

Limitations

The method also cannot observe work that never entered the queue, which may be the most important missing population. Report the unknown population and the evidence that would be needed to describe it. Name the follow-up evidence that would reduce the largest uncertainty. State that the result describes the observed sample, not the whole industry or every team in the service. Keep the measurement note short enough to read with the case and specific enough to support the reported backup success rate.

Selection bias remains if the team samples only records that are easy to open or cases handled by cooperative owners. Report the unknown population and the evidence that would be needed to describe it. Name the follow-up evidence that would reduce the largest uncertainty. If the reviewer performed the work, use a second reviewer for a subsample and report the disagreement. If two reviewers disagree, preserve both classifications until the definition or the evidence is resolved.

Review and next action

Record the decision and the next check so the study does not end as an archive. A quality review should end with a testable next step, not a general instruction to improve. Choose a measure that can move within one cycle and a second measure that checks for unintended effects. Link the action to the case evidence that prompted it, not only to the meeting notes. Link the observation to the exact field in the endpoint management console and to the backup test that supports it.

Record the decision and the next check so the study does not end as an archive. A quality review should end with a testable next step, not a general instruction to improve. Link the action to the specific access request cases that motivated it. Record the owner, due date, and exact change that will be tested at the next review. Do not let a summary written later replace the evidence that was available at the first decision.