Is Digital Content Access driven at the Order Level?

In the Webinar Q&A they said owner and initiator would have access, but not recipient.

I am actually in the middle of a meeting going over options for purchasing access for others.  One of our two guiding principles (well, my guiding principles) is, start with "No", and then where you cannot evaluate the precise audience and how that might guide your solution.

Three ideas (we may use any or all):

1. Skip TNEW and email access to a single password-protected page.
2. Use an allocation to limit the purchased ticket amount and then give the purchaser an offer code to distribute.
3. Have the purchaser buy and hand out Gift Certificates.

In the Webinar Q&A they said owner and initiator would have access, but not recipient.

I am actually in the middle of a meeting going over options for purchasing access for others.  One of our two guiding principles (well, my guiding principles) is, start with "No", and then where you cannot evaluate the precise audience and how that might guide your solution.

Three ideas (we may use any or all):

1. Skip TNEW and email access to a single password-protected page.
2. Use an allocation to limit the purchased ticket amount and then give the purchaser an offer code to distribute.
3. Have the purchaser buy and hand out Gift Certificates.

Owner makes obvious sense, but I am not sure I understand initiator and not recipient.  I mean, the way we have used recipient for normal orders is as the one who receives the tickets.  I am not sure what the thinking is for digital content to NOT be able to go to the recipient unless it was just technically difficult to code given the underlying table structure.  Then again, I have also been irritated that you cannot assign mailing addresses in orders for the recipient.  I guess, for me, if we take a theoretical order, Patron A initiates the order, but for reasons it should live on Patron B's account (owner), but Patron C is the one who will be receiving the tickets, in that circumstance, I would want to be able to mail those tickets to Patron C.  With logical extension then, I would also want Patron C to be able to log into their account and view the digital content, if that was what was in the order.  Sure, the importance of signifying Patron C as recipient is also important for ticket history purposes, but I think it makes sense here, too.

Long story short, I guess this is me saying I would love it if recipient got access to more from the order level.  Maybe this is just my own thing, though.

Ah! I must have missed the bit about the owner and initiator.  Disappointing about the recipient.  That would make the most sense to me.   We may end up implementing a much more manual solution.  

We are also looking at similar methods for access purchased for others.  Over here, there is a big of concern about passwords, offer codes and links being shared, so gift certificates might be the best option.    

Definitely agree, John!  Recipients would definitely alleviate some headaches over here!

Initiator is often used to flag which member on a household is associated with the order, while the owner is usually pegged as the household itself.

The issue here is that they have tied the interface (probably for more than one reason, but the basic structure of TNEW, logins and orders would be a primary reason) to the order, and the order is linked to owner and initiator, while recipient is tied to specific sub line items.

That said, in future iterations I'll certainly be voting to change to displaying events instead of orders, as that is more natural (and will allow more natural searching and sorting) and for allowing access for recipients.

How we've broken it down is this:

With offers and allocations we are able to shove responsibility for distribution off onto the purchaser.  If they or their friends hand out the offer code to the wrong people then they are the ones who lose out (we're actually planning on padding our allocations a bit: obviously we don't have real inventory limits for digital events).

With group password access we're looking at high volume complex distribution events where forcing everyone involved to create an account would be onerous, and also where the event itself is of limited duration, so that releasing the password will create a limited amount of exposure to unintended sharing.

I suppose I could have phrased my thing about initiator better.  I get why initiator would be included.  But if you are going to include initiator, it seems like it makes just as much sense to also include recipient.  If you are just looking at the desire of any given organization to want to give access to more than just the owner, the desire to give to the recipient is likely just as strong as the desire to give to the initiator.

But, from a coding standpoint, given that the initiator is order level and the recipient is not, I get it.  But that does not mean that I do not WANT it.

Hey Gawain!

I have solved our sponsors dilemma (for the most part), now I am looking at possible solutions for patrons purchasing access for others.  Have you sorted out what you will be doing?  We are looking at the gift certificate model, but I'm worried that it might be way too clunky- especially without being able to target the specific GC amount and with TNEW v7 not allowing an easy method to purchase multiple gift certificates without repeated trips back and forth to the cart (this is probably the only thing I miss from TNEW v6)   I am worried that it will turn into a bit of a logistical online nightmare. :/ 

Hoping that maybe you figured out a cleaner, less cumbersome path?

Thanks!
Kristine