As we reported in the Next Gen webinar this week, Release One of the Next Gen software will focus on Constituent themes. We have already asked about Constituent Search and Constituent Relationships. Today’s question surrounds Postal Addresses (we will ask about email, webpages, phones etc. in a separate thread).
Thinking about Postal Addresses in your business, some very BROAD questions:
What are some challenges that you have surrounding addresses today?
Are there trends you are seeing that could impact postal address functionality in the future?
What do you like about Postal Address functionality in existing Tessitura?
What would you like to see changed/improved about Postal Address functionality?
Any other thoughts about addresses, your business, and Tessitura?
(For extra credit: We ultimately take user requirements and express them as “stories”. Feel free to answer this thread however you’d like, but for fun, you could answer in the form of a “story”. An example of a story might be: “As a Special Events Director, I need to be able to send Gala Invitations that include very formal addressing (Street rather than St., Boulevard rather than Blvd), even if this isn’t the mailing convention for other aspects of our business.”)
Thanks!
Andrew
What I like about postal addresses currently is the ability to tie it a specific salutation, the seasonal months, and mail purposes. For the most part this works really well for me.
However, I hate that addresses are tied to phone numbers because most people have cell phones that are not tied to an address. When an address gets inactivated if there is a phone it gets inactivated as well, when very well it’s an accurate one. It allows for a lot of user error if someone forgets to move the phone when inactivating an address. I think phones (like emails) need to be kept separate from addresses entirely.
The story that happens to me most often relates to foundation and corporate records. For example, I need to pull an event list. Corporation ABC meets my select criteria, however N2 on that record is the contact for our corporate coordinator. I want to send the invitation to the CEO, COO, and CFO of that company. Right now I pretty much have to manually do that. I wish that I could create 3 salutations, 3 addresses tied to each unique salutation, select “Invitations” as my mail purpose and have them ALL pull into a list. When I look at a list of 20 I have to think to myself its really 40 because there are two people from each organization being invited. And I have to remember their names, and titles, and add them manually to my spreadsheet before I do a mailing.
In an ideal world you would be able to mail to multiple addresses/salutations for one record. Though of course I don’t know how you would actually do that.
What happens to me with foundations is usually that the giving is from the foundation but we want to invite the individuals at their home address. I can manually create a home salutation and address with an event mail purpose (which is what I do now) on their foundation record, but it seems clunky since I’m basically duplicating information from their individual record. I wish that there was a way to select the address I want to mail perhaps through associations? I can see that these constituents are related and while one record meets my criteria I am choosing the address from an associated record. This would also be helpful if I wanted to invite multiple board members from that foundation, I could then choose multiple home addresses or similar to the corporate suggestion have the ability to choose multiple names tied to the foundation address.
-Marta
From: Tessitura Next Generation Forum [mailto:forums-nextgeneration@tessituranetwork.com] On Behalf Of Andrew Recinos Sent: Friday, January 15, 2010 2:37 PM To: marta@smm.org Subject: [Tessitura Next Generation Forum] Addressing addresses
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!
Spam Not spam Forget previous vote
This input is coming from a database wonk, so its not entirely related to user experience, but with that caveat:
The time restrictions on addresses are great but I think there must be a more elegant way to deal with that information both in the user interface and the database itself. Currently, the default is to have each of the monthly check boxes filled which muddies up the front end and adds more data to the record. I would love to see a system in which an address is assumed to be for all time periods unless there is an indicator that the user can see (it would be in a different color, for instance).
Also, the month by month selection is restrictive. You should be able to add a very specific restriction that is either a one time occurrence or a recurring action. Story time:
A) A board member is going to Europe for three months. During that time, they should not be sent any mailings. So I can enter it as "No Mail Delivery 04/15/2010 - 06/30/2010 - no recurrence"
B) We have "Snow Bird" constituents who go to Florida every summer. The restriction is then entered as "No Mail Delivery 06/01 - 08/27 - annual recurrence"
As a bonus, the snow birds gave us their Florida address and we have entered it in Tess. The system then knows (by date) which address should be their primary one and displays the appropriate address on the constituent screen as well as in lists, extractions, etc. (For the DBAs in the room, I am envisioning a TX_ADDRESS_RESTRICTION table.)
I second the vote for de-coupling phone numbers from addresses. I know you can enter unrelated phone numbers now but under the current arrangement, its not an intuitive move.
Finally I would absolutely LOVE a process that checks the format of the address against USPS naming conventions. The user should be able to override it if they want, but if they spell out "Street" instead of "St" a pop up should alert them. We are currently using a script (which I think many others have as well) that auto-corrects certain items in the address but notifying the user at the time of entry is a good way to help enforce consistent data entry and ultimately helps get better results out of mailings.
In the current system, I love the ability to click on the stamp to get an envelope. I would love to see this expanded a bit so you can select from different types of documents. Form letters for instance.
"Thank you for your call today regarding _____. I hope that we have resolved the situation to your satisfaction. If you have any further questions please contact <tessitura user's name and contact info>."
This may have something to do with my love of Mad Libs.
Can't wait to see how the constituent record evolves in the next generation!
Seattle Rep is closed on Mondays
twitter.com/seattlerep | facebook.com/seattlerep | blog.seattlerep.org
Please consider the environment before printing this e-mail
From: Marta Garczarczyk <bounce-martagarczarczyk9387@tessituranetwork.com>Sent: 1/15/2010 3:44:17 PM
From: Tessitura Next Generation Forum [mailto:forums-nextgeneration@tessituranetwork.com] On Behalf Of Andrew RecinosSent: Friday, January 15, 2010 2:37 PMTo: marta@smm.orgSubject: [Tessitura Next Generation Forum] Addressing addresses
SpamNot spamForget previous vote
I'll second Christy's issue with the billing address. This is especially a problem for us on the web where the patron doesn't read the messaging that tells them the address has to match the billing address and then calls us very angry that our website keeps rejecting their perfectly valid card.
Controlled addresses can be an issue for us.
Story:
A patron calls the main box office to report a change of address. The operator changes the address on the General tab, but also needs to make sure that all corresponding controlled addresses at all organizations in the consortium are changed.
Andrew,
Stacy in Patron Services is talking to an important donor who provides several addresses for his account. One of the addresses on his PERSONAL account is his office address at “Large Financial Corporation” So Stacy feels that the address should look like this:
Mr. Big Bucks Salutation
Director of Important Stuff Business Title
Large Financial Corporation ???????
51 Liberty Plaza Street1
Room 20DA157g ???????
New York, NY 10017 City, State, Postal Code
Stacy needs places for all of this kind of stuff. But the account is not an official “Large Financial Corporation” account. So this should not show up as a name on the account.
She runs into a problem setting up this kind of address today because there are not enough fields so she compromises. She puts in the address this way.
Large Financial Corporation Optional Address (t_address.street2)
51 Liberty Plaza, Room 20DA157g Street1
Stacy does not understand what address type is about so she puts this in as a home address. Because this is easiest and this is not for an for an official corporate relationship. “This is a personal account for sure.”
She then needs a way to mark that this is where Mr. Big Bucks wants his tickets sent, and other addresses are for other things on this personal account. The corporation information is only an aid for delivery. It is not an official relationship with the corporation. An OK compromise from Stacy’s point of view. She gets the tickets out to the customer. The customer come to the show. Everyone seems happy.
Then (Story 2),
When Joe the IT guy send the data to data from story one above out to NCOA review he has to keep all of these things separate.
Room 20DA157g Street2
New York City
NY State
10017 Postal Code
USA Country
When Joe is looking to send this data for NCOA processing. The NCOA processor wants Company Name, Name, Street1, Street2, City, State, Postal Code. The problem for Joe, that gives him Gray hairs and keeps him up at nights is that because we do not have a clear place for a Corp Name in the address
In fact it is likely best if he sends the following address to be checked
He needs to be able to filter on Country Code so he does not send any international items to the NCOA process. NCOA does not process international customers.
The issue is that Joe has a hard time teaching the computer to guess exactly what is in which fields in the address.
Andrew I have lots of other stories about addresses but it is getting late.
For example:
o The one about the guy who moved while his order was still open.
o And the one about the guy who moves and 3 months later provides a change of address card to the USPS, and the marketing manager who want to get his new address back on the account.
o And the one about 40% of the customers on the web site who put all of their information in lower case and the Ticketing Services Agents who have to go in and manually correct the addresses
o And the one about the Tessitura team that cannot decide on a standard on addresses, and does not want to use the All uppercase USPS preferred standards, and yet want the Tessitura system to automatically update the addresses to keep them standardized.
o And the one about the Development department that wants to manually maintain all of their addresses because they do not trust a automated system to maintain the addresses.
o And the one about the USPS changing standards about what is an acceptable address
o And the one about the USPS increasing the number of times a year that addresses have to be reviewed for NCOA
o And the one about the E-Marketing Manager who wants to get as many email addresses on the web and create accounts, but does not want to have to get street addresses to create the account.
o …
--Tom
From: Tessitura Next Generation Forum [mailto:forums-nextgeneration@tessituranetwork.com] On Behalf Of Andrew Recinos Sent: Friday, January 15, 2010 3:37 PM To: Thomas Brown Subject: [Tessitura Next Generation Forum] Addressing addresses
We coincidentally enough just discussed the exact scenario in a meeting today prior to me reading this. We are 100% behind Tom’s suggestions!
From: Tessitura Next Generation Forum [mailto:forums-nextgeneration@tessituranetwork.com] On Behalf Of Tom Brown Sent: Friday, January 15, 2010 7:32 PM To: marta@smm.org Subject: RE: [Tessitura Next Generation Forum] Addressing addresses
Hi -
These are my addressing stories:
Story #1:
In the ticket dept we are totally QAS compliant to ensure deliverability of tickets. Accounts built over the phone are certified when they are being built and we have put the QAS interface on our website. We routinely QAS the addresses that slip through uncertified (although we do not keep everything in upper case letters as the PO would prefer.) This serves us well and we do our best to ensure that our ticket agents (including those at the window) are always using the QAS tool.
However - our colleagues in development have different addressing needs as has been discussed. Ultimately we decided we needed to identify high touch patrons at-a-glance so as not to defeat the standards of the development dept. or the personal wishes of the high touch constituents (ex: we have a group of suburbs that the PO treats as Barrington and some of the constituents that live there insist on North Barrington, Barrington Hills, etc. which makes no difference when the address has the correct zip code but does make a difference in the patron's perception). We identified these high touch patrons by their donor constituency and our ticket dept custom header shows their address in grey which indicates to us to leave the address alone if we have the patron on the phone or when making an address change to type it exactly as the patron wants regardless of the QAS rapid addressing feature. Yes, we still also use the Mail Purposes flags for specific purposes like Formal Invites, but the 'greyed out' address tells all who touch the account how to proceed.
Story #2:
In tickets we are often printing a name and address in a tightly confined space, and for this reason, we used the Mail Purposes flag for high touch accounts that involve a corporate address and title to create a full but abbreviated address that could print on subscription forms. Essentially this address would be an edited duplicate of the primary address. Problem being that when an address change was done the Mail Purposes flag for Subscriptions may have been overlooked. Suddenly Mr. VIP's renewal form is going to an old address and that is not good - would love to see a dialogue box that other Mail Purposes exist and should be reviewed.
Story #3
Phone numbers: like everyone else we have been finding that the phones no longer are strongly associated to the primary mailing address and we have been in the processing of converting any phone to, what I refer to as, "below the grey bar" with an appropriate description so that we can easily see the active phone numbers, business N1, home, cell N2, assistant N1, any time we go to the General Info screen without having to search through multiple addresses to find a phone where we can reach a patron in a pinch.
Hope these help.
Paula
As a Consortium a key Address issue for us is the constraints of a single Primary address; the way that it and its Salutation is presented on the General Tab, and how to handle differing views of a single mail purpose in different organisations. It’s a tricky area trying to balance the benefits of sharing within a Consortium against the need to protect and control usage within each org.
Mail Purposes is good functionality but we realised early on that we couldn’t use MPs on any ‘shared’ cross-consortium addresses. This is because, for example, what one org considers an Invite address another may not.
Because the Primary Address is exposed to all Consortium users, on any Addresses where these things matter (donors, subscribers, media, other corporate contacts) then orgs often have to create their own control-grouped address types and Salutations, join these two then apply Purposes there.
This is a clumsy process often requiring duplicate data entry on every address and Salutation. It also relies on Users understanding the notion of shared and cg’d addresses and where they can and cant apply Purposes. It only requires one accidental application of a Purpose on a shared or primary address to undo any Purposes work on cg’d addresses.
End result is that some key areas are working exclusively with cg-d addresses and salutations and have to learn to pretty much ignore the General Tab.
But on the Address tab when combining a Salutation with an Address the result of that combination is never actually viewable (as it is on the General Tab). This is not ideal for operations working with sensitive client info and is constantly a point of confusion for users who don’t use Tess regularly.
So kind of backwards story-wise (ie the story is post NextGen)
· Peter the Philanthropy manager at ConsortiumPartner1 is inviting Mr Rich to an opening night event. Mr Rich is a donor. Peter uses the private home address that only he and his team know about. He wants to use this address for all invitation activity and includes a personal salutation “Dear Richie”. He can also see Mr Rich’s business address which Peter considers the ‘primary’ address for other general business purposes. This includes his Organisation and Job Title info and should be the default address for any activity Peter does if he doesn’t specify a purpose for the correspondence. Peter chooses not to view any other addresses, but could add to his view another ‘shared’ address which is the Business PO Box that the Box Office had garnered from a ticketing purchase and which CP1 has made available to the Consortium. CP1 want to use this shared address for all ticketing activity in the future.
In reporting on the Opening Night activity even though Mr Rich was invited at his private address as a Donor, Peter wants to be able to provide his CEO with Mr Rich’s job title and organisation.
· Lesley is the Subscriptions Manager at ConsortiumPartner2. Mr Rich is a subscriber, he uses his personal PO Box for all subs activity from CP2. Lesley considers this Mr Rich’s primary address. It’s the only address she wants to see, she considers it ‘her’ address.
· Matt is a Box Office seller at ConsortiumPartner3. Mr Rich has telephoned CP3 for the first time to buy tickets to a show. He searches for and finds the record CP1 had created with the shared address. Mr Rich actually provides the same home address that CP1 considered ‘private’ to have his tickets mailed. Matt adds this to his address view and indicates that its to be used for all ticketing activity from CP3 in the future. This doesn’t effect CP1’s setting of the shared address as their ‘ticketing’ address.
Too easy …
peter nelson business analyst
information systems
pnelson@sydneyoperahouse.com
T+61 2 9250 7180 F+61 2 9251 7821
SYDNEY OPERA HOUSE BENNELONG POINT
GPO BOX 4274, SYDNEY NSW 2001, AUSTRALIA
SYDNEYOPERAHOUSE.COM
From: Tessitura Next Generation Forum [mailto:forums-nextgeneration@tessituranetwork.com] On Behalf Of Andrew Recinos Sent: Saturday, 16 January 2010 07:37 To: Peter Nelson Subject: [Tessitura Next Generation Forum] Addressing addresses
Please consider the environment before printing this email. =====This message is intended for the addressee(s) named and may contain confidential information. If you are not the intended recipient, please delete it and notify the sender. Views expressed in this email are those of the individual sender and are not necessarily the views of the Sydney Opera House Trust=====
We would like to be able to rank address types when extracting them.
Story: Say, hypothetically, that Opera Company operates in a consortium. The marketing manager mails out thousands of subs brochures. Some recipients have a number of address types eg Opera Board Address (home address, maintained by CEO's office), Opera Donor Address (home address, maintained by Development department), Consortium General address (maintained by Box Office operators across the consortium). She needs to create a list with the most correct address for each constituent, order of priority eg if constituent has a Board address, select that; if not, select Donor address; if not select General address etc.
AND she needs correct salutation with each address type, so the salutation allocated to that address can, if she chooses, be extracted with it.
AND she needs to have access to all these addresses and salutations to extract them, even though she may not have user rights to edit them (here, we cross into control-grouping territory).
Just ran into another one:
I need to run the membership renewals utility, and exclude bad addresses. If the address is inactive, no problem; but since you can't inactivate a primary address, and you must have a primary address on all accounts, this leaves me with a problem. I could run a list of bad addresses (which, incidentally, would be looking for both "NCOA$DNM" coding as well as another technique that we can use to mark bad addresses ad hoc)...trouble is, I need to use my list filtering option to segment my renewals for tailored messaging. Having to use it for both makes the whole process much more complicated.
Moral: any address marking (eg for bad addresses) needs to carry through ALL aspects of the db systematically. Once you mark something bad in one of the standard ways, you should never have to wonder if it will be excluded - you should know it will be.
I've been thinking about addresses and noticing that Development departments seemingly everywhere are much-maligned in their attempts to "manage" addresses in their own ways. Thought I might share some of my thoughts, from that point of view. =) Keep in mind that Lyric's IS Director recently asked me if I'd "gone over" and "finally seen the light" about letting everything be QAS'd - to which I answered "No." But that got me thinking about why - because obviously it is a ton of work with a fair amount of duplicate effort to accommodate separate addresses. So we looked at our database - 1.3% of the active customers in our database had more than one active address. Of those - the percentage jumped to 6.3% of our customers with our what I will lump together as "important" constituencies. Then, when I looked - we aren't managing separate/additional address locations, necessarily. The number one thing we are doing is managing a STYLE of addressing. Example - an Invitation Address -- all the data is exactly the same - but it appears differently: "Mr. and Mrs. James C. Pritchard" (not JIM AND BONNIE) and "Street" (not ST with no period) are written out. Right now we select this via a combination of Formal Invitation Salutation Type and Mailing Purpose of "I" (for Invitation). It's not really a purpose, though. It's a STYLE. I think that Purposes and Styles are different. Could Purposes contain Different Data?? E.G. Invitation Purpose would be the home address instead of the corporate address?? And then Styles could be an "overlay" that did lovely looking, Development Department-approved formats of the same information?? To me that would save a lot of time in invitation review, etc. by not having to update and audit if a home address changes, you have to change and modify all the addresses. One of the examples that we struggle with Addresses is with Invitations when a corporate-type Board member wants his invitations to go to his house so that his wife knows what is going on - or, he might want TWO invitations to be sent - one to the office to his assistant who manages his calendar, and one to his house so his wife knows what is going on and what to wear. We manage this really well with a series of Attributes right now, but it would be nice not to have to. I am just talking here - I'm not trying to muck up things, as obviously a number of address management issues would need to be reworked, and this is the beginning of an idea. But, frankly, they will have to be reworked anyway if the constituent model is going to look different than how it does now, so we might as well talk about it. So, have at it, friends. Erin
I've been thinking about addresses and noticing that Development departments seemingly everywhere are much-maligned in their attempts to "manage" addresses in their own ways. Thought I might share some of my thoughts, from that point of view. =)
Keep in mind that Lyric's IS Director recently asked me if I'd "gone over" and "finally seen the light" about letting everything be QAS'd - to which I answered "No." But that got me thinking about why - because obviously it is a ton of work with a fair amount of duplicate effort to accommodate separate addresses.
So we looked at our database - 1.3% of the active customers in our database had more than one active address. Of those - the percentage jumped to 6.3% of our customers with our what I will lump together as "important" constituencies. Then, when I looked - we aren't managing separate/additional address locations, necessarily. The number one thing we are doing is managing a STYLE of addressing.
Example - an Invitation Address -- all the data is exactly the same - but it appears differently: "Mr. and Mrs. James C. Pritchard" (not JIM AND BONNIE) and "Street" (not ST with no period) are written out. Right now we select this via a combination of Formal Invitation Salutation Type and Mailing Purpose of "I" (for Invitation). It's not really a purpose, though. It's a STYLE.
I think that Purposes and Styles are different. Could Purposes contain Different Data?? E.G. Invitation Purpose would be the home address instead of the corporate address?? And then Styles could be an "overlay" that did lovely looking, Development Department-approved formats of the same information?? To me that would save a lot of time in invitation review, etc. by not having to update and audit if a home address changes, you have to change and modify all the addresses.
One of the examples that we struggle with Addresses is with Invitations when a corporate-type Board member wants his invitations to go to his house so that his wife knows what is going on - or, he might want TWO invitations to be sent - one to the office to his assistant who manages his calendar, and one to his house so his wife knows what is going on and what to wear. We manage this really well with a series of Attributes right now, but it would be nice not to have to.
I am just talking here - I'm not trying to muck up things, as obviously a number of address management issues would need to be reworked, and this is the beginning of an idea. But, frankly, they will have to be reworked anyway if the constituent model is going to look different than how it does now, so we might as well talk about it. So, have at it, friends.
Erin
Erin,
The idea of an address Style resonates with what I am seeing here. And the separate idea of address purpose (what we are to send to each address). Thickets, Invitations, Contribution acknowledgements covers a lot about the small number of situations when we have multiple addresses.
We also have multiple addresses because we have kept old addresses as inactive when people move and we get this information as part of the NCOA process. In the long run we think this can give an interesting long term perspective on a potential customer. (This customer moved from a less affluent area to a more affluent area, and then back to a less affluent location. Or the customer repeatedly moves from NYC to Florida and back again.) However, we are likely to move away from this because it has been complicated to keep this data and the new Tessitura Network provided NCOA process does not permit this kind of process.
From: Tessitura Next Generation Forum [mailto:forums-nextgeneration@tessituranetwork.com] On Behalf Of Erin Koppel Sent: Friday, January 29, 2010 3:27 PM To: Thomas Brown Subject: Re: [Tessitura Next Generation Forum] Addressing addresses
From: Beth Varro <bounce-elizabethvarro6946@tessituranetwork.com> Sent: 1/21/2010 3:47:17 PM
I second many, many of the issues already listed here! Especially, Rebecca's point about ranking multiple address types (this is a HUGE issue for us here at Yale) and Erina and Tom's points about multiple address types/purposes/styles etc.
We have not made use of the Mail Purpose flags in our consortium, mostly because by the time we divide them up among the consortium members, there really aren't enough of them to be useful. As a result, we are using Address Types for everything, including different addresses, different styles of addresses, and different uses for addresses, not to mention addresses that are private to a specific consortium member.
We also are in the practice of keeping old addresses on file as inactive addresses in order to make a historical record of customer addresses available to the users. This information is especially helpful to our users when they are trying to determine if two accounts are duplicates or if they are two different customers with the same name.