• Replies 4 replies
  • Subscribers 358 subscribers
  • Views 110 views
  • Users 0 members are here
Related

transacting as individuals on the web

Former Member
Former Member $organization

Hi esteemed colleagues and v11 mavens.

Reviewing the conversations on here about indiv vs households and who should own transactions, it would seem that we are out on our own in preferring to always transact on the individual. As a consortium, we've discussed this, and basically everybody agrees that we want to be able to choose to transact on the indiv or the HH on a case-by case basis, but we have a strong preference for the individual as a general policy. Perhaps that's because us ANZACS are such rugged individualists, or something like that. (cf crocodiles etc.)

...anyway....

We made a collective decision some time ago to abjure the use of N1/N2 records, that everyone was to be an individual, and no-one was to create new N1/N2's, although existing ones were grandfathered until they could be split up.  Org Contact records were eliminated completely. With the result that we now have relatively few N1/N2 records to convert into Households. Which is fine. 

But of course there are some, and in v11-land, we'll happily be creating new ones, now we have the New Constituent Model. However we do intend to contumaciously** reject the strong Tess advice to keep transactions on the household. Brave.

We have set the Transact_as_Household _CONTR, _ORDER, and _CREDITEE defaults to Prompt, obviously.

"But what about the Web??" I hear you cry. Well; exactly; good point; and this brings me to the nub of this post. We are tempted to set that to No, against the specific advice of the upgrade doc ("NOTE:  For backward compatibility with existing websites, TRANSACT_AS_HOUSEHOLD_WEB should be left on Yes.) , 

So - what would be the terrible consequences of that? I've walked through the notes in the What's New, and none of the actual dire warnings in there seem to apply to us. We don't have any mention of N1/N2 on the website, since we've never used them, so we won't try to update them, so those update N2 issues seem to be moot. Similarly,  it seems fine to us if the updates to attributes and so on stick with whoever logged in, whether they're a HH or an indiv. We don't manipulate associations via the website now, so we shouldn't run into those issues.

In another thread here, it is suggested (I think) that if an individual with no primary address of their own (ie an indiv whose primary address is inherited from the Household) is logged on as themselves and tries to update their address, this will cause an issue, because the address actually belongs to another constituent and can't be edited. But this appears not to be the case. What actually happens is that the API creates a fresh individual address for them, as a copy of  the Household address, with the edits that they've made applied to it, leaving the actual household address well alone. Which seems eminently sensible, i have to say.

 I believe my colleagues just along the Harbour at SOH have also been testing things this way, with no negative consequences to date.

So...  is there some other deep dark reason that I've completely missed, why we should not set the TRANSACT_AS_HOUSEHOLD_WEB value to No?

Anyone have any experience to offer? Anna? 

What will happen now - or is it about possible future changes that might cause havoc?

Ken

** Synonyms: contrary, pigheaded, factious, refractory, headstrong, intractable.

  • $organization

    Ken,

    If your website does not use Name 2 it is possible that you may transact on the individual without issue.  If you choose to do this then as you point out you will need to test thoroughly all the processes and make sure that your website does not have any issues with the setting.  I will say that we have only tested the SOAP API against the recommended transaction model and therefore you may want to really redouble your testing.

    The biggest risk with transacting on the individuals rather than forcing to the household mainly relates to two issues: renewable items (memberships and subscriptions) and consistency of data. 

    When deciding to transact on the individual the membership or subscription will be on the individual’s constituent record, therefore other members of a household would not have access to the membership data and could not act on it.  For example, if you were to offer subscription renewals online and make the choice to not automatically swap to the household, then only one person in the household would have access to the subscription to renew, same with exchanges and membership benefits.  Also with membership renewal, if Household Member1 purchases a membership and then Household Member2  goes online to renew the membership, then Household Member 1 will show as an expired member and Household Member2 will show as a new member.  This can be problematic for trending reporting as well as membership benefit allocation.  Also on the web if you have benefits or pricing for members only if the membership is on one individual’s record then the other members of the household will not have access to the membership benefits (that may be fine if you are selling solely individual memberships). 

    In addition to the renewables conundrum the other issue is about consistency of data.  If you have the prompt option on, then that means that the operator chooses whether to transact on the household or the individual.  How is that decided?  If I call in to buy a subscription does it go on my individual record, if I mail in a cheque with both my and my spouse’s name on it do you put it on the household?  And then how does your operator know when to choose one or the other?  If you have the prompt on then you need to make some very clear guidelines for when a transaction is put on the household and when on the individual or it may affect reporting, list pulling, how you address your communications, and access to the data by the individuals in the household.  This relates to the issue above with renewables where if I call and buy the subscription, what does the operator do when my spouse calls to exchange the tickets.  Where this complicates on the web, is that the operator is given a choice to transact on the individual or the household, on the web it is wherever the login is, so there is no option and therefore it is possible that you web data may be inconsistent with the data entered by the operators.  I am not offering a value on if this is a deal killer or not but wanted to point out the difference. 

    In the end you will need to weigh the pros and cons of this and do a lot of testing to make sure that this is the way you want to go. 

    I hope that clarifies it rather than complicates it.

     Anna

  • Former Member
    Former Member $organization in reply to Anna Wessely (Past Staff Member)

    Thanx anna.

    Beautifully clarifed, as usual.

    I think we will keep testing the Way of the Individual.

    We (at ACO, I mean - not speaking for the whole consortium here) don't have any of those complex Membership/Subscriber benefit entitlement schemes set up, so that shouldn't cause us a problem. (Of course, as soon as I've said that, the Dev poppets will probably walk into the office with a proposal to do exactly that, but for the moment we're safe).

    And all of our discussions so far have tended towards a preference for transacting on individual records unless there's a compelling reason to do otherwise, so we think that will be our policy.

    Obviously N1/N2 records that have converted to households could cause some confusion and data inconsistency in this scenario, since logins will have stuck with the household, so if people log in to transact  they will be transacting on the household (and of course rolled-over subs orders and transaction history will be on the household in this case), so that's something we need to work through.

    But I don't see any way of avoiding some issues of that kind, even if we do force transactions onto the household. 

    For example, the consortium Constituent Management Group is currently considering an interesting conundrum that has been raised with households and privacy, :

    • We have a relationship with an individual who has opted in to our communications; 
    • We add that individual in to a household, where the other member has not opted-in, 
    • We have a transaction with that individual (which may be forced to the household), creating a de facto relationship with the household
    • Our next marketing message goes to the household,
    • Have we thereby violated Privacy rules?

    I suspect that's more of a theoretical issue than a practical one, but we haven't come up with an answer yet. Lawyers are garnering fee income on this matter as we speak.

    .. And of course the classic case of the household member who buys some tix that the other member of the household is Not Supposed to Know About......a potentially embarrassing situation.

    Ken

     

     

     

  • $organization
    Ken,

    it is a great discussion, and we've focused a lot of effort on it here as well. We've also reached the conclusion that most transactions will go on the individual record, for a number of reasons.

    First, though, two caveats: One, we are not live with this, but are in the final stages of testing and are scheduled to go live next week. So who knows what we'll run into when we go live, even though we've done everything possible to anticipate and accommodate everything. Second, we have modified our website to use the new REST services for any functionality that is now available with the REST services, and we don't use the old Tessitura web api. We have also taken advantage of the service interceptors.

    So having stated that:

    Realizing that the vast majority of all our records (95% or so) are only individuals, and even a sizable portion of our donors and subscribers (about 35%) are individuals only, we know that regardless of what we decided, many if not most of our orders would go on individuals anyway. There is also great value in knowing which individual did what, including many of the reasons you describe in your post.

    Therefore:

    1. We are putting all ticket transactions on Individual records, with one main exception. We interact with actual people (individuals) and we want to know who we interacted with and give them full control as individuals. There is also incredible value from a data mining and modeling perspective in being able to differentiate the behavior and activity of specific individuals.

    2. The exception to the above is tickets acquired through the benefit we provide to our Corporate Fund donors, since the contact we deal with is often known and tracked through an affiliation, we don't actually know who will use those tickets anyway and we felt it was more valuable to keep these in the Corporate record since that is the 'entity' that is entitled to the tickets.

    3. We hope this will change with Version 12, but for now, we are even putting group and school orders in the record of the individual we are interacting with, rather than in the group or school record. The prime reason for this is we need to easily mail those tickets to the right business address, and the way things work in Version 11, it does not make sense to attach the business mailing address to the school or group (different individuals working for the same company will have different business addresses -- we have dozens of addresses for IBM -- and we need to know which business address belongs to which contact.

    4. What makes all this possible is that we are leveraging Service Interceptors and a custom field we've added to Orders (using standard Tessitura custom field functionality) to track the customer_no of the entity the individual is "transacting on behalf of". We use Service Interceptors to make this seamless and foolproof, and since Service Interceptors work regardless of whether the transaction is processed on the Web or by an operator using the Tessitura front-end, we get consistency across all transactions. An operator (or a customer on our website) can indicate which affiliated record they are transacting on behalf of, which goes into the custom field. If they don't specify anything, the Service Interceptor checks to see if the individual belongs to a household, and it defaults in the customer_no of the household. Note the customer (on the web) or operator (in Tessitura) can also choose the individual themselves as the "on behalf of", which accommodates the privacy issue you mentioned -- if it is themselves, other members of their household cannot view the order. Also, in any case, the Service Interceptor also copies this value to the standard "Special Request For" field on each lineitem in the order (although again, it won't overwrite anything the operator may have already put in on a particular lineitem). This allows us to search for either customer_no in the Order Search screen in Tessitura, and the order will appear regardless of which account it is searched under. This will also allow us to address the considerations that Anna raises related to renewals, exchanges, etc.

    Reports, custom screens, and similar tools have had minor adjustments (usually replacing a table reference with a reference to a view or inline function) so it is essentially transparent and the order is visible whichever account (individual or household) is being viewed.

    I can't emphasize enough the value the Service Interceptors add here. They let us automate this, saving time and effort for our operators and eliminating errors, while still giving operators and customers on the web the easy ability to override the defaults. They give us perfectly consistent behavior between the website and internally processed transactions, with one set of code. It took a little work -- but much less than you might expect -- basically one person a couple of weeks, including the interceptors mentioned below and including a few aborted attempts before we determined the optimal approaches.

    5. Contributions and Memberships are also handled. In this case, we want the contribution to be under whoever actually gets tax credit for the contribution (using our understanding of IRS regulations, this is typically whoever's name is on the Payment. So if the check is from an individual, we put the contribution on an individual. if the check has both names on it, we put the contribution on the Household. In either case, we always wanted the Membership to be on the Household, since we provide benefits to the whole household, and also to accommodate the renewal issues Anna mentions. So we use a Service Interceptor to move the Membership to the Household. This actually addresses many challenges we've struggled with in the past and greatly simplifies or eliminates some complex workarounds we've had to use in the prior to now. Our website now checks for the membership on the household if one exists, regardless of which individual is logged, and provides benefits/offers accordingly.

    6. Having both customer_no's on every order also made it easy to display on our website all of a households orders to any member of a household, regardless of which individual made the purchase, and to show those orders in the Ticket History screens in Tessitura, again, addressing some of the issues Anna rightly mentioned. This is also true for related constituency codes, rankings, etc.

    7. We've created a process on our website that checks to see if someone is logging in with a login that is on a household, and if so, confirms which individual they are, and moves the login accordingly. We've also created a process that checks every time an individual logs in to see if there are other individuals in their household who have not yet created their own logins, and gives them an opportunity to send those individuals an email with a token they can use to easily create their own login. That way we hope to capture more of the individuals in each household and lessen the risk of them creating new records orphaned from the household.

    8. In regards to some other posts about where emails are or where postal addresses are, we've adopted a basic convention (allowing for some exceptions) where we treat email addresses, facebook logins, twitter addresses as contact points that almost always belong to individuals, and thus they typically will be on the individual records. For now, as I've said, we're also putting business addresses on individuals (but we hope that will change with Version 12). Regular mailing addresses will go on the Household, but could also go on individuals. So depending on the "delivery" or "media" of a message, we can handle the extraction appropriately, but perhaps more importantly, as you have pointed out, we can appropriately handle opt-in and opt-out requests/preferences. It also gives us the great advantage that when using online media such as email, we can send the message to everyone within a household individually, and even to multiple email addresses for a single individual if that is what the individual prefers (or even to their email address and facebook and/or twitter accounts, if that is what the individual prefers). Yet we can still just as easily send just a single copy of a printed message to a household via postal mail.

    There's obviously a bit more to it and many important details, but this post is already getting too long. These are most of the major points. Happy to talk in more detail offline if you are interested.

    Alan

    On Jul 5, 2012, at 9:34 PM, "Ken McSwain" > wrote:


    Thanx anna.

    Beautifully clarifed, as usual.

    I think we will keep testing the Way of the Individual.

    We (at ACO, I mean - not speaking for the whole consortium here) don't have any of those complex Membership/Subscriber benefit entitlement schemes set up, so that shouldn't cause us a problem. (Of course, as soon as I've said that, the Dev poppets will probably walk into the office with a proposal to do exactly that, but for the moment we're safe).

    And all of our discussions so far have tended towards a preference for transacting on individual records unless there's a compelling reason to do otherwise, so we think that will be our policy.

    Obviously N1/N2 records that have converted to households could cause some confusion and data inconsistency in this scenario, since logins will have stuck with the household, so if people log in to transact they will be transacting on the household (and of course rolled-over subs orders and transaction history will be on the household in this case), so that's something we need to work through.

    But I don't see any way of avoiding some issues of that kind, even if we do force transactions onto the household.

    For example, the consortium Constituent Management Group is currently considering an interesting conundrum that has been raised with households and privacy, :

    * We have a relationship with an individual who has opted in to our communications;
    * We add that individual in to a household, where the other member has not opted-in,
    * We have a transaction with that individual (which may be forced to the household), creating a de facto relationship with the household
    * Our next marketing message goes to the household,
    * Have we thereby violated Privacy rules?

    I suspect that's more of a theoretical issue than a practical one, but we haven't come up with an answer yet. Lawyers are garnering fee income on this matter as we speak.

    .. And of course the classic case of the household member who buys some tix that the other member of the household is Not Supposed to Know About......a potentially embarrassing situation.

    Ken






    From: Anna Wessely >
    Sent: 7/5/2012 5:30:45 PM
    Ken,
    If your website does not use Name 2 it is possible that you may transact on the individual without issue. If you choose to do this then as you point out you will need to test thoroughly all the processes and make sure that your website does not have any issues with the setting. I will say that we have only tested the SOAP API against the recommended transaction model and therefore you may want to really redouble your testing.
    The biggest risk with transacting on the individuals rather than forcing to the household mainly relates to two issues: renewable items (memberships and subscriptions) and consistency of data.
    When deciding to transact on the individual the membership or subscription will be on the individual’s constituent record, therefore other members of a household would not have access to the membership data and could not act on it. For example, if you were to offer subscription renewals online and make the choice to not automatically swap to the household, then only one person in the household would have access to the subscription to renew, same with exchanges and membership benefits. Also with membership renewal, if Household Member1 purchases a membership and then Household Member2 goes online to renew the membership, then Household Member 1 will show as an expired member and Household Member2 will show as a new member. This can be problematic for trending reporting as well as membership benefit allocation. Also on the web if you have benefits or pricing for members only if the membership is on one individual’s record then the other members of the household will not have access to the membership benefits (that may be fine if you are selling solely individual memberships).
    In addition to the renewables conundrum the other issue is about consistency of data. If you have the prompt option on, then that means that the operator chooses whether to transact on the household or the individual. How is that decided? If I call in to buy a subscription does it go on my individual record, if I mail in a cheque with both my and my spouse’s name on it do you put it on the household? And then how does your operator know when to choose one or the other? If you have the prompt on then you need to make some very clear guidelines for when a transaction is put on the household and when on the individual or it may affect reporting, list pulling, how you address your communications, and access to the data by the individuals in the household. This relates to the issue above with renewables where if I call and buy the subscription, what does the operator do when my spouse calls to exchange the tickets. Where this complicates on the web, is that the operator is given a choice to transact on the individual or the household, on the web it is wherever the login is, so there is no option and therefore it is possible that you web data may be inconsistent with the data entered by the operators. I am not offering a value on if this is a deal killer or not but wanted to point out the difference.
    In the end you will need to weigh the pros and cons of this and do a lot of testing to make sure that this is the way you want to go.
    I hope that clarifies it rather than complicates it.
    Anna



    You were sent this message automatically by www.tessituranetwork.com because you subscribed to the Tessitura Next Generation forum email notifications. You may reply to this message or visit the site to reply to the post above. If replying via email, please consider deleting the previous message text before sending to help with readability on the site. Thank you!

    ________________________________

    This e-mail message is intended only for the recipient(s) named above. This message may contain trade secrets, attorney-client communication, or other privileged and confidential information. Any review, re-transmission, dissemination, reproduction or other use of, or taking of any action in reliance upon, this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the Sender and delete the material from any computer.
  • $organization
    Wow! Very cool. Great thread. Thank you Ken, Anna, and Alan for this very insightful discussion. And I was hoping I read correctly that some of this will be presented at the conference. Thanks to Jon Ballinger for agreeing to present!
    ...Dave

    -----Original Message-----
    From: Tessitura Next Generation Forum [mailto:forums-nextgeneration@tessituranetwork.com] On Behalf Of Alan Levine
    Sent: Thursday, July 05, 2012 10:38 PM
    To: Vivino, David
    Subject: Re: [Tessitura Next Generation Forum] transacting as individuals on the web

    Ken,

    it is a great discussion, and we've focused a lot of effort on it here as well. We've also reached the conclusion that most transactions will go on the individual record, for a number of reasons.

    First, though, two caveats: One, we are not live with this, but are in the final stages of testing and are scheduled to go live next week. So who knows what we'll run into when we go live, even though we've done everything possible to anticipate and accommodate everything. Second, we have modified our website to use the new REST services for any functionality that is now available with the REST services, and we don't use the old Tessitura web api. We have also taken advantage of the service interceptors.

    So having stated that:

    Realizing that the vast majority of all our records (95% or so) are only individuals, and even a sizable portion of our donors and subscribers (about 35%) are individuals only, we know that regardless of what we decided, many if not most of our orders would go on individuals anyway. There is also great value in knowing which individual did what, including many of the reasons you describe in your post.

    Therefore:

    1. We are putting all ticket transactions on Individual records, with one main exception. We interact with actual people (individuals) and we want to know who we interacted with and give them full control as individuals. There is also incredible value from a data mining and modeling perspective in being able to differentiate the behavior and activity of specific individuals.

    2. The exception to the above is tickets acquired through the benefit we provide to our Corporate Fund donors, since the contact we deal with is often known and tracked through an affiliation, we don't actually know who will use those tickets anyway and we felt it was more valuable to keep these in the Corporate record since that is the 'entity' that is entitled to the tickets.

    3. We hope this will change with Version 12, but for now, we are even putting group and school orders in the record of the individual we are interacting with, rather than in the group or school record. The prime reason for this is we need to easily mail those tickets to the right business address, and the way things work in Version 11, it does not make sense to attach the business mailing address to the school or group (different individuals working for the same company will have different business addresses -- we have dozens of addresses for IBM -- and we need to know which business address belongs to which contact.

    4. What makes all this possible is that we are leveraging Service Interceptors and a custom field we've added to Orders (using standard Tessitura custom field functionality) to track the customer_no of the entity the individual is "transacting on behalf of". We use Service Interceptors to make this seamless and foolproof, and since Service Interceptors work regardless of whether the transaction is processed on the Web or by an operator using the Tessitura front-end, we get consistency across all transactions. An operator (or a customer on our website) can indicate which affiliated record they are transacting on behalf of, which goes into the custom field. If they don't specify anything, the Service Interceptor checks to see if the individual belongs to a household, and it defaults in the customer_no of the household. Note the customer (on the web) or operator (in Tessitura) can also choose the individual themselves as the "on behalf of", which accommodates the privacy issue you mentioned -- if it is themselves, other members of their household cannot view the order. Also, in any case, the Service Interceptor also copies this value to the standard "Special Request For" field on each lineitem in the order (although again, it won't overwrite anything the operator may have already put in on a particular lineitem). This allows us to search for either customer_no in the Order Search screen in Tessitura, and the order will appear regardless of which account it is searched under. This will also allow us to address the considerations that Anna raises related to renewals, exchanges, etc.

    Reports, custom screens, and similar tools have had minor adjustments (usually replacing a table reference with a reference to a view or inline function) so it is essentially transparent and the order is visible whichever account (individual or household) is being viewed.

    I can't emphasize enough the value the Service Interceptors add here. They let us automate this, saving time and effort for our operators and eliminating errors, while still giving operators and customers on the web the easy ability to override the defaults. They give us perfectly consistent behavior between the website and internally processed transactions, with one set of code. It took a little work -- but much less than you might expect -- basically one person a couple of weeks, including the interceptors mentioned below and including a few aborted attempts before we determined the optimal approaches.

    5. Contributions and Memberships are also handled. In this case, we want the contribution to be under whoever actually gets tax credit for the contribution (using our understanding of IRS regulations, this is typically whoever's name is on the Payment. So if the check is from an individual, we put the contribution on an individual. if the check has both names on it, we put the contribution on the Household. In either case, we always wanted the Membership to be on the Household, since we provide benefits to the whole household, and also to accommodate the renewal issues Anna mentions. So we use a Service Interceptor to move the Membership to the Household. This actually addresses many challenges we've struggled with in the past and greatly simplifies or eliminates some complex workarounds we've had to use in the prior to now. Our website now checks for the membership on the household if one exists, regardless of which individual is logged, and provides benefits/offers accordingly.

    6. Having both customer_no's on every order also made it easy to display on our website all of a households orders to any member of a household, regardless of which individual made the purchase, and to show those orders in the Ticket History screens in Tessitura, again, addressing some of the issues Anna rightly mentioned. This is also true for related constituency codes, rankings, etc.

    7. We've created a process on our website that checks to see if someone is logging in with a login that is on a household, and if so, confirms which individual they are, and moves the login accordingly. We've also created a process that checks every time an individual logs in to see if there are other individuals in their household who have not yet created their own logins, and gives them an opportunity to send those individuals an email with a token they can use to easily create their own login. That way we hope to capture more of the individuals in each household and lessen the risk of them creating new records orphaned from the household.

    8. In regards to some other posts about where emails are or where postal addresses are, we've adopted a basic convention (allowing for some exceptions) where we treat email addresses, facebook logins, twitter addresses as contact points that almost always belong to individuals, and thus they typically will be on the individual records. For now, as I've said, we're also putting business addresses on individuals (but we hope that will change with Version 12). Regular mailing addresses will go on the Household, but could also go on individuals. So depending on the "delivery" or "media" of a message, we can handle the extraction appropriately, but perhaps more importantly, as you have pointed out, we can appropriately handle opt-in and opt-out requests/preferences. It also gives us the great advantage that when using online media such as email, we can send the message to everyone within a household individually, and even to multiple email addresses for a single individual if that is what the individual prefers (or even to their email address and facebook and/or twitter accounts, if that is what the individual prefers). Yet we can still just as easily send just a single copy of a printed message to a household via postal mail.

    There's obviously a bit more to it and many important details, but this post is already getting too long. These are most of the major points. Happy to talk in more detail offline if you are interested.

    Alan

    On Jul 5, 2012, at 9:34 PM, "Ken McSwain" > wrote:


    Thanx anna.

    Beautifully clarifed, as usual.

    I think we will keep testing the Way of the Individual.

    We (at ACO, I mean - not speaking for the whole consortium here) don't have any of those complex Membership/Subscriber benefit entitlement schemes set up, so that shouldn't cause us a problem. (Of course, as soon as I've said that, the Dev poppets will probably walk into the office with a proposal to do exactly that, but for the moment we're safe).

    And all of our discussions so far have tended towards a preference for transacting on individual records unless there's a compelling reason to do otherwise, so we think that will be our policy.

    Obviously N1/N2 records that have converted to households could cause some confusion and data inconsistency in this scenario, since logins will have stuck with the household, so if people log in to transact they will be transacting on the household (and of course rolled-over subs orders and transaction history will be on the household in this case), so that's something we need to work through.

    But I don't see any way of avoiding some issues of that kind, even if we do force transactions onto the household.

    For example, the consortium Constituent Management Group is currently considering an interesting conundrum that has been raised with households and privacy, :

    * We have a relationship with an individual who has opted in to our communications;
    * We add that individual in to a household, where the other member has not opted-in,
    * We have a transaction with that individual (which may be forced to the household), creating a de facto relationship with the household
    * Our next marketing message goes to the household,
    * Have we thereby violated Privacy rules?

    I suspect that's more of a theoretical issue than a practical one, but we haven't come up with an answer yet. Lawyers are garnering fee income on this matter as we speak.

    .. And of course the classic case of the household member who buys some tix that the other member of the household is Not Supposed to Know About......a potentially embarrassing situation.

    Ken






    From: Anna Wessely >
    Sent: 7/5/2012 5:30:45 PM
    Ken,
    If your website does not use Name 2 it is possible that you may transact on the individual without issue. If you choose to do this then as you point out you will need to test thoroughly all the processes and make sure that your website does not have any issues with the setting. I will say that we have only tested the SOAP API against the recommended transaction model and therefore you may want to really redouble your testing.
    The biggest risk with transacting on the individuals rather than forcing to the household mainly relates to two issues: renewable items (memberships and subscriptions) and consistency of data.
    When deciding to transact on the individual the membership or subscription will be on the individual’s constituent record, therefore other members of a household would not have access to the membership data and could not act on it. For example, if you were to offer subscription renewals online and make the choice to not automatically swap to the household, then only one person in the household would have access to the subscription to renew, same with exchanges and membership benefits. Also with membership renewal, if Household Member1 purchases a membership and then Household Member2 goes online to renew the membership, then Household Member 1 will show as an expired member and Household Member2 will show as a new member. This can be problematic for trending reporting as well as membership benefit allocation. Also on the web if you have benefits or pricing for members only if the membership is on one individual’s record then the other members of the household will not have access to the membership benefits (that may be fine if you are selling solely individual memberships).
    In addition to the renewables conundrum the other issue is about consistency of data. If you have the prompt option on, then that means that the operator chooses whether to transact on the household or the individual. How is that decided? If I call in to buy a subscription does it go on my individual record, if I mail in a cheque with both my and my spouse’s name on it do you put it on the household? And then how does your operator know when to choose one or the other? If you have the prompt on then you need to make some very clear guidelines for when a transaction is put on the household and when on the individual or it may affect reporting, list pulling, how you address your communications, and access to the data by the individuals in the household. This relates to the issue above with renewables where if I call and buy the subscription, what does the operator do when my spouse calls to exchange the tickets. Where this complicates on the web, is that the operator is given a choice to transact on the individual or the household, on the web it is wherever the login is, so there is no option and therefore it is possible that you web data may be inconsistent with the data entered by the operators. I am not offering a value on if this is a deal killer or not but wanted to point out the difference.
    In the end you will need to weigh the pros and cons of this and do a lot of testing to make sure that this is the way you want to go.
    I hope that clarifies it rather than complicates it.
    Anna



    You were sent this message automatically by www.tessituranetwork.com because you subscribed to the Tessitura Next Generation forum email notifications. You may reply to this message or visit the site to reply to the post above. If replying via email, please consider deleting the previous message text before sending to help with readability on the site. Thank you!

    ________________________________

    This e-mail message is intended only for the recipient(s) named above. This message may contain trade secrets, attorney-client communication, or other privileged and confidential information. Any review, re-transmission, dissemination, reproduction or other use of, or taking of any action in reliance upon, this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the Sender and delete the material from any computer.


    You were sent this message automatically by www.tessituranetwork.com because you subscribed to the Tessitura Next Generation forum email notifications. You may reply to this message or visit the site to reply to the post above. If replying via email, please consider deleting the previous message text before sending to help with readability on the site. Thank you!