The User's Edge : Jennifer's Jargon

Jennifer's Jargon: User Groups

Jennifer Paquette — Wed, 09 Apr 2008 00:28:00 GMT

Friends,

Just had a conversation today with a client re: User Groups... Am a huge fan of the concept -- the formal Blackbaud regional User Groups are fantastic networking opportunities, as well as the chance to hear news about what's new and what's coming down the pike.

Even more important (IMHO) are internal User Groups -- meaning you and your colleagues get together regularly to chat re: how folks are using The Raiser's Edge to fulfill roles and meet organizational goals. As a client, I had standing monthly RE User Group Meetings. Each month we'd look at each other and think, "Do we really have anything to talk about?" and next thing you knew it was 1.5 hours later and we had discovered 5 new tips & tricks, uncovered a hidden process flaw and had a good laugh about it. It really helps to keep all users on a parallel track, identifies future power users and allows everyone to feels empowered to "own" and become experts on their piece of the system. Also welcomes new users into the fold and provides a level of soft training.

If you're not already doing it -- consider it! Maybe start with a light agenda over a brown bag lunch... Believe me, interesting conversations will quickly ensue -- everything from "What in the world does this attribute mean?" to "How can we empower our CEO to feel more connected to the daily stats?" Have different folks take notes at each meeting and assign follow-up tasks (i.e., creating a new query, searching Knowledgebase, contact Customer Support, etc.). Personally, I've observed that clients that host regular internal User Groups are ultimately much more successful, satisfied and retain qualified RE users longer than those who don't.

Until next time... :)

Jennifer

Jennifer's Jargon: Solicit Codes

Jennifer Paquette — Mon, 17 Mar 2008 21:59:00 GMT

Ever been confused by solicit codes? Maybe you inherited your database from someone else? Or maybe too many users have been allowed to add to your code tables? Either way, keep it simple -- solicit codes should be in the negative (i.e., "Do not solicit," "Do not call," etc.) BTW, "Do not email" is a completely unnecessary solicit code -- check the "Requests no email" box on the lower right-hand corner of the Bio 1 tab instead. If you're using solicit codes in the affirmative (i.e., "Send spring mailing," "Call during fall phonathon," etc), consider using constituent attributes to pull constituents into queries and exports instead.

Use "Do not solicit" sparingly. Think about it -- should this constituent truly never, ever be solicited for anything? Annual appeals, event participation, legacy giving, etc. -- not just now but forever and ever? Consider creating more specific Do Not Solicit codes instead. Personally, I don't appreciate phone calls, but am happy to receive a well-crafted case for support via email or snail mail. And (speaking from experience) might your constituent be highly offended if he/she didn't receive an invite to your fantabulous annual gala? The generic Do Not Solicit code might inadvertently strip him/her from that prestige mailing (been there, done that).

Am always happy to share real-life experiences and will continue to do so in coming blogs!

Jennifer's Jargon: Thoughts about Queries

Jennifer Paquette — Wed, 05 Mar 2008 06:09:00 GMT

Cheers! Am thrilled to be part of Blackbaud's new blogging forums...

As introductions are in order, I'm Jennifer Paquette, a Fundraising Solutions Consultant and long-time RE user (since 2000!). Am happy to share thoughts, advice, etc. from the perspective of both a Blackbaud Consultant and a Fundraising Professional / long-time client. Feel free to check out my background on my profile -- am betting there are many of us with quite a bit in common.

Suggestion for the day.... When creating RE queries, check the "Others may run" box, but NOT "Others may modify" box when saving your query. Why let others mistakenly ruin your hard work? Instead force them to save it as their own and then make changes. And why do I feel so strongly about this? Because I was that sorry soul who was constantly (and inadvertently) modifying my colleagues' queries -- I'd see a cool query and think "great -- I'll save myself some time and just tweak it." And then forget to save it as my own. Sort of peeved my colleagues who had invested the time in creating those complex queries.... Believe me -- protecting your queries saves everyone from grief!