Print (Non-Email) Campaigns & Responses:

There are three ways of responding to a print campaign, either via phone call, BRCs (business reply card/snail mail), or (optionally) WWW/email. If the correct tracking information is printed on the print campaign pieces, we can track the response rates for individual mailings and by individual people. [I don't think anyone would have multiple sending methods (mail and email) for the same campaign – these would be different campaigns, even if the 'creative' was the same.]

So, we want to print a short, unique number on each outgoing mail piece, identifying the person and campaign. Ideally this will be in both human-readable and machine-readable format (perhaps we will print a bar code?).

The recipient may respond via mail, typically via Business Reply Card (BRC)
• The data entry person should have the Campaign number and Contact person id (perhaps in bar code format) on the response vehicle for easy data entry.

The recipient may also respond via phone. We want to show, on the Case screen, a dropdown of all the campaign mailings a Contact person has received.
• If they respond to a mailing via call, we correctly track the responses and tie them to the correct campaign. The contact could read the campaign mailing number to the call center rep over the phone.

If enabled, the recipient may also respond via email or web page.
• If the internet was a viable response method, the Contact could email a response to the email address on the mailing, or the Contact could enter the same number on a web page if a response URL was provided. Extra security would be needed to protect privacy, so that simply guessing a number similar to the one you received would not work.

Design ideas:

1. Generate campaigns mostly as current in Sugar CRM. Add ability to tie an attachment to the campaign, so a call center rep can bring up a PDF of the actual mailing.
2. Assign a Campaign Number to uniquely identify campaign (with something small that a person can read back over the phone) – this might be analogous to the 'generic response URL' of email campaigns.
3. Enable a 'Generate Campaign Mailing List' function that generates the mailing list CSV (or tab-delimited) file, and marks the Contact record as having been sent campaign "Campaign Number" on date "Today" (or a different user-selected date to allow for processing time). Current Sugar campaign module methods of sampling, etc. would be good.
4. Print a CSV file list of people to receive the campaign, with the Campaign Number and the Contact person ID (again a short ID that people can read over the phone), or a combination of the two IDs. (i.e. 113-987654, where 113 is the mailing and 987654 is the Person ID), or a hash of the two – this might be analogous to the 'personalized response URL' of email campaigns. This field might optionally need a checksum/security field (see item 7) to make sure errant responses are not processed as correct responses if response vehicle is email or WWW.
5. These numbers will be printed on each outgoing piece of mail, on the part of the mail that would be mailed back to us (the BRC) and/or whatever other part of the mail piece as seems desirable. (For example, we might print it as bar codes on the BRC and in larger letters elsewhere on the mailing.)
6. If a Contact responds to the campaign via phone, and does not have the mailing in his hand to read off the Campaign Number, the dropdown on the Case screen would show all the campaigns the Contact person had received, and the call center rep's knowledge of the campaign contents (and/or ability to bring up the PDF of the actual mailing) would help the rep select the correct 'campaign responding to' value. (i.e. 'Does it have an orange sun in the upper corners?' = Campaign 113)
7. Email and Web sites are a little more complicated due to the anonymous nature of the internet. If a Contact responds via email or a web site, we would ask them to enter the Campaign Number and Contact ID and something else to identify them as the recipient of the mailing. This extra information would be for security (a checksum? Minutes + Seconds of Contact record created time? Whatever, but something is required) to make sure that a correct Campaign number but an incorrect-but-exists Contact ID number would not have us opting in / mailing to the wrong person. (i.e. 113-987654-XYZ, where 113 is the mailing, 987654 is the Person ID, and XYZ is the security code. This XYZ suffix would only be needed to be printed on the mailing if 'WWW/Email' was one of the possible response options.)
8. The end result is that we will know everyone who received a given mailing, and everyone who responded to it, via any method.
9. We want to be able to generate future campaigns based on who did and did not respond to prior campaigns.