Zip Code as Constituent Name?

Hi Mindee,

You can use survey questions to track zip codes for general public orders, and then in T-Stats and Tessitura Analytics (v15) you can then identify the question used to record zip codes for general public orders and then do zip code analysis on those along with regular constituent records that have addresses on file. Here's a link to the help topic on survey questions

https://www.tessituranetwork.com/Help_System_v141/Content/Sales%20Layouts/Survey%20Questions.htm 

-Kevin Sheehan

HI Kevin,

We were intrigued by Mindee's post because what it will do, that I think survey questions would not, is allow reports to be run on that zip code like a constituent.  One thing custom order data and also survey questions lack is the ability to get ticket sales reports, especially by price type.   Am I wrong?  Is there a way to get tickets sales by price type using a survey question?  I know doing something like this would muddy up the customer name, which is a text field with numbers but it sure does sound like an ingenious idea to get the numbers we yearn for with Gen Public sales.

Thanks, Kevin! They are currently using a survey question but the presentation they saw at TLCC2018 really fired them up about the idea of having a constituent record for each zip code. Thanks for the link to the documentation, though, because maybe we can adjust how they're currently doing this!

Terry,

I was curious about the same thing.  Something that has been discussed around here is creating a general order account whose only purpose is to have the relevant zip code on it so that those tickets at least have the correct location on them.

That has not yet been done due to the sheer number of zip code accounts that might need to be created, and then using them in a timely manner for walk-up sales would be a bit of a hassle, too.  Sure, you could have something written down with the most common zip code account numbers written on them, but what about when someone wants one that is not on the list that still has a lot of accounts in the system with that zip?  Searching that way for the account number in the constituent search takes a while.  And then of course the time that must be taken to create a new one when someone comes up whose zip code does not have a generic account either.

But I am curious about these things, too.  As we continually get requests from different departments asking about marketing and development things, they are going to become less and less pleased with walk-up sales not being counted.  We have few enough walk-up sales that this is nowhere near an immediate issue for us, but I am curious to see what other options might be out there.

Yes, in both T-Stats and Tessitura Analytics you can designate which survey question represents postal codes for general public orders. Once you do that general public orders that have a response on file for that survey question will be treated as if that is the postal code on their primary address. 

In T-Stats (right now), there is an optional  parameter in the load_warehouse procedure, @gen_pub_survey_zip, that allows you to specify which survey question’s responses to use as postal codes for general public orders. 

In Tessitura Analyitcs (very soon in v15) you can do the same thing, except it will now be controlled by a T_DEFAULTS entry, General Public Zip Question. 

Also, in both T-Stats and Tessitura Analytics, if your org has decided to use a single constituent record other than ID 0 for your general public orders, you can specify the ID number for that constituent record as well (with a parameter/T_DEFAULTS entry), and the tools will use the postal code survey responses on file for the specified constituent ID instead of constituent 0. 

I imagine you could do the same thing for any custom reports you write, though the specific code mechanics of that are outside my expertise (though you will be able to reference the views used by Tessitura Analytics for writing your own reports, so that might help. I’m sure once v15 is released support can point you in the correct direction for that).

-Kevin

Thanks Kevin,

That is very good to know and we will look at using survey questions for zips and test it out.  

The TLCC presentation you are looking for is General Public, But Not Anonymous. From my notes, the Business Analyst from the Metropolitan Museum of Art talked about how they have a record for each Zip Code and County; roughly 40,000 records.

First Name = Out of State - CA

Last Name = 90210

Terry,

If you use the built-in General Public account (customer_no 0) and a zip code survey question, and the T-Stats configuration option Kevin mentioned, you can absolutely report on sales by price type, including those to the zero customer, by zip code in T-Stats. Using the General Public zip code functionality moves all the survey-response zip codes into the standard zip code attribute in T-Stats. So it'd all be in one place.

T-Stats can also be configured to store up to 10 survey questions and answers,so you could also report on sales by price type by (not necessarily zip code) survey question in T-Stats.

Also I want to clarify that the option Kevin mentioned, regarding if you do not use customer_no 0 for General Public orders, on the T-Stats side does not expect a single non-zero constituent ID. Rather, that parameter in T-Stats allows you to specify the ID of a constituent type used for General Public orders, which may have one or more constituents associated with it. 

Thanks for that clarification, Amanda. And it applies to Tessitura Analytics as well, i.e. you specify a general public constituent type). What's the emoji for that feeling when you didn't reread the documentation you wrote yourself very closely before answering a question...

Be careful about using accounts for multiple customers as might be envisioned in this discussion.  (Create an account for Zip Code 08904 and then everyone in that zip code who does not give a name sharing the one account.)

There was a change in Tessitura V14 and V15 that makes it likely that you will eventually charge the wrong customer if you are storing lots of credit cards for different customers on these Zip Code Accounts. 

See the following link https://www.tessituranetwork.com/Items/Support/Alerts/2019/Generic-Constituent-Accounts

Thanks, Tom, for pointing this out. We are already investigating our stored account practices in anticipation of moving to P2PE; this just adds another thing to the list of considerations, I guess.