SugarCRM for life insurance

[wheel]

Hi,

After quite a number of years of absence, I'm going to try setting up SugarCRM for a life insurance brokerage again. I've got it installed and running, am seeking some general guidance on a few things.

1) I have individual clients and 'associated' clients. Associated clients would be like mom and dad - individual insurance coverage, but when I pull up their record I want to see them as one entity. What do you see as the best way to set this up? Associate clients somehow? Or all clients as contacts and accounts, so couples are joined at the account level, but I have to have an account and a contact for individuals?

2) I wanted to add policy data at the personal level (depending on what I do in step 1). So an individual might have 1,2 or more policies. How do I set this up? I set up a 'policy' module with the fields I wanted (amount of insurance, company name, etc) then created a relationship between contacts and this policy module. That gave me an ajax slider for policy data just like I wanted, but when I click on the create button for the policy, I don't get the fields I created back in the module. I must be missing something fundamental - any pointers?

And lastly, a more general question. Would Sugar be appropriate to manage tens of thousands of insurance clients with an inbound call/sales center? Or are there any scale problems?

Thanks for any pointers! I appreciate it.

[Chris_C]

I'll take a first stab at this.

Hi,

After quite a number of years of absence, I'm going to try setting up SugarCRM for a life insurance brokerage again. I've got it installed and running, am seeking some general guidance on a few things.

1) I have individual clients and 'associated' clients. Associated clients would be like mom and dad - individual insurance coverage, but when I pull up their record I want to see them as one entity. What do you see as the best way to set this up? Associate clients somehow? Or all clients as contacts and accounts, so couples are joined at the account level, but I have to have an account and a contact for individuals?

Assuming the name of the insured person (or couple) is stored in the Account name, why not put the "associated clients" (beneficiaries?) as other Contacts in the Account ? The son Silvio, the daughter in law Francesca, etc. ? Or do the "associated clients" group together with the main client because each person is individually buying their own life insurance policies ?

2) I wanted to add policy data at the personal level (depending on what I do in step 1). So an individual might have 1,2 or more policies. How do I set this up? I set up a 'policy' module with the fields I wanted (amount of insurance, company name, etc) then created a relationship between contacts and this policy module. That gave me an ajax slider for policy data just like I wanted, but when I click on the create button for the policy, I don't get the fields I created back in the module. I must be missing something fundamental - any pointers?

I believe this might be due to the fact that you need to make sure your EditView, DetailView and ListView, and QuickCreate are all showing the fields you want to show. Just because you create fields etc. in EditView does NOT meant they carry over to DetailView, etc., by default.

To auto carry over the fields etc. from one view to the others, you have to enable this feature with a checkbox - on the Edit View, the checkbox is called "Sync to DetailView". Similarly on the QuickCreate there's the button "Copy from EditView".

And lastly, a more general question. Would Sugar be appropriate to manage tens of thousands of insurance clients with an inbound call/sales center? Or are there any scale problems?

I'm quite sure you could handle 50,000 clients in SugarCRM. You might want to hire SugarCRM to set this up for you so that it's pefect. I'd recommend using a few machines as the database servers, and a few machines as the front end web servers - in a cloud setup. Two 8-core CPU's and ~32 GB RAM on the apache/PHP web servers. Two 12-core CPU's and ~64GB RAM on the database servers.

[wheel]

Thanks Chris for your detailed reply.

To clarify #1, let me give an example of what I'm trying to track.

Household #1:
Dad - has $100,000 coverage
Mom has $100,000 coverage
So I need multiple contacts, but want somehow to track that mom and dad are one household

Household #2:
Person A - has $100,000 coverage.

It seems like Sugar is set up out of the box to have an Account = household in my definitions. Given how many times I will have a one to one (household #2) situation I guess I was wondering if there was a better design. Probably not.

Account has one to many contacts, contacts has one to many coverages/policy works. When i do an email newsletter I can just go to the account level.

Thanks for the tip on #2 - I can go from there.

[mrbarletta]

Hi Wheel...

Just a quick note to your general question

Yes SugarCRM can handle 100K customers easily. Largest customer has 330K contacts/ 400K Ops and +100 users and this is the hw specs.

Web server is Centos 6 Apache 2.2 / PHP 5.3 + APC - Dual Core 2.4 gHZ 8GB Ram
DB Server SQL Server 2005 32GB RAM - Quad Core Xeon - Intel Xtreme SD Disks

Its also linked to the ERP using Logic Hooks (no triggers at all) and some Night Schedulers for reports/info/ etc.

We run the reports using Jasper from a linked servers that log ships every 5 mins.. Reports is the slowest part..

good luck!

[Chris_C]

Thanks Chris for your detailed reply.

To clarify #1, let me give an example of what I'm trying to track.

Household #1:
Dad - has $100,000 coverage
Mom has $100,000 coverage
So I need multiple contacts, but want somehow to track that mom and dad are one household

Household #2:
Person A - has $100,000 coverage.

It seems like Sugar is set up out of the box to have an Account = household in my definitions. Given how many times I will have a one to one (household #2) situation I guess I was wondering if there was a better design. Probably not.

Account has one to many contacts, contacts has one to many coverages/policy works. When i do an email newsletter I can just go to the account level.

IF Account maps nicely to Household.. and one COULD say it does.. then, what you might want, is to modify Sugar to establish a brand new, optional relationship between Accounts (Households). This way - the client's Household 1 and 2 would be represented by Sugar Accounts 1 and 2.

Another way to do it - this might match your life insurance mindset - is to somehow add an optional subdivision to the Sugar Accounts module ( = your overall client). So you divide up a Sugar Account ( insurance client) into 1 or more households - which is just a list of Contacts (members of the household). Think of it like a big company organization - Coca Cola Marketing Dept with 200 contacts, and Coca Cola Corporate Executives with 20 contacts.

[wheel]

I used sugarcrm a number of years ago and eventually abandoned it. Had too many technical problems, didn't do what we needed, etc. I'm prepared to try it again and hope to use this thread to document much of what I'm doing - both so other life insurance companies can use this as well as so others can comment/assist.

Overall environment:
- life insurance brokerage with leads generated from website, to be inserted into database
- multiple agents, some offsite
- agents need access to leads
- administrators/service people need access to accounts and be able to track 1) sales process which can take months and 2) customer service questions which can take weeks and require followup.
- longerterm may integrate this with switchvox or something similiar (phone system).
- long term would also like to have email setup so that emails to clients/insurance companies are tracked and part of the database. Right now our email is kept on each pc. I think to do this properly I need to set up an email server and that's another job entirely.

At this time I'm going to defer the web to lead function (because there's some hiccups there I think). Of particular interest is the ability to do things like tracking the sales process,i.e. from application to submission to company to follow up, to getting medical information, etc etc etc. As well, there needs to be some interaction between service and sales, client calls in and requests service that may need multiple follow ups, or interaction with a salesperson (because salespeople are gov't licensed and service reps are not, and licensing is req'd for some functions). As well, need to track multiple follow up in the sales process.

Basic design:
this I think is where I'm going to start deviating from the base sugar config functions. From my initial readings, we're going to use:
Leads (from the web)
Leads have Activities Module. The Activities module will be used to track lead progress, re: when a lead is generated, a call will be made (this will be a 'Task' in the Activities module). If no contact is made, a follow up task(phone call) will be scheduled for the next appropriate contact time (i.e. perhaps tomorrow evening). If contact is made, notes will be inserted into the task, and again a new task will be formed if necessary.
If lead does not follow through, they will be marked dead. It would be nice if we had a system-wide setting to disable viewing of leads marked dead, and just a toggle to turn it them on when required.

Accounts will be households.
Accounts have Contacts.
Accounts have policies.
Contacts will be insureds, members of households.
If client is single, will have one account and one contact.
If say husband and wife are insured, there will be one account (using their last name) with two contacts - one for the husband, one for the wife.
Polices (defined below) will be attached to an account.

When an application is taken with a lead, they will be converted to a contact and an account. Unlike in many businesses, taking an application isn't a sale just yet - there's a month or two between taking an application and it actually becoming a sale.

During the underwriting process (because it takes a month or two to go from taking an insurance application to having a policy) we will track the progress with the Cases module. The intention is that the service reps will track and follow clients who have applied but do not have a policy yet issued. The time between an application being taken and a policy being issued is vital because there's lots of follow up with clients, medical people, insurance companies, and others. So an insurance company may send a request for more information which the service rep reads and either responds to, or they may send it on to a sales rep to handle.

Exact methodology here is still undefined in my mind - because we might have multiple service reps handling this, and they may want to forward the case/task on to everyone in sales or just one rep. I beleive sugar will let this happen, just don't know how yet.

Tasks during this timeframe and any future follow up with clients (i.e. change of banking information) will be done using Cases.

So a client record may look like this:
Account: Sugars (their last name).
Contact 1: Bob Sugars
Contact 2: Jane Sugars
Policy 1: Insurance policy 1 on Bob
Policy 2: Insurance policy 2 on Jane

Follow ups and client contact will be done at the account level using the Cases module. I.e. if Jane calls in, we will attach this as a note on the account.

Policy module:
I think I'm going to create a new module to handle policies. Policies will be attached to accounts rather than contacts, just for ease of admin - when I pull up an account I'll see a list of people in the household and a list of policies, rather than having to go into a contact to see the policies. Since I see this assignment as relatively arbitrary, it's just easier that way.

So I intend to go into the module builder and create a new module that tracks for each policy: contact person (if I can do that, don't know yet), and policy details like type of insurance, insurance company, and so on.


Initial setup:
I need to create some dropdowns like lists of insurance companies, policy types, and so on. Need to create a policy module. Need to edit all the various screens to add/delete fields. Need to turn off all the modules I won't be using, like opportunities. Also need to figure out how I can make it work so that my service rep can track/follow service items and share them with the sales reps.

[wheel]

I've started modifying screens to get rid of some stuff that is extraneous for a life insurance brokerage.

On my homepage the dashlets I have are:
Open tasks
open cases
my leads
email
my calls

Don't need the last two yet, don't have the email function working yet.

Next, along the top menu where it says 'sales' 'service' collaboration' etc, the only three I want are sales, support, and all. So I went to admin->configure grouped modules and removed all the modules except sales and support. Then in the sales tab I removed the opportunites module.

That puts the home page display to where it's just what I need.

Next stage hopefully today, starting to modify the fields on various screens like accounts, contacts, leads, to track the information specific to my processes.

[wheel]

After some consideration yesterday, Here's what I think I need in terms of fields:
Accounts:
Name
Phone office/home/mobile
Address/city/state/zip
do not call/email field
email

Client:
First/middle/last name
DOB

Lead:
First/middle/last name
Email
Phone

Policy:
Insurance Company
Policy Type
amount of insurance
policy number
policy issue date (important for tracking renewals on some insurance types)
Health class (regular/preferred)
Rating %
Rating $
(last two fields would allow me to track if client is given a rating as a percent of premium, or a flat extra. I may not actuallyuse these fields as I'm not certain I need to track them).

I think everything else I need to track can be done throught the attachments/documents/activities/tasks etc. i.e. scan and attach any documents, track any notes, any interaction with client.

Adding/deleting/moving these fields is easily done in Studio. What I don't know yet (may investigate today) is whether I can align or relate fields between leads/contacts/accounts. So if a Lead has a Date of Birth and I convert to a contact/account, will the date of birth field from the lead populate into the date of birth field in the contact. I don't know yet.

Oh, I also changed the list view for accounts and contacts to show various phone numbers and emails. that way if I'm looking at the accounts I've got the contact info right in the list without having to click through into individual records to get it.

Anyone have any comments if I'm going down the right road here?

[backe]

Hey Wheel,

Thanks for bringing this up.

I am about to set up a similar system.
Looks like you are on the right track. I have previously used salesforce.com and we used exactly the same setup.

I noticed that in sugar you can change the labels for account. I wonder if this will affect anything else if you change accounts to household, or if it better to keep it as it is.

We currently have another client database as well that I am looking to synchronize with the sugar database. Not sure yet what the easiest way forward would be, but noticed that there are several software that can do it. Would be interested to hear if anyone has done anything similar.

Please keep reporting on your progress. Will see if I can set up a new sugar for testing.

Cheers,
Backe

[wheel]

I will have to convert over some thousands of clients, but I'll like either have my developer write a script, or dump the existing database into a text file and import it that way (I'm assuming Sugar can somehow import text files). I'll likely lose a bunch of stuff in the conversion, that's OK for now, I can always have some add more details by hand later.

In terms of changing 'account' to household, I think it's easier to just have the reps understand that account=household. They need a basic understanding of the database structure anyway to run this.

I wanted to change the state to province and use a drop down. Doesn't look like that's possible without changing code unfortunately. I find that very odd, it's such a US-centric thing to put into a CRM. Unless someone else has a better idea, I'll just type in the province for now, in the state field. Same thing for postal code.

Decided to go this route after monkeying with lead/contact/account relationships. Looks like I need to keep the 'Primary Address' box and fields in these records, and that section is forcing me to use state and zip. I attempted to remove the 'primary address' block from the various pages and instead add fields like province/postal code, but this does not seem possible. Again, a bit odd, but I can make it work.

Part of the reason behind the push to make Sugar work is the integration with switchvox. Right now I'm using asterisknow for my voip but expect in the mid term to move to a switchvox/sugar combination.