Changes

Hello,

It would be helpful to capture the reason some data is changed internally.  But, if the process to capture the "why" is mandatory and cumbersome I'm certain it will become meaningless (operators will just start clicking through). 

Would a free-form Reason field keep operators honest, in that they'd take the time to record the real "why" because there's no other choice, no dropdown?  Of course, they could type "Because" but mgrs could follow up on that kind of reason.  Not sure how a time-sensitive change (in line at the Box Office before a show) could be best managed...allow certain operators an opt-out of the mandatory process?

We've disabled the ability to make a name change to an account online, because we don't want subscribers to "will" their subscriptions to family or friends with a sneaky name change.  Any name change requests from the web come through as a CSI so that we can investigate.

Other than a name change, I think the patrons themselves should be able to make any changes directly online without any restrictions at all as long as they're informed of the consequences of changes.  We have QAS online and even when presented with a corrected address the patron CAN opt to keep the address as they entered it.  However, we display clear messaging that if they keep the bad address they might not get their tix in the mail or other correspondence. 

Thanks,
Mary

Getting back to constituent information that will need to be tracked... any change in the "Member of Link" which connects/disconnects individuals to their groups etc. will most definitely need to be tracked in the future.

In Heather's example - if the "Member of Link" was inactivated with a reason of "Divorce" would that have prevented the Dev Relations Manager from resetting the name (twice)? Don't know.

BUT, I would think that it would be mandatory to have those changes tracked - if organizational staff or self-serve web made an update to those links we would most certainly need to know that.

Getting back to constituent information that will need to be tracked... any change in the "Member of Link" which connects/disconnects individuals to their groups etc. will most definitely need to be tracked in the future.

In Heather's example - if the "Member of Link" was inactivated with a reason of "Divorce" would that have prevented the Dev Relations Manager from resetting the name (twice)? Don't know.

BUT, I would think that it would be mandatory to have those changes tracked - if organizational staff or self-serve web made an update to those links we would most certainly need to know that.

Currently, we make extensive use of the Constituent Audit Report so that key staff at each consortium organization can see who has made changes to their donors, subscribers and other VIP records.

We used to require that anyone making a change to a record send an email to the appropriate contacts at each organization, but, as you can imagine, this did not happen consistently.  We agreed that for our consortium, trying to enforce the use of CSI's was not practical for the same reasons.  However, having an added reason as to why a change was made would be enormously helpful.

There are a number of fields that aren't audited or that aren't in the standard version of the report, including Program Book Name, Alias, certain Attributes, and Associations.  We are considering trying to customize this report to pull in additional fields we'd like to track.

As far as future stories go, I agree with Erin that tracking changes to the Member of Link, including a reason for the change, would be very helpful.

Here are some current real life stories related to how we track (and would like to track) changes.

Jennifer works for the Art School.  She has a donor, Jane Doe, who is listed in the program book as Jane Doe Foundation.  One week when Jennifer goes to run the program book listings, she sees no entry for Jane Doe.  She looks in Jane's record and sees that the program book listing name is gone.  She doesn't know who made the change or why.  She sends some email around to her colleagues, but no one fesses up, so she adds it back in based on last week's spreadsheet.  She doesn't want to call the donor, because she doesn't want the donor to think we've messed up her record, but she's uneasy about adding the information back into the system in case the change was legitimate.

John works for the Dance School.  He reviews the constituent audit report every week to see what changes have been made to his big donors who are also involved with other consortium organizations.  One day, he sees on the constituent audit report that a donor's business address has been removed from the system.  He is unaware of any change in employment, so he contacts the department who made the change.  Turns out, the change was made by a work study student in error.  The student corrects the mistake, and the big donor gets the next mailing from the Drama School on schedule.

Mr. and Mrs. Smith buy tickets and give donations to several of our consortium organizations, but they are most attached to the Science Museum, where they are members.  Mrs. Smith calls the membership manager at the museum to let them know that Mr. Smith has passed away and asks that their account be updated.  The membership manager changes Mr. Smith's name status to Deceased and updates the shared salutations and the museum's salutations.  Jennifer, back at the Art School, sees the salutation update on the Constituent Audit Report and changes the Art School's salutations and their program book listing.  However, John at the Dance School doesn't have Mr. and Mrs. Smith on his watch list, because they are single ticket buyers.  Their ballet tickets are mailed with Mr. Smith's name on them.  Mrs. Smith is upset, because she already informed several University departments of Mr. Smith's death.