Campaigns

Use this page to collect requirements for modeling 'Campaigns' in a future release/component...

Laundry List of Possible Requirements

Basically a campaign is a group of actions for which an organization wants to track inputs and results. Defining effectiveness measures and being able to compare these across Campaigns is key requirement.

Campaigns may be classical fund-raising efforts - but Advocacy, GOTV, etc. may also be modeled as 'Campaigns'. For a fund-raiser, effectiveness measures may be relatively simple ROI based calculations (hard costs + staff and volunteer hours compared against money raised).

• Campaigns have 'meta' properties (name, start date, end date, active).

• Campaigns have 'contacts' who are 'owners' (folks responsible for implementing them) - and might have a hierarchy of owners (development director + associatees + fund-raising volunteers + corporate partners, etc...)

• Campaigns have 'contacts' who are 'targets' (potential donors, email recipients, event invitees and attendees, volunteers solicited and engaged, voters, petition signers...)

• Campaigns have goals (possibly process as well as end-result oriented). e.g. make phone calls to 1,500+ people, raise $300,000, etc.

• Campaign actions have costs items to be entered and aggregated (room
  rental, food and drink for party, etc.).

• Campaign effectiveness measures need to be summarized and compared
  to previous campaigns and budgets/goals.

Modeling this data for the varied needs of different organizations will require some combination of generalized data objects with customizable extensions.

Ideas for Implementation w/in CivicRM

Essentially, campaigns are collections
of action objects.

I take some actions (send these 4 groups emails,
record that these 20 people donated on my special web
page, etc.), analyze those actions, a get come results
(I send out 500 emails and got back 20 donations with
a total value of $1000).

In the CiviCRM case, we would add a foreign key to the
action entity to associate actions back to a campaign
entity.

It seems like campaign would be handled better by a
campaigns application separate from CiviCRM. Actions
get logged in CiviCRM with a campaign ID from the
campaign system.

The campaign system gets a list of all the actions for
a given campaign ID. It combines the bare bones action
attributes it gets from CiviCRM with the richer action
attributes stored in the campaigns system with still
richer action attributes stored in the external
systems that registered those actions with CiviCRM.

From that big set of actions tagged with the same
campaignID, it starts to display 40 of action type A,
20 of action type B, 10 of action type C. For each of
those creatures it creates aggregates.

Action A is an email was sent.
Action B is a click through on the email.
Action C is a donation.

The campaign system compiles aggregate data about the
different actions.
Action A- the email was sent on 2/2/05
Action B- the click through was on 2/3/05. It took an
average of 1 hour for users to click through.
Action C- it took an average of 1:10hrs for a donation
to be made. Total donation volume is $1000 across 10
donations. Average donation is $100.

If we adopt this approach, the only modification to
CiviCRM is the addition of a campaignID attribute to
the action entity.

Or, we could add "two data values" to the
action entity. (At GS, we called those values:
RemoteKey and RemoteData). We don't really
specify/care what those values are, its for the module
to decipher and make sense of how to use those values
appropriately. Thus actions associated with a campaign
could store "CampaignId", RealCampaignId in the (key,
data) pair.

Campaigns from an Activism Perspective

(Ideas contributed by Aaron Kreider - campusactivism.org)

I think campaigns are extremely important.

In my activist world, it makes the most sense to model a campaign
based on the Midwest Academy model (see "Organizing for Social
Change." and notably the Strategy Chart – http://slac.rso.wisc.edu/flyers/strategy-chart.pdf).

We probably don't want to include all of the elements that the
Midwest Academy has for their campaigns. But possible items to
include would be goals (long term, medium term, short term), targets
(primary, secondary - people who have power to grant the goal),
constituencies and allies in support of the campaign, opponents of
the campaign, tactics, a timeline, and progress reports (campaign
updates).

For the basics, I went with a campaign name, short description, the
ability to relate it to other things (events, online resources,
groups, people, email lists, etc) and the ability for groups or
individuals to write campaign updates. I figured most of the
strategic information for a campaign can be on the campaign's
website(s). But now on second thought, I strongly believe that having
a structure that went into more details (ex. asked for campaign
goals) would give activists a useful push - because having an
explicit strategy is a good thing, particularly for people who are
new to political action. The most common error made by people who
want to change the world is to not use a strategy.

User Narrative for Political Campaigns

(contributed by John Springer (Democratic Party of Oregon) - john at dpo dot org )
I think what you need to do is use CRM as a master list
of people, and then have a way to filter people, put them
into some specific program, and them do detailed stuff
within the context of that program.

This applies to fundraising "campaigns", but it also
applies to managing volunteers for a political campaign.

1. You start with a pool of volunteer prospects, typically
past volunteers or people who've said their willing to help
or signed up from some event or web site or whatever.
All these people need to be in the CRM, with some attributes
that helps you select prospect. And of course, new people are
popping in all the time.

2. You start contacting these people to see if they are
willing to participate in the current campaign, and in what
ways. People's willingness to get involved depends on
the issue or candidate, what else is going on in a person's life,
like did they break a leg last week. In other words
a person volunteers for very specific things at specific times.

3. You need to keep track of which prospects you've contacted, who said yes, who said no, who said later, and who you called 3 times and never got hold of so it's time to give up until next month. This is the part that most systems don't handle well.

Then you constantly need to check your call-backs, and to contact new
people who are new to the prospect list.

4. Having identified a list of people who are your real volunteers,
then you have to manage the details, which is very specific to the type of
program you're doing. For a fund-raising campaign it's a set of contacts and receipts and thank yous and cheap banquets.

For recruiting volunteers, it's who's showing up thurs at 7pm at each of 3 phone banks and who scared away the other volunteers so you need to find something else for them to do.

So I've concluded that these campaign things are very complex in their
own right and should be handled as ancillary applications that work off the
people in the CRM but have their own structures and mechanics.
Some thought about how they might hook in (step 3 above) might
be useful now.

Possible Implementation Approach

(response to John Springer by Dave Greenberg)
RE: item 3 (keeping track of your "contact contacting" results...) -
our initial thoughts on how this might be handled in CRM goes
something like this...

1. Create a set of custom properties for 'Campaign Tracking'. These
could include:

• Campaign Name (drop-down list)
• Status (drop-down might include - 'not yet contacted', 'need to call
  back', 'volunteered', 'not available'...) [or could separate Contact
  Status and Response fields..]
• Last Contact Date
• Next Contact Date
• Campaign Notes

( Our data model supports multiple instances of custom property data
sets - so any contact could have this same set of fields populated for
a series of Campaigns. )

2. Create and save a search query which identifies current prospects
for the campaign (based on relevant existing properties).

3. Work down through the search result set, contacting each prospect.
For each contact - complete the Campaign Tracking fields.

4. Callback scheduling can be managed via another (saved) search, e.g.
"Show me all contacts with Campaign Name = "My First Campaign" and
Status = "needs callback" and Next Contact Date <= today.

OR

We have also been considering adding a Task List functionality to a
subsequent release. This would allow callbacks to be
assigned/scheduled as a task (for self or another user).

5. New prospects could be identified by repeating the original search,
with the addition of Campaign Name <> 'My First Campaign' (should also
grab NULL Campaign Name folks).

Other than the 'Task List' feature - the mechanisms used in this flow
would be available in our initial release. Your thoughts on this
approach would be appreciated.