Understanding renewal process and history

[Dennis]

I'm fairly new to TAM although I've many years of experience and exposure to management systems. In TAM (10.5), when our CSRs renew a policy (commercial lines for example), she creates a future app, completes the app and then moves the app to the current app. It's my understanding that the "old" current app is then moved to history along with the option to identify the changes and set a date.

Assuming that this is correct, we're moving the current app to history prior to the expiration of the policy (I think download does this auto-magically for us as well); We periodically need to issue a Cert on this in-force policy that has it's app moved to history - which you can't do; TAM Support instructed the CSR to use the current app and just change the dates, policy #, etc to issue the Cert.  I don't much care for this solution because it's just fraught with potential problems.

Am I not understanding more than what I already know I don't understand about how this process works? What are others doing in situations such as this to issue binders, certs, etc on policies that reside in history; I'm positive that we're not following the correct path on how this needs to be handled.


Thanks

Dennis

TAM 20 users 10.5 online

[Jeff Zylstra]

I believe that one of the utilities you run during night time utilities will automatically change the update the "future" app to the "current" app as of the renewal date.  Look into your night utilities setup and I think you'll see what I'm talking about.  Sorry I can't explain it better.  Someone else will pick up the ball for me here, but there is a way to automatically do this and still be able to print certs and other documents using the current app.

[Lance Bateman]

There are many things you can do from "history" such as invoice, endorse, claims, etc.  I'm currently using Vision, so not positive you can do certs, but I think you can.

[GeorgeW]

If a certificate already existed when you moved the futue app to current and the current to history, then that certificate is still there. The dates won't change on the certificate.

If you are adding a brand new certificate for a policy already in history, then I agree with Applied, you would have to use the current info and change that info once the certificate is created.

Just saw the other post while I was typing...you cannot add a certificate to a history policy like you can claims and invoicing

[Jim Jensen]

I see no issue with amending a certificate to the propert dates after you've created it if the policy was already sent to history. We've had to do the same for the opposite reason when the renewal is running late and hasn't been received yet.

If a certificate already existed when you moved the futue app to current and the current to history, then that certificate is still there. The dates won't change on the certificate.

If you are adding a brand new certificate for a policy already in history, then I agree with Applied, you would have to use the current info and change that info once the certificate is created.

Just saw the other post while I was typing...you cannot add a certificate to a history policy like you can claims and invoicing

[Dennis]

Thanks to all.  I didn't see anything in night utilities that infers that policies would be moved on renewal date - maybe I'm missing something;

It sounds like we're doing everything the correct way; The Cert did not exist and had to be created for the policy in history but using the policy that was soon to be in effect; My concern here is that in this scenario - what if coverages, etc are different between the two and the CSR makes a mistake;  If the cert exists already - then this isn't really an issue (as much);  I'm probably worrying about something that might not ever occur - however the owner pays me to worry for him so I want to make sure I'm giving him his money's worth!!

When I asked Applied about having an option to change when and how policies get moved to history - they suggested that we could add a letter to policy numbers so download would not match and then manually match the policies when the effective dates became current;  my only thought was that the person who suggested this has never worked in an agency;

Again - thanks to all. Hopefully I'll become knowledgeable enough to someday actually ANSWER someone's query and feel like I'm giving back.

regards

Dennis

[Lance Bateman]

I think what happens in night utilities is actually regarding endorsement requests, not policies (I could be wrong - I'm on Vision now).  You can set up endorsement requests to never delete or delete after a certain period (set on the endorsement request).  Night utilities then processes those.

[Jeff Zylstra]

I'm wondering if it is the same as "update change requests".  There is also a "process change requests" that exists in close day.  Since I don't do the utilities usually, I'm very rusty on what each one is.

[Alice]

Although worded differently, they mean the same...same end result.

[Jim Jensen]

Yes Night utilities will update pending changes, but not renewals. Renewals are strictly manual, unless downloaded. Dennis' concern about showing the proper coverages is correct and it needs to be paid attention to, but there are other item that you can't assume either - does the GL limit apply per policy, per location or per job? That doesn't pull it from the app. Are the WC limits statuatory or other? That has to been manually chosen as well. If creating a certificate from history, the workflow should include opening that application to very that the limits on the certificate are correct. Build a workflow/procedure that minimizes the chance of mistakes, check to make sure they are being done properly. If you have concerns about them being done properly, you can put in some procedural blocks, like making one get signed by a certain person.