Maharashtra Gram Sevak study materials
Maharashtra Gram Sevak study resources

Portal Deadline, Power Cuts and an OTP Call at Malkapur

Maharashtra Gram Sevak · Put your knowledge to work in context.

All case studies

Portal Deadline, Power Cuts and an OTP Call at Malkapur

The Gram Panchayat office of Malkapur has one laptop, one 4G dongle and no UPS. A state portal must receive 1,240 beneficiary records, with Aadhaar and bank details, by 20 January. Power is cut for about four hours daily and the dongle disconnects during the afternoon peak. Of the 300 records already entered, 38 were rejected by the portal for duplicate or invalid Aadhaar numbers, most typed from handwritten slips. A single operator handles data entry and the Sarpanch's phone receives the portal OTPs. The Block office wants a weekly progress figure, and three names on the old list are reported to be of deceased beneficiaries. At 4 p.m. a caller claiming to be a district coordinator says the portal needs the OTP read out to restore the Panchayat's login before the deadline, and the operator is alone in the office with the Sarpanch's phone on the desk.

1. Design a work plan that gets the 1,240 records in by 20 January despite power cuts and weak connectivity.

Read the worked answer

Separate capture from submission. Enter data into a local spreadsheet with fixed columns and validation, saving after every 25 records, and upload in batches during the reliable morning window. This means a power cut costs typing time, not verified data.

Size the task. With about 20 working days and roughly six productive hours a day given four hours of outage, a realistic rate after the first few days is 70 to 80 verified records a day, which covers 1,240 records with a buffer for the 38 rejections already logged. Set a daily target and note the actual figure on a board in the office so the weekly figure for the Block office is simply read off.

Rule out rework. Before typing, sort the paper slips by name and house number to catch duplicates; type Aadhaar numbers in a fixed 12-digit format with a repeat-entry check for every record; keep the source slip number against each row so an error can be traced back.

Protect the data. Keep a daily backup on a pen drive and, if permitted, a copy in the Panchayat's official e-mail; keep the laptop charged during the morning window and use a voltage stabiliser or an inverter if one is sanctioned. Print a fortnightly reconciliation of uploaded and pending records and file it, so the deadline is evidenced by a paper trail and not only by a screen.

2. What should the operator do about the 4 p.m. call?

Read the worked answer

Refuse to read out the OTP, and note the call. A portal OTP is a one-time credential equivalent to a signature. No genuine district coordinator needs it, because the coordinator's own login does not depend on the Panchayat's OTP. Pressure of a deadline is exactly the lever such a caller would use.

Steps in order: (1) Do not disclose the OTP; keep the Sarpanch's phone in hand. (2) Note the time, the number, the name given and what was asked for, in the office diary. (3) Call the Block office back on the number already on file, not on any number the caller supplies, and confirm whether any verification call was due; report the incident to the BDO and the Sarpanch the same day. (4) Ask that OTP receipt be restricted to the Sarpanch or a named alternate, and that the OTP never be shared verbally, not even within the office. (5) If any credential may have been compromised, change the portal password at once.

The wider point for the office: write a one-page rule that OTPs, passwords and Aadhaar numbers are not read out on the phone or shared on messaging groups, and paste it near the laptop. Data-entry staff handling Aadhaar and bank details are the obvious target of such calls, and the Gram Sevak should be able to show the Block office that the office has a rule and a register of such incidents.

3. How should the 38 rejected records and the three deceased beneficiaries be handled before resubmission?

Read the worked answer

Treat the two problems separately. Rejections are a data-quality issue; deceased beneficiaries are an eligibility issue, and mixing them into one correction file hides a serious matter inside a technical one.

Rejections: group the 38 by cause. For duplicate Aadhaar numbers, compare the digits against the source slip, because most are typing errors in a repeated digit; where two different persons genuinely share an Aadhaar number in the register, investigate before overwriting either. For invalid numbers, re-enter from the original Aadhaar copy with a second person reading out the digits, never from memory. Log each correction with the date and the initials of the person who corrected it, and resubmit in a batch so the portal's response is captured.

Deceased beneficiaries: do not silently delete. Record the report, obtain the family's confirmation or a death certificate reference, and put the deletion before the Gram Sabha or the competent committee with the minutes, then follow the scheme's procedure for substituting an eligible household. Deleting without a record invites a complaint that a benefit was diverted.

Finally, reconcile the final count: 1,240 minus deletions plus substitutions must equal what the portal accepts, and that reconciliation should go with the note to the Block office.