Policy Document Filing for Advisors: From PDF to Retrievable Record

A policy document reaches an advisor through one of three doors: the insurer's issuance email, a WhatsApp forward from the client who received it first, or a download link inside the principal's portal. All three doors open into the same room, and that room is a mailbox or a chat thread. Neither is a filing system. Neither has an index, a field structure, or a retention behaviour you control. WhatsApp media clears when the phone clears. Mailbox search finds only what you can remember a word from.

The failure is not that the document is lost. It is almost always still there. The failure is that it is not retrievable, which is a different property. Retrievable means you can produce the right document, for the right client, inside the time the situation allows. At claim intimation the situation allows minutes. When a client calls from a police station after a motor accident and asks whether his policy covers a hired driver, the answer "let me look and call you back in an hour" is the moment a four-policy household starts becoming a one-policy household at renewal.

A solo advisor running 150 to 400 policies across motor, health, term and personal accident does not have a records team. What the advisor has is a decision, taken once, about what happens in the four minutes after a PDF lands. This post is about those four minutes. The companion question, what you must keep and for how long because your principal will ask for it, is a separate discipline with its own logic. This one is narrower. This one is about being able to find.

A policy PDF is not a record. It is a container for a record you have not extracted yet. Extraction is what converts a file into something you can sort, filter and act on, and it is seven fields long for almost every retail policy a POSP places.

1. Insured name, exactly as the schedule spells it, not as you say it. "R. Krishnan" on the policy and "Krishnan Ramaswamy" in your notebook are two different people to every search you will ever run.
2. Policy number, in full, including the insurer's prefix blocks and any leading zeros. It is the only field in the document that is globally unique, and it is the first thing any servicing desk asks for.
3. Insurer and product name. "Health" is not a product. The insurer's actual product name is, because it determines which wording applies.
4. Cover and sum insured. For motor, the IDV and whether the cover is a package policy or a standalone third-party. For health, the sum insured and whether it is floater or individual. For term, the sum assured and the policy term.
5. Risk start and end dates, as dates, not as "one year from issue". The end date is the field your entire renewal book runs on.
6. Premium, gross, with the payment mode. Annual, half-yearly and monthly matter, because the mode decides how many times a year the client can lapse.
7. Your POS Code, as recorded on the issued schedule.

Seven is not an arbitrary number. It is the minimum set from which you can answer the four questions that generate every client call: am I covered for this, when does it expire, what did I pay, and who do I call. Anything beyond the seven (nominee, add-ons, deductible, no-claim bonus, endorsement history) is worth capturing when the product makes it load-bearing. The seven are not optional, because a record missing any one of them fails at precisely the moment it is needed.

The POS Code is the one field on the list that has nothing to do with the client and everything to do with you. It is the unique code your principal allocates when you pass the examination, and under the IRDAI Master Circular on Point of Sales Products and Persons, Life Insurance (IRDAI/LIFE/CIR/MISC/215/12/2019) every proposal must carry it, with the insurer responsible for recording it. The certificate and appointment letter follow within 15 days of your passing, and the code arrives with them.

Advisors treat the code as a formality of the proposal form. It is in fact the join key between your book and your income. Commission reaches you because the entity that engaged you can tie a policy to your code. Where the code is missing, mistyped, or belongs to the colleague who helped you fill the form on a busy afternoon, the policy exists, the client is covered, and you are not paid for it. You find out at the statement, weeks later, by which point the correction is a request rather than a fix.

This is why the code has to be read off the issued document rather than assumed from the proposal you submitted. The proposal is what you intended. The schedule is what the insurer recorded. Those two diverge more often than advisors expect, particularly on motor, where proposals are frequently keyed at a dealership or a branch and re-keyed at issuance.

If you file to a folder and rely on opening documents to find things, your filing system is your eyesight. If you name files properly, your filing system is your phone's search box, which is faster than you are and does not get tired at 9pm.

A file name that works has four parts, in this order:

• Expiry date first, as YYYY-MM-DD. Date first means the folder sorts itself chronologically without you doing anything, and your renewal book becomes a scroll rather than a query.
• Household tag. One tag per household, chosen once, never varied. "kulkarni" forever, not "kulkarni", then "kulkarni-sanjay", then "sanjay-k".
• Product shorthand. Two to four characters used consistently: mot, hlth, term, pa, home, trvl.
• Last four digits of the policy number. Enough to separate two motor policies in one household, short enough to type.

So 2027-03-14-kulkarni-mot-8821.pdf. Typing "kulkarni" returns the household. Typing "mot" returns the motor book. Typing "2027-03" returns March renewals. You have built three indexes and written no software.

Two rules make this survive contact with a real week. Never rename after filing, because a file renamed twice is a file you will later search for under the name it does not have. And never keep the insurer's original name: POLICY_SCHEDULE_17394822.pdf is meaningful inside the insurer's system and useless inside yours.

Consistency beats cleverness here by a wide margin. A mediocre convention applied to all 300 policies retrieves faster than an excellent convention applied to the 40 you filed while you were still enthusiastic about the convention.

A single copy on a phone is not a filing system. It is a single point of failure with a battery. The minimum workable structure is two copies in two places with different failure modes.

The working copy sits where you actually operate, which for most Indian advisors is the phone, because the client calls the phone and the WhatsApp forward arrives on the phone. The archive copy sits in cloud storage under the same folder structure and the same naming convention, synced rather than manually uploaded. Anything that requires a deliberate weekly upload gets skipped in the first busy week and never resumed.

Structure the archive by year of expiry, not year of issue. Your work is organised around expiry. The folder you open most often is next quarter's renewals. Issue date is a historical fact that never turns into a task.

Three constraints worth designing around:

• WhatsApp media is not storage. It compresses, it clears with the phone, and a document you can only reach by scrolling a chat thread from eleven months ago is not filed. Move the PDF out of WhatsApp on the day it arrives.
• The client's copy is not your copy. "The client has it" fails at exactly the moment the client is standing in a hospital admissions queue needing you to have it.
• A photograph of a printout is not a document. It cannot be searched, it crops, and it will be the version you have on the day you need the version you do not.

None of this needs a subscription or a system. It needs the archive to be the default destination and the phone to be the convenient mirror, rather than the other way round.

There is one honest test of a filing system and it costs ninety seconds.

Pick a client at random from a year ago. Not a recent one, not a favourite one. Start a timer. Produce the policy PDF, the sum insured, the expiry date and the premium. If you get there in ninety seconds without opening more than two files, your system works. If you find yourself scrolling a chat thread, opening PDFs to see which one is which, or calling the insurer's servicing desk, it does not, and what is missing is not effort. It is structure.

Run the test against the four situations that actually occur:

1. Claim intimation. The client calls from the site of the incident. You need the policy number, the insurer's claims line, and whether the peril is covered. This is the ninety-second case and it is not negotiable, because most of what the client will ever believe about your value is decided in this one call.
2. Renewal conversation. You need last year's premium and sum insured before you dial. An advisor who opens by asking the client what he paid last year has told the client the relationship is administrative.
3. Coverage question. You need the schedule and the specific add-ons on it, not the product brochure.
4. Your principal asks about a policy. You need the issued schedule with the POS Code visible on it.

The value of the test is that it fails cheaply. Failing it on a Tuesday afternoon costs ninety seconds and tells you which part of the structure is broken. Failing it during a claim call costs the household.

Every filing system that collapses collapses the same way. The document arrives at a bad moment, the advisor thinks "I will file it later", and later never has a trigger. Six weeks on, the working copy is three hundred unnamed PDFs in a downloads folder, and the effort to fix it is now large enough to defer permanently. "I will find it later" is not a decision to file later. It is a decision not to file, taken quietly.

The fix is that filing happens at receipt rather than at need, and it takes four minutes:

1. Open the PDF once, on arrival.
2. Pull the seven fields into whatever your book is, spreadsheet, notebook or app. One row.
3. Rename to the convention.
4. Save to the expiry-year folder. The sync handles the second copy.
5. Send the client a two-line acknowledgement carrying the policy number and the expiry date.

That fifth step costs thirty seconds, confirms to the client that someone is holding the record on his behalf, and is the cheapest persistency work available to an advisor.

Four minutes at receipt against forty minutes of archaeology during a claim is not a close trade. But the argument that actually moves advisors is not the time. It is that the four minutes happen while you are calm and the forty happen while your client is not.

The discipline also scales in one direction only. An advisor who files at receipt from policy number one can hold 400 policies without the book degrading. An advisor who files at need cannot reliably hold 80, and will never notice the ceiling, because a book you cannot retrieve from does not announce that it has stopped growing. It just quietly stops renewing.