• Replies 8 replies
  • Subscribers 247 subscribers
  • Views 157 views
  • Users 0 members are here
Related

Household Memberships v. Individual Logins

Kelly Enderwick
$organization

Hello,

I wonder if anyone has come across a similar issue and how they got around it:

1. We process memberships at the HH level (if one exists) as everyone in the HH can benefit from that membership.

2. When we process tickets we have that on the individual records as we want to see their individual ticket history and their online login is on their individual record also.

The issue we are having is members of a certain level do not have to pay ticketing fees, however when they book online it is not taking the fee off the booking as they are booking on the Individual record and the membership is on the HH.  

Is this possible for the membership to be recognized in the individuals order? I feel it should be. Any advice greatly received. 

Thanks

Kelly

P.S. Please don't say we have to get our web provider involved. 

 

Parents
  • $organization

    Hello, 

    I now have the problem the other way round. Any help would be greatly appreciated. 

    The Problem:

    • TNEW forces the transaction to the Household
    • Our Memberships sit at the Individual 
    • If a member logs in, who is part of a household, they don't have access to the same benefits. I.e. the MOS doesn't change based on the Ranking on the Individual record so they can access Priority booking. 
    The Solution: 
     
    • This is where you lovely people come in... 
    • Putting the Membership on the Household makes the most sense as they probably share it any way - However, as we have a  single membership option we can't put that as the Household level, our membership team, where a Single Membership exists, don't want both Affiliates using it. 
    • I've had a look at the ShiftContext API method, could this work? Not being too well versed in the API world I'm not too sure.  

    Open to any other suggestions.

    Kelly

     
  • $organization in reply to Kelly Enderwick

    If a member logs in, who is part of a household, they don't have access to the same benefits. I.e. the MOS doesn't change based on the Ranking on the Individual record so they can access Priority booking.

    I'd make sure you understand all the different permutations of login locations and TNEW behaviors: you can have logins on a Household or an Individual account, and the behavior is pretty complicated.  All transactions certainly happen on the Household whether the login is associated with an affiliate or not), but other things happen on the specific account the login is on: for instance, Interests updated through the Interests page (account/interests.aspx) happen on the individual customer record.  I haven't checked to be sure, but I expect that the Web Ranking also happens on the account of the login.

    Putting the Membership on the Household makes the most sense as they probably share it any way - However, as we have a  single membership option we can't put that as the Household level, our membership team, where a Single Membership exists, don't want both Affiliates using it. 

    The real question is how you rank customer accounts.  Your ranking algorithm is necessarily custom, so you should be able to make this do whatever you want (not that it will necessarily be easy).  So you could potentially have the ranking algorith look at affiliates when computing it's value, and you can choose which memberships it fires certain behaviors on (i.e. skipping Individual memberships altogether, or just not looking for those on an individual account when computing for a household.).

    I've had a look at the ShiftContext API method, could this work? Not being too well versed in the API world I'm not too sure.  

    Not likely: if you have TNEW you have limited ability to fire customizations related to session.  How were you going to go about implementing it?

Reply
  • $organization in reply to Kelly Enderwick

    If a member logs in, who is part of a household, they don't have access to the same benefits. I.e. the MOS doesn't change based on the Ranking on the Individual record so they can access Priority booking.

    I'd make sure you understand all the different permutations of login locations and TNEW behaviors: you can have logins on a Household or an Individual account, and the behavior is pretty complicated.  All transactions certainly happen on the Household whether the login is associated with an affiliate or not), but other things happen on the specific account the login is on: for instance, Interests updated through the Interests page (account/interests.aspx) happen on the individual customer record.  I haven't checked to be sure, but I expect that the Web Ranking also happens on the account of the login.

    Putting the Membership on the Household makes the most sense as they probably share it any way - However, as we have a  single membership option we can't put that as the Household level, our membership team, where a Single Membership exists, don't want both Affiliates using it. 

    The real question is how you rank customer accounts.  Your ranking algorithm is necessarily custom, so you should be able to make this do whatever you want (not that it will necessarily be easy).  So you could potentially have the ranking algorith look at affiliates when computing it's value, and you can choose which memberships it fires certain behaviors on (i.e. skipping Individual memberships altogether, or just not looking for those on an individual account when computing for a household.).

    I've had a look at the ShiftContext API method, could this work? Not being too well versed in the API world I'm not too sure.  

    Not likely: if you have TNEW you have limited ability to fire customizations related to session.  How were you going to go about implementing it?

Children
No Data