Philippines staffing research
Testing whether vendor scorecard monitoring catches silent failures
Contents
A grounded offshore outsourcing operations note for offshore program owners: vendor scorecard with explicit evidence, decision rights, and a verified close.
Question and scope
The scope is one defined population of vendor scorecard cases observed from first request through verified close in the vendor scorecard. Exclude a reopened case only when the reopening did not create a new requirement; keep the exclusion count and reason. Write the primary measure and one supporting measure; a measure without a denominator or observation window is not ready. Record the exclusions in advance so a difficult case cannot be removed after the result is known. If the case moved between owners, include both owner periods in the review note and name the handoff time.
Write the primary question and one supporting question, then stop; a long list of questions usually hides an undefined unit. A count without a denominator is not a measurement, especially when the queue changes size during the day. Write the primary measure and one supporting measure; a measure without a denominator or observation window is not ready. Separate the operational question from the compliance question; this method does not certify either outcome. Keep the review note with the case so the next sampler does not have to reconstruct the decision from memory.
Population and unit
Include cases opened before the window but closed inside it only when the protocol says they belong to the population. Exclude cases opened outside the window only when the exclusion rule was written before collection. The start event should be the first recorded request, not the first time the team opened the case. Use the same case key across the queue export and the evidence extract to avoid double counting. When a value is missing, record the missing state and the reason instead of leaving an empty field in the extract.
The unit is one vendor scorecard case, from the opening request to the verified close, and linked events stay with that case. The population should include unresolved cases, not only closures, or the study will overstate completion. Define how a case that waits for vendor manager is counted: paused, open, or excluded, but not silently dropped. If a request was reopened after the window, keep it in the original population and report the later event separately. At Offshore Outsourcing Company, the vendor scorecard review should end with a dated note and a named owner for the next check.
Definitions and measures
A pause should have a reason, an owner, and a review date; otherwise it is an unowned case with a different label. Record the version of the vendor scorecard and the program management portal snapshot used for each case. A completeness measure should name the required fields and the evidence state; an overall percentage is not reproducible. If two reviewers disagree, preserve both classifications until the definition is clarified. If the evidence is sensitive, record the approved reference and access path rather than copying the content.
A pause should have a reason, an owner, and a review date; otherwise it is an unowned case with a different label. Keep the original text and the coded value together so a reviewer can check the classification. If a case is outside the scope rule, record the rule and the date of exclusion rather than removing it silently. State how duplicate, cancelled, and reopened cases enter the numerator and denominator. The note should distinguish what was observed, what was inferred, and what still needs an owner decision.
Data dictionary and evidence
The data dictionary should name the allowed values for status, exception reason, owner, and close evidence. Version the dictionary and report which version was used for each observation period. Run a five-case pilot before the full sample and revise any field that two reviewers interpret differently. Archive the dictionary with the study so a later reviewer can reproduce the categories. Record this decision in the study log with the case key, the review date, and the person who approved the classification.
The data dictionary should name the allowed values for status, exception reason, owner, and close evidence. Test the dictionary on a case with a missing role scope and a case with a corrected value. Keep the original evidence reference next to the coded value so the reviewer can verify the classification. Use a separate field for reviewer notes so the coded values stay comparable. Keep the evidence reference beside the coded value so a reviewer can test the same case without rebuilding the queue.
Use a pseudonymous case key and keep the identity crosswalk in an approved system with restricted access. Record the extraction time separately from the event time so a late entry is visible. Store sensitive evidence in the approved repository and keep only the reference in the analysis file. Pilot the dictionary with two reviewers and compare their classifications before the main sample. If the source changes after the observation, preserve the earlier value and add a dated note instead of replacing it.
Sampling and collection
Sample across the full observation window, including the days when the queue was busiest and the days when coverage changed. Collect the exception reason and the action taken before the close so the analysis can separate detection from resolution. A sample of recent closures can miss the oldest unresolved work, which is often the most informative. Record the sampling frame as an export with a date, filter, and row count. At Offshore Outsourcing Company, the reviewer should be able to explain this step to offshore program owner from the case record alone.
Sample across the full observation window, including the days when the queue was busiest and the days when coverage changed. A second reviewer should re-extract a small subsample and record disagreements before the full analysis. Stratify by risk, channel, and owner so the sample is not dominated by the easiest queue. Include at least one case from each owner in scope when the frame allows it. Use the same note in the case file and the study extract; do not create a second version in a personal document.
A convenience sample of recently closed cases will overrepresent easy work and underrepresent the tail that needs attention. Do not clean the data by filling missing values; preserve the missing state and report it as a result. If a stratum has fewer cases than planned, report the smaller count instead of replacing it with a convenience case. Include at least one case from each owner in scope when the frame allows it. When a case needs an exception, record the reason, the owner, and the date before continuing the review.
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. Keep descriptive findings separate from causal claims. Report the number of cases that changed status after the first extraction and how the change was handled. When a measure is based on a small sample, state the case count and avoid ranking owners by the result. Keep the measurement note short enough to read with the case and specific enough to support the reported access exceptions.
Compare coverage gap hours across owners only after checking the case mix, the channel, and the evidence standard. Keep descriptive findings separate from causal claims. Show the unresolved cases by owner, age, and dependency instead of reporting a single completion percentage. Show the age distribution and the open-case count by owner, not only the mean. If two reviewers disagree, preserve both classifications until the definition or the evidence is resolved.
Limitations
The method also cannot observe work that never entered the queue, which may be the most important missing population. The record may be incomplete or delayed, so the method cannot infer work that never entered the queue. Report the limits of the vendor scorecard data, including fields that were unavailable or changed during the window. If the queue changed during the window, explain how the change affects the denominator. Link the observation to the exact field in the vendor scorecard and to the quality sample that supports it.
The cited public sources frame recordkeeping, privacy, security, or control practice; they do not provide a local result. Small samples are unstable; report the range and the cases that create the variation. Record the response or access problems that prevented a case from being reviewed. Record the access problems that prevented a case from being reviewed. Do not let a summary written later replace the evidence that was available at the first decision.
Review and next action
A quality review should end with an owner, a date, and one testable change, not a list of intentions. If the action changes scope creep, record the approval from team lead before implementation. Report the action result even if the change did not work; a failed test is still evidence. Report a failed action with the same detail as a successful one so the team can learn from it. If the case moved between owners, include both owner periods in the review note and name the handoff time.
Record the decision and the next check so the study does not end as an archive. Name the owner, the review date, and the decision the study is expected to inform. Record the owner, the due date, and the exact change that will be tested at the next review. Use a short action log that names the change, the owner, the due date, and the measure that will show whether it worked. Keep the review note with the case so the next sampler does not have to reconstruct the decision from memory.