DIY training

Jennifer Reager · August 2017

I'm looking for any tips you have regarding RE training outside of Blackbaud University. Tomorrow I'm hosting a review session on some of our daily data entry and Operations functions. I've got my Powerpoints, some corresponding "how-to" handouts, and generally a good sense of humor.

Please share any useful acronyms and learning aids you've come across, or ideas for training follow-up and "homework," or just any stories about your training/teaching successes!

P.S. This particular session was inspired partially by my discovery of an inordinate amount of data entry errors, so I'm also accepting advice for doling out some tough love and motivation.

Ryan Hyde · August 2017

I don't have any good learning aids to share, but I was wondering what kind of data entry errors have you spotted? Some kinds can be rectified at the admin level (like mismatched appeals and funds, or funds and campaigns, etc.), while others can be monitored actively via queries. From my experience, nothing teaches someone like a little active monitoring for a few weeks. If you correct the mistake soon after the mistake is made, the person puts two and two together a lot more quickly.

Jennifer Reager · August 2017

Ryan Hyde:

I don't have any good learning aids to share, but I was wondering what kind of data entry errors have you spotted? Some kinds can be rectified at the admin level (like mismatched appeals and funds, or funds and campaigns, etc.), while others can be monitored actively via queries. From my experience, nothing teaches someone like a little active monitoring for a few weeks. If you correct the mistake soon after the mistake is made, the person puts two and two together a lot more quickly.

I recently pulled the fiscal year's worth of names and tributes for donor recognition lists. I haven't personally worked with that raw data in years (only spot-checked the "cleaned up" lists done by others). The output tells the story! I found some clear breakdowns in some of our everyday processes that led primarily to creating duplicate/triplicate constituent records and attaching gifts to incorrect tribute records, or the wrong type of tribute (mem vs. hon).

Most of the other stuff was carelessness and typos and perhaps a general disconnect about how the data fits together and works from start to finish, if that makes sense. I'm trying not to beat myself up for being too meticulous.

I'm hoping that the refresher course combined with the knowledge that this is all actively on my radar will help keep the team on their toes!

Jen Claudy · August 2017

Doesn't work for all staff, but sometimes it works to make the person who created the mess clean it up! Particularly something that has to be cleaned up manually. Ain't nobody got time for that! So if (and assuming you have buy-in from their supervisors) the person who didn't do due diligence and created new constituent records that are duplicates has to go in and merge them and clean it up (probably not deleting, but merging and keeping a list of ConstIDs for you to later spot check and delete), perhaps they'll take the extra minute or two to thoroughly search before creating duplicates if they think they're going to have to do the cleanup later.

roger berg · August 2017

Some errors can be avoided by adding drop down tables where possible. For instance, I had several (mis-spelled) versions of the same city until I changed the City tab to a drop down, cleaned up the table and locked it down so that not everyone can add a "new" city to the list. Same thing with titles, suffixes, and degrees.

In training (via procedure manual or in-person) I've found as a trainee and as a trainer that it's best to explain why we do things a certain way rather than just say, "do it this way." If I know that there is a reason behind the rule, I'm much more likely to follow it.

I do like Jen's idea of having the "guilty" party do the clean up

Jen Claudy · August 2017

Roger has some good points.

When I started at my last org, the City field was Text. I changed it to Table, and then had to clean up the table. Org is in Cincinnati, and staff all live in the area, but there were 17 (!) instances of Cincinnati (and there are really only 2-3 accepted abbreviations, so at most there should have been 4...maybe 5 if you used "Cin" which is a very old fashioned one) in the table. Most were flat-out misspellings. I got everything sorted out and ran the entire database through NCOA (using a mailhouse and Import, so I could clean every Address Record and not just one per Constituent). They gave me back all records formatted (even if there wasn't a move or other tag from the screening), essentially AddressAccelerator. That helped, too, because then everything was set to the USPS preferred City. It took a while to clean up the table, and if you do this, I recommend formatting with AddressAccelerator before converting the field from Text to Table. Wish I'd done that.

I know I prefer to know the reason why rather than just what to do, but I know not everyone thinks that way. Wouldn't be a bad idea, though, because at the very least it will stick in some people's minds that "there's a reason for this, even though I don't remember what, because she has a reason for everything and told us that in the training" and might get more folks to do it the way you trained them to.

Good luck!!!

Joanne Felci 2 · August 2017

roger berg:

Some errors can be avoided by adding drop down tables where possible. For instance, I had several (mis-spelled) versions of the same city until I changed the City tab to a drop down, cleaned up the table and locked it down so that not everyone can add a "new" city to the list. Same thing with titles, suffixes, and degrees.

In training (via procedure manual or in-person) I've found as a trainee and as a trainer that it's best to explain why we do things a certain way rather than just say, "do it this way." If I know that there is a reason behind the rule, I'm much more likely to follow it.

I do like Jen's idea of having the "guilty" party do the clean up

Curious: does RE come with a pre populated table with all the cities in the US or are you a local organization? I'm just wondering how you would set up and/or maintain such a thing. Never heard of this - interesting...

JoAnn Strommen · August 2017

No, RE does not come with a pre-populated list of all cities in the US. For us, everytime I add a unique city name it asks if I want to add that to the city table. Our list is only several hundred vs. tens of thousands if all were listed. For us 'Address City' is a table, don't remember from conversion if we chose table over text. If option were offered, I'm sure did after seeing lots of typos of "Rapid City".

I can definitely see with a large org where locking the table would be quite smart.

roger berg · August 2017

No - RE is not pre-populated with a city list. Cities had already been entered over the years as records were added to our database - the problem was that the City field was TEXT. I changed the type to TABLE which then pulled in all those existing (and duplicated with mis-spellings) city names. I simply went through and cleaned up the table. Each time a new city is entered, the system prompts to see if you want to add it to the list. I locked that down (some user cannot add or edit table entries) because some folks were autmatically hitting "yes" without making sure it really was a "new" city and not a bad spelling or weird abbreviation of an existing one.

If you somehow were starting with a blank database you would enter the city (or any other new entry to any other table) and the program would prompt you whether you want to add it.

Hope that helps!

Jen Claudy · August 2017

When you change the field from Text to Table, RE will populate the Table with entries based on whatever is in the Text field in your database. But if you have, for example, "New York City" and "NYC" in your database as text entries in the City field, you'll end up with a table entry for each when you change the field type. So I recommend do at least a little cleanup first.

Once the field is a Table, you can sort it like any other table, and you can intentionally reorder the entries. For example, at my last org, I moved "Cincinnati" to the top of the Cs, so that when typing in a new address, you just type "C" and Cincinnati comes up first. RE will then ask you if you want to add entries to the table when you type in a city that isn't in your table yet. This can help prevent misspellings. New entries are added at the bottom, so you can easily find them if someone accidentally clicks [Yes] to add a misspelled city to the table.

Faith Murray · August 2017

It's very interesting to note from Jen's post that switching from text to table will auto-populate the data. However, I don't think making City a drop-down item would work in our database, with people from all over the place and hundreds of new people coming in from new cities every year in our direct mail acquisition program. However, Attributes are another matter. In my opinion, no Attribute should be a text field - ever!

I've done training presentations for our organization, and they were very well received. The presentation, done on Powerpoint or Word, with an active RE account open for live reference, made an effective overview for explaining new processes and procedures. It seemed to work best to choose only one overview, or else 2-3 specific tasks, to focus on in a one-hour presentation. Anything more complex than that needs broken down into bite-size chunks. Although the presentation puts everything together, people don't remember everything afterward though, so I scheduled sit-downs with each of them individually afterward to walk them through applying what I had shown them as a group in the presentations.

Now, for maintenance, I send email updates one a month or whenever a new change takes place, or when I see a mistake being proliferated. I send an email "Database News" to all RE users (not pointing fingers), but then I also will send a private email to the culprit. Depending on the severity of the mistake, I may fix it myself, or make them fix it themselves. My guys are usually really good about trying to get it right, because they understand the need for accuracy, so once it's pointed out, they do their best to adjust.

Our P&P manual is also available on our server folder for anyone to reference (what there is of it -- it's still a work in progress). But, most people don't even open it. (sigh) Probably because you don't know to look something up if you think you're already doing it the right way!

Alan French · August 2017

Jen, do you know if it also works the other way, i.e. change a table-based field to text? Our subject field has so many different table entries and it's really frustrating not being able to query it using "contains"!

Jen Claudy · August 2017

No idea, Alan. I've never done it in reverse. My guess would be that you can uncheck the Config > Fields > Address > Lookup checkbox and it will just turn the table entry into text for every record.

Depending on your backup schedule, and how easily/quickly you can restore a backup, you could try it just after a full backup runs. Then, if it doesn't work as you want it to, restore your backup and move on. Or jump on a Support Chat and ask...or search the Knowledgebase, but I don't ever seem to have much luck with that option. =)

Alan French · August 2017

Thanks Jen, I can't uncheck the box though as it's greyed out - I wondered if you needed to do anything else first, as I know when I've changed attribute types I've had to delete them from all records and then import them back in afterwards.

Jen Claudy · August 2017

Sounds like you can't change it back to a Text field once it's a Table (Lookup). You might jump on a quick Support Chat and ask, because it might be like you mentioned that you have to clear out all of the entries before you can change it. Which you could do using Import to create an Import file (ImportID, AddImpID, City) and then Global Delete, clean out the table, uncheck [Lookup], Import the file back in. I would still check with Support first, unless someone else chimes in that they've done this. Otherwise you might do a lot of work for nothing. My preference is for the lookup table, so I've never looked into doing the reverse.

Andrew Ludwell · August 2017

This is less tips for the actual presentation, especially given it's already happened, than for you as the trainer.

A couple of ideas I picked up recently:
1. Give to training to anyone who asks how to do something - If they're asking, then they're open to it.

2. Ensure your user guides are easy to understand and supplement with bite sized How To guides for role specific tasks. If they're not using these, just bring them along to whenever you need to sit down with someone to go through something. This will reinforce their usefulness and hopefully lead to the user looking around for them. It's a subtle way to influence culture without ramming user guides down their collective throats!

DIY training

Comments

Categories