If you’re like us, you’ve probably had the experience of wondering exactly what a flag in your database signifies. Was “Xmas15” meant to indicate that this person should be sent the December 2015 mailing, that they made a donation in response to that mailing, or that they’ve promised to make another major donation at this time and someone needs to call them?
Without a well-defined and documented set of database rules, flags have a tendency to sprout like weeds. While whoever added the flag undoubtedly knew exactly what it meant at the time, memories can become surprisingly fuzzy in only a few months.
As companies have moved away from having in-house database experts, the importance of up-to-date database documentation has grown. You should follow industry best practices by creating a database bible and updating it every time you add a new flag or make any other changes to the database.
As you flag records, one thing to avoid is being overly conservative. If someone tells you they want to receive less mail, flagging them as a “once/year donor” may be too restrictive. And, for heaven’s sake, don’t mark someone “do not mail” unless they adamantly tell you never to contact them again. “Do not mail” essentially eliminates the chance that you’ll ever receive another donation from this person again.
As an extreme example of this, one company was taking “do not email” to mean “do not mail”. Correcting this misunderstanding added 20,000 potential donors who had not been contacted in some time back into their mailing list!
As workloads get heavier and heavier, it is easy to convince yourself that there’s not enough time to document your database changes. Please resist this urge! Your future self will thank you immensely, as will the person who takes over your database responsibilities in the future.
Want more than a cookie cutter approach? MMI Direct dives deep into your data
to determine how best to optimize your list and maximize your direct mail ROI.
