The Ambiguous Digit: Speed, Accuracy and a Colleague's Shortcut
Ravneet joined a BPO in Mohali three weeks ago as a data-entry operator on a motor-insurance claims process. Her shift runs 1:00 pm to 9:30 pm. The client's SLA requires 120 scanned claim forms keyed per shift, with accuracy measured at 99.5% or better on a random audit of 200 fields, and any field that cannot be read with certainty must be flagged with a reason code rather than guessed. At 7:40 pm she has 34 forms left. Six contain a handwritten claim amount where one stroke joins the '1' to the '5', so it could be ₹1,500 or ₹7,500; two contain an 11-digit policy number where the format is 12 digits. Her team leader is on a client call and not answering chat. A senior colleague tells her to 'just key 7,500, the assessor will catch it' and to keep her flag count low because flags count against the team's quality score. On the next desk she also glimpses a scan: it is her neighbour's hospital discharge summary, which is not part of Ravneet's process.
1. Decide what to do with the 34 remaining forms, in priority order, and justify each choice against the SLA definitions rather than against feelings.
Read the worked answer
Read the numbers first. 99.5% on a 200-field audit allows one error in 200 fields - roughly one wrong field across several forms. Guessing six amounts and two policy numbers is eight near-certain errors concentrated in her own work, which fails the audit on its own and, worse, puts eight wrong claim values into a client system where an assessor may pay on them. The throughput target of 120 forms is a rate target; it does not override the accuracy clause that is measured in the same SLA.
Priority order.
- Key the 26 clean forms first - they carry no risk and protect most of the day's volume.
- Park the eight doubtful forms; for each, enter everything that is legible and apply the documented reason code for the illegible field (ambiguous/missing), with a one-line note of what the digit could be. A flagged field is a correct action in this process; it is not an error.
- Before logging off, send the team leader a short message or an incident ticket listing the eight form IDs and the reason - 'no reply on chat' is not permission, but an untraceable last-minute surprise is worse. If the escalation channel defines a backup TL, use it.
- Do not call or message the customer or the policyholder. Claim queries travel through the client, never from an operator's phone.
On the flag metric. A genuine ambiguity flag is not the same as a poor-quality key-in. Suppressing a flag to protect a team score converts a readable metric into a hidden defect - and the audit will find it.
2. Analyse the colleague's advice - 'the assessor will catch it' - and say how Ravneet should respond without turning it into a personal accusation.
Read the worked answer
Why the advice is wrong in this process. The assessor usually works from the keyed record, not the paper scan; if the scan is not attached or not re-opened, there is nothing to catch. Where the scan is visible, the assessor is checking claim admissibility, not re-reading handwriting against a keyed value - that comparison is exactly what the quality audit does, and it happens after the data has been used. Second, a deliberate guess is not an error in the audit sense; it is falsification of source data, which is treated far more seriously in an ITeS contract than an honest flag.
How to respond. Keep it procedural and unemotional: 'I can't read these six reliably, so I'm flagging them - that's what the reason codes are for,' and continue. Do not argue about the quality score in the aisle, and do not lecture a senior colleague in front of others.
What not to do. Do not reduce the flags just because the team average looks bad this month; massaging flags to match a colleague's practice is a bigger integrity problem than the original ambiguity. If the colleague is systematically advising new joiners to guess, that is a process issue to raise with the TL as a question ('what is the correct reason code when a digit is joined?'), not as a complaint about a person.
3. The neighbour's discharge summary on the next desk: state what Ravneet may and may not do, and connect the restriction to the actual obligations that bind her rather than to general politeness.
Read the worked answer
What binds her. She signed a confidentiality undertaking and works under the client's data-protection terms. Any personal health information processed in the client's systems is accessed only on a need-to-know basis for the assigned process, and every screen view and search is logged against her user ID. Employers also handle unauthorised access and disclosure under Indian law (the IT Act, 2000, and the DPDP Act, 2023 for personal data), but the practical consequence arrives first: an audit trail showing her ID looking at a non-assigned record is a disciplinary matter, not a grey area.
She may not: read further, zoom or scroll; take a photo or screenshot; search that name in the system; tell the neighbour or the family that she saw the file; discuss it in the canteen or in a WhatsApp group; ask the colleague at the next desk about it.
She may: look away and continue her own work. The only permitted follow-up exists if she sees the colleague mishandling data - photographing a screen, leaving a record open, taking a printout out of the floor - in which case she reports that behaviour through the security/compliance channel, again without naming the patient to anyone who does not need to know.
The judgement point. Wanting to help a neighbour is not a need-to-know justification. If she is worried about the neighbour's claim, the correct route is to tell the neighbour to contact their own insurer, never to check the status internally.