Joint membership (probably not household) modelling and hook question

[Michael McAndrew]

Hi,

I'm modelling the membership structure of an organisation with a pretty large existing membership base that we are importing into CiviCRM (approx 10,000).

They have a joint membership structure.  After looking at their requirements, I came to the conclusion that household membership was the way to model joint members (don't panic Tony!).

Then read all of the Tony blog and forum posts.  Having spent some time on the households model, I was kind of reluctant to let it go, but the more I read, the more I realised that Tony might be on to something, so I tried to do it the Tony way.  Below I've sketched out the requirements and model of this new approach.

So this work in progress comes from discussions I've had with the client, and with Peter and Xavier (who are working with me on this) and from Tony's comments.  I'm up for loads of comments here, and as a result of this, I feel kind of qualified to be part of the "cor blimey governor - what are we going to do with households?" discussion?

Requirements

The org has single and joint membership options.  Joint members should be treated as a single entity in some cases, and as two individuals in others.  Specifically:

1) When sending out emails, the org wants to contact all individuals with joint membership and all single members.

2) When mailing out the paper newsletter, they want to produce one address with a nice greeting (i.e. custom joint for joint members)

3) Sometimes they want to send out paper mailings which have two copies of things for joint members like ballot papers (but just send one envelope to the same address)

4) When signing up for membership (online or offline), they want to enter one address, and two individual email and phone numbers.

5) Members want to interact with the org, sign up for groups, etc. in their own right as an individual, for example, make contributions to campaigns etc.

6) They both need to be able to edit their own phone and email contact details, and their shared address details.

Model:

Single membership is a bog standard single membership.  Joint membership extends through a relationship to another person in the contact database.  That relationship is 'member who did the transaction' <-> 'member who didn't do the transaction'

Following this model, two smart groups are created:

a) 'Single members and joint members' (all members)
b) 'Single members and joint members that have the relationship member with address' (members condensed)

Joint membership sign up has the following fields:

Person a name
Person a phone
Person a email
Person b name
Person b phone
Person b email
Address (shared)
Shared greeting (stored in postal shared greeting field)

Refering the model back to the requirements:

1) Can be done with smart group a)

2) Can be done with smart group b)

3) Can be done by splitting members into joint members and not single members and putting two copies in joints and one in singles.  If you want to mailmerge or do something clever with related activities we'll have to wait until 3.1 when the ability to export related contacts comes in.

4) When you sign up on a joint sign up page, a hook takes all fields that apply to contact 2 and creates a contact. (unsure as to whether this includes address).  It give the contact the relationship.  Website logins are created for both contacts if they don't have them (automatically?).

What about the internal process for this?

5) They use their log in.

6) a hook that updates address for these contacts whenever the other address is updated.  In a sense this is the shared address functionality that Tony-the-household-hater is talking about.  As long as both people are aware that updating an address will update the other, that is OK.  We'll have a hook that updates addresses for related contacts both ways.

OK.  It's taken me a while to move from the household model to this one.  Please tell me it was worth it.  If not, I can always go back - I think I remember how I was thinking about it before 

[petednz]

And a checkbox that appears on any form for someone with that relationships so they can specify if they are 'updating the address for all people at that address' (which probably means it needs a read only field showing names of people at that same address)

That way people can say 'yes the (non-)household address has changed' or 'I have moved/left the (non-)household' - though of course that latter has added complications for people with joint memberships - since presumably the 'i have moved/left' means the relationship that causes the membership inheritance needs to be terminated - and this needs to trigger an alert that someone in the relationship will have just lost their membership!

but yes Michael, I agree with the track you are on - but I think that track is also what is still needed for households too.

[Michael McAndrew]

but yes Michael, I agree with the track you are on

Good to know.

That way people can say 'yes the (non-)household address has changed' or 'I have moved/left the (non-)household' - though of course that latter has added complications for people with joint memberships - since presumably the 'i have moved/left' means the relationship that causes the membership inheritance needs to be terminated - and this needs to trigger an alert that someone in the relationship will have just lost their membership!

One of the restrictions of joint membership is that the org only delivers to one address.  So in your model the checkbox is always ticked.  I don't think it would be a problem therefore to remove the checkbox and just say that you are updating the address details for both members.

When joint members want stuff delivered to two households, the org instructs the members to switch to two single memberships.  In this case, the members will not renew their joint membership, and instead create two single memberships and hey presto.  In the first instance, this might involve some manual intervention by the org but that should be acceptable.

[davidunwinubs13]

Michael's ideas here are interesting and something that I think many organizations would need. I am doing some pro bono work on behalf a large residents society in London. They have joint memberships where they want to treat a household as one membership but have the option to send one copy of report to the household but also communicate with individuals. We also have the same  problem with using organizations as we use for business membership. Same thing one membership but have the ability to communicate with either a single entity(the business) or one or more of the employees.

[Erik Hommel]

I am not sure if I understand all the problems correctly but with our housing corporation customer we also deal with households and individuals, and sometimes the household is more important and sometimes the individual. We have the following situation:

• in principle a household rents a property, even if it is a household of one person
• the individuals in the household (this could only be one) are created as an individual with a relationship to the household
• as much as is feasible, information is kept only once and at the correct level: address belongs to the household and the individual uses the household address. Like so for home phone number and household email
• things like mobile phones and personal emails are kept on the individual level
• we have different relationship types for the contractual partners in the household, the children that live at home, the children that do not live at home, other residentials

I have no idea yet how does is going to work with printing of documents, sending mails and that sort of stuff. I will follow and gladly contribute to the discussion. I am sure we will have to do some work in this field anyway, so count me in for some hours when work is required.
Erik

[LoganBear]

I'm curious of the status of this development, since I've just been handed an identical situation.  Is there anything of your project you can share with us?

[Michael McAndrew]

We've stuck with the method above for the project I mention.

It's good with the following pain points which might serve as directions for working with this.

The shared address fields are un-normalised.  You have to type the shared address and shared greeting in both records (and when you update the shared greeting, you have to remember to do it in both).

You have to add the relationship first because the membership won't be delivered to both if you don't.

You have to remember which side of the relationship to deliver the membership to because the membership is only inherited one way

you have to remember that postal greeting really means shared greeting.

Of course there's ways around these.  I outline them in case they are useful when it comes to rethinking the membership through relationships model.

I think that some of your problems Eric, would be solved if we could implement a primary contact for organisations, or more closely link groups and relationships, or allow people to search based on criteria on both sides of relationships, i.e. say

I want to find all fathers in households in which we've had complaints about noisy 18 year olds

[Erik Hommel]

That sounds like a realistic question Michael, being a father of an 18 yr old son myself :-)
I will certainly do work on this stuff in the coming weeks, but the simpler things first.

[SarahG (FountainTribe)]

In your situation, does joint membership cover the children of the couple?  I have very similar requirements  with organizations that I work with. They offer single memberships, family memberships ( covers 2 adults plus their children )  and couples memberships ( covers 2 people) .   In the case of family memberships, there are situations where parent has joint custody with an ex, who is part of a different household. ( The ex may have membership too ).

The organizations often need to communicate with the whole family unit ( such as when mailing something  ), or each individual. 

I have already written code to deal with the joint greetings ( ie Dear Mr. and Mrs. Jones ) that is available to download at: http://civicrm.org/blogs/sgladstone/dealing-joint-greetings-part-2-code-provided.

[Erik Hommel]

Our starting point is individuals, and household is a way to connect individuals together. We obviously also deal with broken families, shared custody etc. So far we have been able to cover all those relations with the standard relationship types, using the start and end dates. I do expect we will create some profiles, reports and templates to present information to different users, but that will progress during the project.
I certainly expect requirements to have prefixes like 'Dear Mr. adn Mrs.' (but then the Dutch equivalent), great!

[Eileen]

Hi Erik - just wondering how you got on with your approach...

[Erik Hommel]

Hi Eileen,
we are now in the initial testing phase, where the users will test standard CiviCRM (with some minor adaptations for housing corporations). In the coming week I will have a first look at migrating data into CiviCRM from their main transaction system and some surrounding software (Outlook, Excel).
So far no requests for anything we could not solve with standard situations!
Erik