• State Not Answered
  • Replies 1 reply
  • Subscribers 265 subscribers
  • Views 161 views
  • Users 0 members are here
Options
Related

Using TNEW short reg for newsletter sign ups

Michaela Donnelly
$organization

Hi friends, 

Coming out of our recent conversation about triggered welcome emails in WordFly I am hoping for some help and guidance in my quest to convince the "powers that be" to allow us to use the TNEW "short reg" option for our monthly eNews signups. So I have specific questions for anyone using Short Reg for newsletter sign ups. This is what I have been tasked to explain and these are questions that I would love for voices of authority outside of my organization to weigh in on. Basically confirmation of what I know to be true in some cases or let me know about anything I may not be thinking of, and maybe provide me some creative solutions for capturing information that the Box Office has deemed absolutely essential. Some of this should just be common sense answers that I should know and think I do, but...

1. How much information do you ask for? I would like to limit it to First Name, Last Name, Email

2. If a person signs up with First/Last & Email, but has not followed the prompts after sign up to finish creating an account what is the process if they do come back and by tickets--basically, how can the box office insure that when a person actually executes a purchase they have to provide an address which is then capture on the account.

Specifically: Once items are in their carts they need to log, so when they get to the login page if they 

A. Do not equate their "newsletter sign up" with a registration and they go to register

  • They Register
  • They are going to create an entirely duplicitous account with the same email, but full contact details.
    • As a second account is created is anyone using a stored procedure they really love to automatically go in to merge these accounts, how frequently does it run, are there any major issues you have run into with it (merges gone wrong)?
    • Is there anyone who has something built who flags them as already having an account and told to "retrieve their password" (like guest check out does?-- Is this just a pipe dream?)

B. They are flagged as already having an account in option A OR they do remember the newsletter sign up and assume they have an account but no password

  • They choose "Retrieve Password"
  • They update their password, they continue with the objects in their cart down the purchase path
    • If they choose mail, they will have to add an address so, we capture it there (yay)
    • If they choose will call or print at home and do not have to enter an address they continue to the cart, when they check out and they use their credit card they have to provide/update their billing address (theoretically from our web defaults) (yay)
  • When they update their password has anyone created redirect specific to this which would take the user to to the account information page to add/"update" their address details? Right now the continue shopping button is universal, which would lead to my next thing...

What am I missing in this? What is the stumbling block that I am not seeing which would send this whole thing crashing to the ground?

Thanks to everyone who puts their eyes on this!

I do apologize to anyone who had flashbacks to choose your own adventure books from when they were children....

Parents
  • 0 $organization

    How much information do you ask for?

    We run First Name, Last Name, and Email. The details have faded, but remember that there's largely not much choice here. Look at the relevant System Table for the "ShortReg" specific choices and that will tell you what your options are.

    Return to Site

    Likewise, you'll find the options spelled out for how you can facilitate a "return to site" idea in documentation, but this concept is effectively outside of the functionality you're asking about--it falls more into a category of smart marketing and customer service, with TNEW just being the web platform. You can include encouraging messages in confirmation emails for the registration (and in other totally independent campaigns), but TNEW itself won't push the patron to upgrade. But the good news is that you get your pipe dream--a return to the site will recognize the email address as (whatever the technical language) as a partial account, and send the person through the forgot password process. This both sets them with a real password and will collect the rest of the account info like the address. Not a duplicate account at all. It's possible they'll miss any Interests settings, but off the top of my head I think you're covered either by having those on the Short Reg page in the first place, or because the page the person will end up on is the Register page (all the things) vs the Update Account page (not all the things).

    If someone does the purchase offline, staff will of course have to find the account and log the info. If they build a new account without catching the older one, yes, you'll need to deal with merges. Hopefully they'll catch this when they try to use an email address already logged somewhere, but that duplication doesn't always get caught.

    The Short Reg system is pretty solid in terms of functionality/logical account processing. It's absolutely nothing fancy so perhaps it looks less shiny than email sign up options existing elsewhere in the world, but I've got no fault with how it deals with records.*

    *Not actually true. I really do wish the process tagged the records built this way with something I could count for reporting (Original Source? even an attribute?), but it doesn't. Might not be a big deal to do a customization there related to Original Source. Someone suggested this could be sort of tackled with a unique Interest, but since those are all optional checkboxes, it didn't feel reliable to me. But this is about reporting, so I'll call it a separate fault.

    I suspect your main challenge--after generally getting things off and rolling--is making sure your Extractions and List queries will grab these people. I think I'm using an account create date > type situation, with some suppressions that should take care of accounts coming in because of other programs. 

Reply
  • 0 $organization

    How much information do you ask for?

    We run First Name, Last Name, and Email. The details have faded, but remember that there's largely not much choice here. Look at the relevant System Table for the "ShortReg" specific choices and that will tell you what your options are.

    Return to Site

    Likewise, you'll find the options spelled out for how you can facilitate a "return to site" idea in documentation, but this concept is effectively outside of the functionality you're asking about--it falls more into a category of smart marketing and customer service, with TNEW just being the web platform. You can include encouraging messages in confirmation emails for the registration (and in other totally independent campaigns), but TNEW itself won't push the patron to upgrade. But the good news is that you get your pipe dream--a return to the site will recognize the email address as (whatever the technical language) as a partial account, and send the person through the forgot password process. This both sets them with a real password and will collect the rest of the account info like the address. Not a duplicate account at all. It's possible they'll miss any Interests settings, but off the top of my head I think you're covered either by having those on the Short Reg page in the first place, or because the page the person will end up on is the Register page (all the things) vs the Update Account page (not all the things).

    If someone does the purchase offline, staff will of course have to find the account and log the info. If they build a new account without catching the older one, yes, you'll need to deal with merges. Hopefully they'll catch this when they try to use an email address already logged somewhere, but that duplication doesn't always get caught.

    The Short Reg system is pretty solid in terms of functionality/logical account processing. It's absolutely nothing fancy so perhaps it looks less shiny than email sign up options existing elsewhere in the world, but I've got no fault with how it deals with records.*

    *Not actually true. I really do wish the process tagged the records built this way with something I could count for reporting (Original Source? even an attribute?), but it doesn't. Might not be a big deal to do a customization there related to Original Source. Someone suggested this could be sort of tackled with a unique Interest, but since those are all optional checkboxes, it didn't feel reliable to me. But this is about reporting, so I'll call it a separate fault.

    I suspect your main challenge--after generally getting things off and rolling--is making sure your Extractions and List queries will grab these people. I think I'm using an account create date > type situation, with some suppressions that should take care of accounts coming in because of other programs. 

Children
No Data