Pre-installation checklist, anyone?

[bvjones59]

Hello all,
As we prepare to take the plunge into CiviCRM implementation, I'm wondering if anyone out there has developed a questionnaire or series of checklists of things we need to have decided on, in order to set it up to best advantage? I am finding some items tucked into the instruction book: be sure you've considered XYZ... But I'm thinking maybe a more detailed questionnaire has been compiled by somebody who does these installs?

My group has a pretty decent grasp of what it wants, but getting all those little details organized is daunting. And I know we need all of that to successfully migrate our existing data and start doing all the extra things we cannot do now.

Suggestions?

[Coleman Watts]

Knowing what you want is probably the biggest thing, and it sounds like you do.
I'm not sure if it's possible to create a "one-size-fits-all" checklist for setting up CiviCRM.
There aren't too many decisions you make now that you can't take back later (although doing so will always cost some time & money). For example, if you pick the wrong host, you can switch later.
But mapping your data is one decision it would be very hard to do over. So planning out how you will use contact types, groups, tags, smart groups, and custom data now (and getting it right) can save you a lot of headache in the future.
Some resources on that:
http://book.civicrm.org/user/current/organising-your-data/overview/
http://civiteacher.com/ (see Groups vs Tags video at the bottom of the page)

[bvjones59]

So planning out how you will use contact types, groups, tags, smart groups, and custom data now (and getting it right) can save you a lot of headache in the future.

EXACTLY!  And this is where I was hoping somebody might have a series of questions. We have a sandbox installed and our webmaster can work out the more technical kinds of details, but getting all the types and groups and tags and so on... Much more complicated than our current setup in Wild Apricot. We have all of those basics which will be imported from there, but there's so much more we want to do. It is overwhelming trying to figure out what we want. Drawing lots of web-style relational maps....

I have looked at those book pages. One example is where it mentions member types. In our current setup, we have over a dozen "member types" mainly because we were unable to create a simple type for "monthly donor" with a drop-down to select how much per month. It looks like maybe we can avoid that in CiviMember?

But we have never before really done a lot of tracking of communications, or of volunteer staff. Events have never been integrated. So that part is all new, and figuring out what sorts of tags and such would be easier with a few guided questions, I'm thinking.

[Upperholme]

It can be pretty daunting trying to get your head around all of the options. As you have a test system installed I would encourage you to spend time with that and the user/admin guide in order to gain a better understanding of what you can do (and what you can't). There is plenty of help and guidance available through this forum as well, and of course if you have the budget you can hire some professional expertise from one of the many partners listed at https://civicrm.org/providers

In terms of membership types, CiviCRM gives you the option to create a membership type that has a monthly cycle, which might well suit your needs. Set it up in your sandbox and test it out with the rest of your workflow - payment processor, contribution pages, etc., and see if it works for you.

How, and whether, you use contact types, groups and tags is as much a matter of personal preference as it is driven by your business processes and workflows. If you want to use targeted bulk mailings then you'll need to use groups for that. Take care when using groups for classification/categorisation and for mailings, as when someone unsubscribes form a mailing list, they are removing themselves from your group, so if that same group is used for categorisation, or is used for access control purposes, you can quickly get into a mess. Tags are lightweight and can be used for a whole range of purposes.

If you want to collect custom data on some types of contacts but not others then using different contact types, and perhaps sub-types, is your friend there.

[bvjones59]

I'm a really visual person... maybe what I am needing is more of a diagram or flowchart that illustrates what you just suggested, showing how types relate to groups relate to tags, and how all relate to - say - organizations or tasks or projects. I'll keep at it, and see if I can get it sorted out a bit. Hard to even ask coherent questions sometimes!

[Upperholme]

In short - they don't. what I mean is that contact types don't particularly relate to groups or tags, or tags to groups, unless you want them to.

To explain more, Civi comes with three contact types out of the box (Individuals, Households and Organisations). Pretty self explanatory. You might choose to simply go with those. You might find that you have some clear groupings for different types of individuals, in that for (students, lets say) you might need to collect different data than for pensioners, and you want to have different sets of custom fields for each. In that case you can create sub-types for students and pensioners, and then link the custom fields to those particular sub-types, so your screens don't get cluttered with pensioner specific fields for individuals that aren't pensioners.

Pensioners might be classified into various groups, and you could use groups or smart groups to do that, especially if you want to use those groups for targeted mailings or for access control. Otherwise you could also use tags. Or you might want to use tags in a different way. It's up to you.

I think the place to start is to understand what your real data needs to look like in order for you to achieve your goals, and then everything will flow from that.

[bvjones59]

Thanks Upperholme!

So what I am calling "categories" presently, would probably be sub-types:
Member, Donor, Subscriber, Volunteer

If I break them down further, would I be getting into the realm of tags? or are they Sub-sub-types? For instance, members can be annual or monthly, to either legal or general fund. Donors we might flag as being large or small, and we have considered an "automatic" membership for over a certain size contribution. Subscribers might get a mailed newsletter, email alerts, and/or just general blogs and newsletters, and only the mailed newsletter comes with a cost.

I think I get the Groups... What I've jotted down so far are things that might involve access to a certain area on our website, or allow our marketing team to target an email or snail mail campaign.

I still need to read up more on the difference between groups and smart groups.

[Upperholme]

At first glance - and without knowing your organisation or its constituencies, my guess would be that a single individual could potentially fit into most or all of those categories.

Certainly members will be defined as any contact that has a valid membership, so any custom data specific to the membership could be associated with the membership record rather than the contact record if that suits your requirement, so a smart group based on membership type and status could be used to categorise your members.

Likewise Donors will presumably be specified as a contact that has made a donation. As you have donation (contribution) records in the system you could categorise donors as a smart group based on whether the contact has made a donation.

If we assume that a subscriber has opted into a mailing list, then that mailing list group defines contacts as subscribers. If they have paid a fee for the mailed newsletter, then you'll be able to find them and place them automatically in a smart group based on that transaction.

I'd guess that you would probably want to collect some custom data on Volunteers, so that might be useful as a contact sub-type, depending on your workflows and data requirements.

If you want to control access to content then you can do that easily in Drupal via memberships and groups (not sure about Wordpress or Joomla!?).

If you have monthly memberships and annual memberships, these could be different membership types that your contacts could sign up for. And smart groups (which are effectively saved searches) could help you to find, list and manage them.

A smart group, because it is a search, is dynamic: contacts will fall in or out of the group based on the search criteria. You can also manually add or remove contacts from a smart group, and that overrides the search criteria.

You could again use smart groups to identify large donors (the saved search might find all contacts with a donation of €1000 or over made in the last year, for example). Likewise small donors.

Hope this helps.

[bvjones59]

Okay, so it sounds like much of what I'm describing right now could be handled through these Smart Groups (saved searches.)

The membership specifications happen as a result of their interactions with the membership module and they will get flagged through that as monthly or annual donors in their records. If they make a donation, that gets flagged in their record too, right? So I could look up Harry Hoo and find out when he joined and what he's given, and create Smart Groups that let me find everybody else who is a member who gave X amount last year, for instance?

So... EVERYBODY is a Contact. In my org, most will be Individuals. Then depending on things THEY choose (become a member, make a donation, sign up to volunteer) they get put into Groups? Or are they just getting TAGGED and then I create a Smart Group for certain tags?

Yes, volunteers will require some other consideration. I'm thinking that Civi-Case may actually prove very helpful with volunteer management... at least in terms of receiving applications, vetting them, assigning them to a project and project manager, and making sure that we don't drop any balls. That will be another whole thread, probably!  Instructions are really good there, though, so hopefully I'll get further along before I start bugging you guys.

Thanks for your patience.

[Coleman Watts]

In general you want to minimize 2 things:
- Manual work on your part
- Redundant data

For example, if you set about tagging everyone who has given money with a "donor" tag, then you are both creating more work for yourself and opening yourself up to data-integrity problems. Because what happens if you forget to tag someone as a "donor" but they've given money? This is an example of redundant data because being a donor is already evident in the fact that they have a contribution record. You can see this on their contact summary page. You can search for donors and create reports on them. There is no need to tag them as well. If you really want to you can create a smart group for them (which isn't manual work to keep up and isn't redundant because it's simply a reference to data, not a separate store of data) but you may not even need to do that.

The golden rule is "don't store the same information in 2 places". People are donors by virtue of the fact that they have a contribution record. People are members by virtue of the fact that they have an active membership record. The list goes on (people are Americans by virtue of the fact they have an address in the US).

I only consider using groups, tags, and contact subtypes if there is absolutely no other way of getting at that data. Smart groups are nice for creating automatic mailing lists (e.g. a smart group of everyone who attended a conference). Tags are simplistic and I avoid them for anything other than sort term "throw-away" use (like quickly tagging all the contacts I need to mail this week, can delete the tag later). Contact types are also a pain because they have to be manually updated, and are really only useful for segregating custom data.