Measuring cycle time for ticket intake from request to verified close

Question and scope

Write the primary question and one supporting question, then stop; a long list of questions usually hides an undefined unit. State how duplicate requests are identified and whether they are merged, linked, or counted separately. Define the start event, the stop event, the pause rule, and the treatment of a missing ticket intake before collecting data. Write the decision the study is meant to inform before choosing the measure. Use the same note in the case file and the study extract; do not create a second version in a personal document.

The question should name the unit, the start event, the stop event, and the decision the result is meant to inform. If the population is too small to sample, say so and report the complete set rather than implying a larger study. Record how corrections, reopens, and duplicate requests are treated so patch compliance cannot be inflated by reclassification. If the study is exploratory, label it exploratory and do not present the result as a stable baseline. When a case needs an exception, record the reason, the owner, and the date before continuing the review.

Population and unit

When several asset record updates belong to one request, state whether the request or each update is the unit and apply that rule consistently. If duplicate requests are merged, keep the duplicate count and the merge rule in the dataset. Define how a case that waits for MSP technician is counted: paused, open, or excluded, but not silently dropped. Report a case that moved between owners as one case with two owner periods unless the process creates a new requirement. Keep the measurement note short enough to read with the case and specific enough to support the reported backup success rate.

Test the unit definition on a case that crosses owners, a case that is still open, and a case that was reopened. The population should include unresolved cases, not only closures, or the study will overstate completion. Write the rule for a missing access request before the first case so the treatment is consistent. Report a case that moved between owners as one case with two owner periods unless the process creates a new requirement. If two reviewers disagree, preserve both classifications until the definition or the evidence is resolved.

Definitions and measures

Test each definition on a routine case, a missing-evidence case, and a case that crossed owners. Record the version of the access request and the identity provider snapshot used for each case. A duplicate request is a separate intake event even when it points to the same underlying need; record the link. A definition that depends on the reviewer’s memory is not reproducible enough for this study. Link the observation to the exact field in the identity provider and to the access request that supports it.

Define the controlled event as the moment a request for ticket intake becomes work, not the moment someone starts typing a note. Use a stable case key and a separate identity crosswalk stored in an approved system. A duplicate request is a separate intake event even when it points to the same underlying need; record the link. Record the pause rule and the person authorized to release a paused case. Do not let a summary written later replace the evidence that was available at the first decision.

Data dictionary and evidence

Mark missing, unavailable, and confirmed negative values separately; collapsing them hides the difference between no evidence and evidence of absence. Record the extraction time separately from the event time so a late entry is visible. Keep the original evidence reference next to the coded value so the reviewer can verify the classification. Keep the original request, the approval, and the destination value linked to the same key. If the case moved between owners, include both owner periods in the review note and name the handoff time.

Each case needs the source, the observation time, the field supported, the owner, and the reviewer. If a field is derived, record the formula and the source fields used to calculate it. Use one row per case and one column per required field; do not bury evidence in a long free-text note. Do not use a zero or an empty string to represent missing evidence. Keep the review note with the case so the next sampler does not have to reconstruct the decision from memory.

Record the version or date of the backup test and the vendor portal value so a later reviewer can see what was known at the first action. Use a controlled list for exception reasons; do not let free text become the analysis category. Use one row per case and one column per required field; do not bury evidence in a long free-text note. Archive the dictionary with the study so a later reviewer can reproduce the categories. When a value is missing, record the missing state and the reason instead of leaving an empty field in the extract.

Sampling and collection

Use consecutive ticket intake cases where possible, then stratify by owner, channel, and risk class. Collect the exception reason and the action taken before the close so the analysis can separate detection from resolution. If a stratum has fewer cases than planned, report the smaller count instead of replacing it with a convenience case. Record the sampling frame as an export with a date, filter, and row count. At IT Virtual Assistant, the ticket intake review should end with a dated note and a named owner for the next check.

Record the eligible count, the sample size, and every exclusion so another reviewer can reproduce the sample. Collect the exception reason and the action taken before the close so the analysis can separate detection from resolution. Use a random or systematic start rule and then take consecutive cases within each stratum. Do not let the reviewer choose the sample after seeing the results. If the evidence is sensitive, record the approved reference and access path rather than copying the content.

Use a random or systematic start rule for the first case, then take consecutive cases within each stratum. Keep the collection window and the number of collectors in the report; both affect how the result should be interpreted. Use a random or systematic start rule and then take consecutive cases within each stratum. Include at least one case from each owner in scope when the frame allows it. The note should distinguish what was observed, what was inferred, and what still needs an owner decision.

Analysis and reporting

For ticket intake, report the age distribution and the share of cases waiting on a named decision rather than a single average. Use case-level review to explain an outlier before treating it as a process signal. If the result is unstable, say which cases create the variation and what a larger sample would test. Report the number of cases that drive a small-sample result and the direction of the effect. Record this decision in the study log with the case key, the review date, and the person who approved the classification.

Separate observation from interpretation; a high completion rate on a small easy sample is not evidence of a strong control. If two measures disagree, report both and explain what each one counts. Report the number of cases that changed status after the first extraction and how the change was handled. Report the numerator, denominator, observation window, and exclusion count for each measure. Keep the evidence reference beside the coded value so a reviewer can test the same case without rebuilding the queue.

Limitations

The record may be incomplete, delayed, or maintained outside the team, so the method cannot infer missing work from a clean summary. Changes in staffing, access, or the ticketing system during the window can create a difference that is not a process effect. If the reviewer also performed the work, note the independence limitation and use a second reviewer for a subsample. Report the limits of the ticketing system data, including fields that were unavailable or changed. If the source changes after the observation, preserve the earlier value and add a dated note instead of replacing it.

Changes in definitions, staffing, or the asset inventory during the window can create a trend that is not a process effect. Changes in staffing, access, or the asset inventory during the window can create a difference that is not a process effect. Record the response or access problems that prevented a case from being reviewed. State that the result describes the observed sample, not the whole industry or every team in the service. At IT Virtual Assistant, the reviewer should be able to explain this step to end user from the case record alone.

Review and next action

Name the owner who will read the result and set a review date before the sample is collected. If the action changes failed backup, record the approval from MSP technician before implementation. If the action requires a policy or access change, route it to the owner and record the decision. Use a short action log that names the change, the owner, the due date, and the measure that will show whether it worked. Use the same note in the case file and the study extract; do not create a second version in a personal document.

Choose one next action: fix the source, simplify the access request, change the queue, adjust access, or pause the work until the owner decides. If the action changes unpatched device, record the approval from security lead before implementation. Choose a measure that can move within one cycle and a second measure that checks for unintended effects. Report a failed action with the same detail as a successful one so the team can learn from it. When a case needs an exception, record the reason, the owner, and the date before continuing the review.