TeamRaiser Quick Registration

"...all non essential questions would be presented in the particpant center to be completed after the registration is complete."

I think this is an awesome idea. Registration is crazy long.

How would this be presented within the Participant Center? Would/Could it be tied in with Online Check-In? (Seems like OCI could stand a bit of work too. Two birds...)

I think the registration questions and waiver would need to be complete before they can begin fundraising. And if that is the case, then perhaps we can make all of OCI required before fundraising? (Especially DSP/ISP. Please, please, please!)

Please be careful that the Participant Center doesn't take any longer to load. It's right on the edge as it is. (A good chunk of people I see launch the participant center for the first time actually say 'WTF' out loud.)

Also I have to say, that the biggest complaint we get about TR is still the email system in the participant center, and not the length of registration. I haven't really watched abandonment rates tho. Do you have Convio-wide stats for TR registration abandonment?

Regards, B

Noticed this related doc after posting a reply.

http://community.convio.com/t5/Luminate-Online/TeamRaiser-Registration-Redesign-Mockups/m-p/21268

Regards, B

Brian Mucha:

Noticed this related doc after posting a reply.

 

http://community.convio.com/t5/Luminate-Online/TeamRaiser-Registration-Redesign-Mockups/m-p/21268

 

 

Regards, B

I notice in these old mock-ups that the discount code field has been moved. I like the new location. Here's another idea.

We had a big problem with emailing discount codes. The recipient would often copy and paste the code from the email and inadvertantly include a leading or training space or some other character. (We send - Your discount code is: 2322. And they paste in ' 2322'.) Seems like a silly problem, but it happened all the time, even when the discount code would be alone on a single line. (And of course the WYSIWYG often adds funny stuff even when the email creators understand the issue.)

So I added a custom page to the TeamRaisers. And now we email a link, like so...

http://www.heroesforlife.org/site/TR?sid=1550&fr_id=1310&pg=informational&dc=myDiscount

This page just grabs the code out of the queryparams and puts it in a readonly input field from which they can copy without error. But it would be so much cooler if this could be the lead page into registration. Maybe as a hidden page that comes before step one? You could still keep the regular field later in the process for those that don't get the code via email.

Regards, B

/ Yeah, post in Ideas.

Noel Beebe:

No, no cross-client stats on abandonment, but we do track it for specific clients who set up google analytics funnels to watch this.  The most popular point of abandonment is the registration summary page -- epecially for clients that do not charge a registration fee.

I do have an issue with making people complete their information before they can begin fundraising -- we never want to add roadblocks to fundraising.  It's not really a "bonus" for the participant to get to start fundraising -- it's a bonus to the organization.  We want them in the door and fundraising asap.  Which begs the question -- when and how to we "force" participants to complete their registrations?

"we never want to add roadblocks to fundraising"

I certainly agree, and thats a great reason to shift the non-critical questions to an autoresponder or coaching email pushed survey. But there are sometimes questions that we must get answered, and these are the only way.

The issue I have with Instant/Delayed Self-Pledge, which presents itself as part of Online Check-In, is that nothing forces participants to complete it. So in the end, we are doing a weekly email to a task built group - bascially nagging them until they comply. Sounds like the 'required' registration questions are tipping into this same bucket

I'd rather have DSP required (and part of checkout) and the questions optional, if anything.

So, perhaps the OCI page is open by default - which they can click away from and start fundraising - until the complete all the steps (Survey, DSP, etc.)

Regards, B

A quick registration process is always a positive thing, provided we are collecting the data that we need to manage the event.

We question though, if participants will go to the participant center and provide the data that we are looking for at a later date.  We think that we will get minimal participation using this mechanism…perhaps that is o.k.

Because we have varying needs across the different centers and events within a center, it is important on an individual center and event basis to decide which questions are mandatory and remain within the new "quick" process. If it is not possible to achieve that level of center/event customization, then we would prefer not chasing down people for data and opt to stay with the longer registration process.

Casey Flinn:

Jim, et al,

take a look at this workflow i sketched...this is what im thinking.

the basic premise is that the questions can be configured to:

1) all be in the workflow

2) some be in the workflow, and the rest in PC2

3) all in PC2

4) optional intercept to not allow access to PC2 without answering the survey questions

5) mandatory intercept of waiver for someone registered via multi reg

thoughts?

Hi Casey,

This is a great process redesign and I agree with the direction all the comments have gone so far. We frequently are asked about the potential to redesign pages or flow, the top three are:

1) Why is Team a separate step, it is only a couple questions?

- looks like you answered it in your flow diagram, awesome

2) Can we add options on the upsells?

a. here we have to go to additional questions, but those questions then appear in a different step

b. I've used JQuery to inject custom inputs after the upsell selection and setting the value to a session value which is then inserted into the actual question on the additional question page... but that is an ugly hack and wouldn't be needed if you could get the reg/upsel on the same page as the questions

3) Can we have a one page registration?

a. I like your current breakdown but, it is possible with the APIs to make a one-page solution. Perhaps that could be considered as a solution here. I know that many clients would like it.

Additionally, I'm going to throw in a request of my own... I think that Engineering is doing a great job of adding CSS hooks as they touch various templates. This registration flow could use a few more that would ease many simple UI requests (hide reg type when there is just one, font styles, etc). Proper IDs (start with letter not number, no periods) and consistent class naming (either cstmback or cstmBack) would be helpful on key elements. There are parts of the current reg flow where it is virutally impossible to simply change font size without traversing the DOM from .appArea.

Thanks,

Glen

I'm also a proponent of the quick registration idea; however, I'm a bit hesitant about the notion of pulling survey questions out of the registration flow and making them optional.  I would anticipate that our response rates for those questions would fall off severely if you did that.  A significant segment of our participant base would fall under the multi-reg scenario - mostly parents registering their children or corporate team captains registering co-workers for our TeamRaiser events.  I think having the survey questions as part of the registration flow enables us to capture the answers to the questions for the secondary registrations (children, co-workers) in the quite common scenario that the secondary never actually logs into PC2 and does any active fundraising.  While they may not be active fundraisers, it is still critical that we capture the information because we're using the responses to survey questions as a means for segmenting our constituents into groups for targeted coaching emails, email campaigns and other communications.  If the survey questions were not part of the reg flow and a gateway to using PC2, then we'd never get answers to those questions for a big chunk of constituents.  At least in the current registration flow, our parents or corporate team captains are prompted to answer the questions on behalf of the secondary.  Our current implementation of survey questions is not optimal for a variety of reasons, but its better than nothing. Other orgs may put greater or lesser weight on survey questions, but for my 2 cents I think having them in the reg flow is better for us.

I have no opinion on the waiver status...as we also have a redundant step during day-of-event to make sure that people have a signed waiver on file.  I would be fine with pulling that piece out and putting it into PC2.

Regarding registration abandonment...based on Google Analytics data, we implemented a javascript customization to our site that has significantly reduced abandonment on the last step.  The customization was simply a pop-up message that prompts the user when he/she attempts to close the browser window or otherwise exit the page without completing registration.  This has made a big difference for us...I would recommend possibly putting something similar into your overall product roadmap.

Additionally, we're making some design changes to make the multi-reg steps a bit more prominent - we found that a number of people are completing their own registrations prematurely when they intended to register one or more secondaries.  The "Register Another Person" button is somewhat inconspicuous with our current page layout...the user habit is to enter the name of the secondary registrant, then proceed to click "Complete Registration" which doesn't perform the desired function of registering a secondary.  I think if you made the multi-reg function a bit more prominent or extricated it from the primary registration flow somehow, it would cut down on failed/abandoned registrations even more.  I think right now the primary reg and secondary reg steps are too tightly woven together.