Rework rate formula for policy services: whose error was it?

The rework rate formula is: rework rate = transactions that had to be corrected within a set window ÷ transactions finished, and first-time-right is one minus that rate. For policy servicing, three rules make the formula mean something. Each correction must be linked to the transaction it corrected, a later change to the same policy and field. Changes the customer asked for in between are not rework. And the rework is charged to the team that made the first transaction, not the team that fixed it. Without those rules the numbers point the wrong way: the team that fixes other teams' errors looks slow, and the team that makes them looks accurate. Botminds' Policy Servicing Analytics links every later change back to the transaction it corrected, counts the in-house work it caused and moves both to the stream of the team that started it, so rework is counted where it started.

The examples come from a fictional sample insurer, Ashcombe Mutual, over ten working days from 29 September, with two in-house teams and two outsourcers. Every person and policy named is fictional.

What does rework rate mean in insurance operations?

In insurance operations, rework rate is the share of finished transactions that someone had to redo because the first one was wrong. A redone endorsement, a reissued certificate, a reversed and reissued refund and a corrected mortgagee clause are all rework. A second endorsement on the same policy because the customer bought another car is not.

The measure matters because rework is invisible in most servicing reports. The redo appears as a new transaction in someone's queue, usually an in-house team's, and the calls, reprints and notices it causes appear as more new work. At the sample insurer, of the 1,964 items open in the Columbus service center on a Monday morning, 732 existed only because another team's transaction had been wrong.

How to calculate rework rate: link each correction back to its source

Calculate it from the corrections up, not the transactions down. Start from every change keyed to a policy, look back within the rework window for an earlier transaction that touched the same policy and the same field, check whether a new customer request arrived in between, and if not, link the two. The earlier transaction is the error; the later one is the rework.

The rework trail: what the customer asked, what the vendor keyed, what the in-house team changed

The exclusion that keeps it fair: changes the customer asked for

A later change is rework only if nobody asked for it. If the customer emails on Tuesday to add a car from Monday and calls on Wednesday to change the date to Friday, the second change is a new request, and the first transaction was right. The test is whether a new customer request sits between the two transactions; at the sample insurer, one morning's run excluded four later changes on that ground.

Regulators draw a related line in the other direction. New Jersey's examiners describe how corrections affect their error ratios: "In the event that the Company corrected an error as a result of a consumer complaint or due to the examiners' findings, the error is included in the error ratio. If the Company corrects an error independent of a complaint or NJDBI intervention, the error is not included in the error ratios" (New Jersey Department of Banking and Insurance, market conduct examination of Colonial Penn Insurance Company, report adopted 3 January 2003). An error the company finds and fixes on its own is treated differently from one a customer had to complain about. Catching rework the morning after the transaction, rather than at claim time, is the internal version of the same incentive.

Whose error was it? Why the team that fixes errors looks slow

Rework counted against the team that does it punishes the wrong team twice: its queue grows and its turnaround slows, while the team that caused the work reports a clean month. At the sample insurer, switching on "count rework where it started" moves 614 items from Columbus's queue to the outsourcer that caused them and 118 to the other outsourcer; Columbus's own open work is 1,232 items, not 1,964.

The same move changes the vendors' accuracy. Harrowfield's badge goes from 99.2%, its own reported figure, to 95.7% measured, and its stream swells by 614 items. Nothing about the work changed; only the attribution did. That is why the contract should say who measures and how rework is attributed, a point taken up in the SLA penalty calculation formula.

Count what the error caused, not just the redo

A wrong transaction costs more than its own redo. The customer calls to ask what happened, documents are reprinted, a bill is reversed, a lienholder is notified, and sometimes a claim waits. Counting those follow-on items is what turns a rework rate into a cost. In the sample, Harrowfield's 181 wrong transactions in ten working days caused 433 more items of in-house work, about 2.4 for each.

The single traced case shows the weight of one error. The customer asked on Monday to add her new car from that day, financed through a credit union; the vendor keyed it from Thursday with no lienholder; she was rear-ended on Tuesday evening; the claim was held because the car was not on the policy on the date of loss. Correcting it took a redo, two calls, a reprint and a lienholder notice, 74 minutes in Columbus, and the claim hold lasted 27 hours.

Rework that reaches a claim: why some errors cannot wait for the vendor

Some rework has to be done by whoever is closest, at once, and the rate should still be charged to the team that caused it. Of the 268 vendor transactions the sample insurer's teams redid in ten working days, 6 had already touched a claim. Its rule is that anything touching a claim, a lienholder or a cancellation date is corrected in-house the same day and charged to the vendor; everything else goes back to the vendor, which has one business day to fix it.

The rule keeps two numbers apart that are often merged. Who fixes an error is an operational decision about speed and risk; whose error it was is a measurement question. A rework rate that follows the fixer would credit the vendor every time the insurer stepped in to protect a customer, which is the opposite of what the measure is for. Charging the source also gives the vendor the information it needs: of the sample outsourcer's 147 wrong endorsements, 109 came from 14 processors in their first two weeks, and its accuracy notice asks for a second check on their work until they reach 98% for two weeks.

First time right: the formula and the rate

First-time-right is the share of transactions that never needed correcting: first-time-right = 1 − rework rate. On the sample, the four teams' first-time-right rates over the two weeks were 95.7% and 97.2% for the outsourcers and 98.6% and 99.0% in-house. The rate is the same number as measured accuracy, which is why it should be measured the same way for every team, in-house and outsourced, before any of them is compared.

The rate is more useful split by request type and by tenure. The sample outsourcer's endorsements ran at 94.1% first-time-right while its billing ran at 98.0%. Within endorsements, 14 processors who had started on 28 September were at 82.2% and 32 tenured processors at 98.0%. A first-time-right rate reported for the team alone would have hidden both.

Disputes: the vendor may object, a person decides

A rework count that the team being charged cannot challenge will not be trusted, so every charged rework should be open to dispute for a fixed window. At the sample insurer the vendor has five business days; the quality analyst confirms or removes the charge, and the credit and the accuracy figure move with the ruling.

Is the rework rate formula the same as the defect rate?

Not quite. A defect rate counts errors found by inspecting output, whether or not anyone fixed them; a rework rate counts outputs that were actually redone. In servicing the two converge when every transaction is checked against its request and every later correction is linked, because the defects found and the reworks done then describe the same transactions from two sides. They diverge when a defect is found but never fixed, which is its own problem, or when a rework is done without anyone noting why. The term is also used in manufacturing and software delivery, with different units, so a contract should define it in its own words.

The definitions on this page are settings in the solution: a ten-business-day window, customer-requested changes excluded, follow-on items counted, five business days to dispute. Changes are saved as a draft and approved by the head of policy services. To score the transactions behind the rework, see the transaction quality audit checklist; to see the rework trail on sample data, start from Policy Servicing Analytics.

Questions people ask

How long should the rework window be?

Long enough to catch errors that surface at the next customer contact, short enough that a later change is plausibly a correction. The sample insurer uses ten business days. Its fully traced example surfaced within three days, through a held claim; a longer window catches errors that surface later and risks charging genuine new requests.

Does a change the customer asked for count as rework?

No. If a new customer request arrives between the two transactions, the later change answers that request and the first transaction stands. A call that only asks why something happened, like the sample customer's call about her held claim, is not a new request.

What are good quality metrics for an insurance BPO?

Measured accuracy on every transaction, rework rate charged to the vendor, follow-on items caused, corrections fixed within the contract's clock and accuracy by tenure. On the sample, the vendor fixed 9 of 11 sent-back corrections within its one-business-day clock.

How is rework rate different from error rate in an audit?

An audit's error rate comes from reviewing a sample of files against the rules; a rework rate comes from what actually had to be redone in the whole population. An audit can find errors nobody has fixed yet, and rework can reveal errors no audit sampled. Running both on the same definitions lets them check each other.

Can rework be charged to an outsourcer under the contract?

Only if the contract says so. The sample contract states that the insurer measures accuracy on completed work and that a transaction the insurer must redo within ten business days is not accurate, which puts each charged rework into the service credit calculation.