CiviCRM provides tools for sending e-mails directly from the system, both to small sets of contacts (a single constituent or small group of constituents) as well as to large volumes of contacts. Later in this chapter, we will look at broadcasting e-mails using CiviMail in more detail. The line dividing easier, simpler, lower volume e-mailing and bulk, mass, or broadcast e-mailing is not always clear. Broadcast e-mailing is clearly appropriate when you are sending messages to thousands of recipients regularly as you need to know the open and click-through rates and segment based on that behavior, and you do not want to manually process invalid e-mails from the list or deal with temporarily unavailable accounts.
To keep things relatively clear, we'll call sending a non-broadcast e-mail e-mailing and follow CiviMail's terminology of referring to a broadcast e-mail as a mailing, and will always refer specifically to CiviMail rather than CiviCRM when dealing with bulk or broadcast e-mailing.
The simplest way to use CiviCRM to assist with communicating is to just click on any e-mail link it displays. For example, the Contact Summary page displays a contact's e-mails as clickable links. This will launch your e-mail client, placing the contact's e-mail into the TO: line. While this allows you to easily send an e-mail when looking at a contact's record, it may not be ideal from an overall CRM perspective as the e-mail will not be saved in CiviCRM. Fortunately, CiviCRM provides several tools to improve your ability to record e-mails directly in the system.
The question of what to retain and what not to retain in the system is important for your overall CRM strategy. Not all communications with all constituents need to go into CiviCRM. You must weigh the pros and cons of collecting and having too much information versus too little information. The former may create extra work ensuring the communications are stored and create a clutter of material to wade through in the system. The latter may result in other disconnected offline data sources being used to store and retrieve key information, or having insufficient history about interactions with a constituent. Once you've navigated these waters, develop a policy and procedure statement to guide staff which includes clear examples of what should definitely be included in or generated from the system, and what should not.
Many CiviCRM sites, perhaps the majority, just track auto-generated messages sent to constituents and broadcast e-mails. Some may choose to record a few manually generated types of official communications to their system, such as e-mails notifying grant winners in CiviGrant. Others may try to collate all e-mails, in-person meetings, and phone call records that are related to one another through CiviCRM, particularly in the area of case management.
Articulating an appropriate policy where just important and useful e-mails are tracked can be challenging. We've all seen e-mail threads with 14 entries just trying to set the time, date, and place for a meeting. These communications may be voluminous and have no enduring interest or significance. Document retention policies usually distinguish between different types of communications that have appropriately shorter or longer retention periods depending on whether it has continued relevancy or legal liability.
Your policy on what to put into CiviCRM needn't include all e-mails just because it is relatively easy to capture them, nor should it exclude phone and face-to-face conversations in advancing a file because of the extra work involved in documenting those interactions. Will the constituent expect the organization to "remember" an interaction? If so, it likely belongs in CiviCRM.
To make the system useful, and avoid significant wastage of time when something should be in the system but isn't, the policy needs to be clear and followed consistently.
As alluded to earlier, in addition to providing hotlinked e-mail addresses that will open in your preferred e-mail client, CiviCRM provides tools to e-mail one or more constituents directly from the system. Assuming you are about to e-mail something to a constituent that should be kept in CiviCRM, there are several ways to invoke e-mailing contacts in CiviCRM without using its broadcast e-mail component, CiviMail.
To e-mail a single contact on a Search Results page that has an e-mail displayed, select Send an Email on the More link at the right end of the row.
To e-mail multiple contacts from a Search Results page:
- Select one or more contacts, or choose the All Records radio button.
- Select Send Email to Contacts from the alphabetical listing on the -actions- button.
- Click on the Go button.
Third, from a Contact Summary page, you can click on Actions | Send an Email. Note that if the contact does not have an e-mail or their privacy options are indicating they should not be e-mailed, then the Send an Email action is not displayed as an option.
Finally, from any page in the system, you can click on the Create New button in the left sidebar (default block location) and select Email.
All four approaches will bring up the following form for e-mailing via CiviCRM:
While it seems like a fairly standard e-mail form, let's go through it field-by-field to learn about its special features:
- From: This defaults to the primary e-mail of the currently logged in user but also allows you to select from other e-mails set up in Administer | Configure | FROM Email Addresses. This is particularly useful for situations where there are departmental or functional e-mails (for example,
<[email protected], [email protected], [email protected])>or where one staff member sends e-mails on another's behalf (for example,[email protected]). The e-mail will be logged as an activity for all contacts specified in the From, To, CC, and BCC fields. - To: The primary e-mail address of the contact(s) to be e-mailed. If you arrived at this form through the contact record or search results, the field will be populated with the originating contact(s) e-mail address. If you arrived using the Create New button, you will need to search for the contact(s) you wish to send to. You can add additional e-mails using the standard auto-completion search functionality (name and e-mail).
- Add CC | Add BCC: These links provide auto-completion search fields and ensure that the e-mail activity is added to the record of the relevant contacts.
- Subject: In addition to providing text that will appear unchanged on the subject line in people's inboxes, you can use the Insert Token link to include information from a contact's record that should be looked up and inserted into the subject line. This can include either core fields such as a person's first name, or contact-type custom fields that are specific to your installation of CiviCRM. The latter are included in the alphabetized drop-down list of field names as Custom Field Name :: Custom Data Group Name.
- Use Template: E-mail templates are used in slightly different ways in different parts of CiviCRM:
- Unlike automated message templates generated from event signups, contribution pages, and other public facing forms, templates selected when manually sending an e-mail will pre-populate the content field and provide you an opportunity to manually edit the content before it is sent out. As a result, the process is more like making and editing a copy of a Word file than auto-generating a letter from a Word mail merge template.
- Since it populates the field and then provides access to further edit the content, you can take advantage of the tool by creating e-mail templates containing just your design/layout branding, and also use it to create standardized responses for common queries received by phone or mail. When creating your template, take the time to test it thoroughly and ensure cross-client compatibility, including reviewing how it will appear in web-based e-mail tools (Gmail, Hotmail, and so on). It can take significant fiddling to get HTML-formatted e-mails to look consistent in different e-mail clients, especially when you are trying to do sophisticated formatting. By investing the time to create a well-constructed template, you will save time for end users creating the e-mails and help ensure effective visual branding.
- HTML Format: CiviCRM ships with two popular WYSIWYG (what you see is what you get) editors which support standard formatting tools when constructing your e-mail. We find that Drupal users will typically use CKEditor, and Joomla! users will select TinyMCE, as they are more commonly used in those respective CMSs. Note that in CiviCRM v3.3, Joomla! users will be able to use the default or user-specified editor installed in Joomla! and selected in Global Configuration, which will significantly extend the options available. The following screenshot refers to CKEditor. Some standard caveats apply:
- While visually well-designed HTML e-mails tend to improve readability, click-through, and response rates, it is important to test and periodically retest how the e-mails are appearing in popular desktop and web-based e-mail clients. Invalid HTML markup, such as unclosed tags are red flags to spam checking software; so beware of inadvertently creating deliverability problems by having someone who is not familiar with HTML doing anything fancy in the HTML source view.
- CSS used in your e-mail should always be inserted directly in the HTML tags. Most e-mail clients don't support style declarations inserted in tags through class and ID values.
- Don't cut and paste directly from Microsoft Word because it uses non-standard markup code. Invisible to you when pasting, this markup code will often prevent your messages from appearing correctly in your recipients' inboxes because it references Microsoft-specific elements that are not widely supported. If you need to copy something from a Word document, the easiest way to remove the problematic markup code is to paste using the special Paste from Word or the Paste as Text icon. Paste as Word will attempt to retain structural elements, such as bullet lists, whereas Paste as Text more thoroughly strips all design and layout elements.
- For an image to appear in your constituents' browsers properly, it needs to be available on the Web somewhere. Generally, it is best to upload any image you need in your e-mail to a publicly accessible part of your website, making note of the URL that displays the image.
- When referencing pages on your website or inserting images, be sure to use the full URL (
http://), not a relative path. Remember that the e-mail received by your constituents will not be directly connected to your website, so relative path resources will be meaningless. - There are a number of good resources (many of them free) for obtaining e-mail templates that are compatible with most e-mail clients. Consider obtaining some as the basis for your template and then modify to suit your organizational branding.
- Plain-Text Format: Ensure that you fill this in if any of your recipients are marked as wanting plain text e-mails. The HTML version is not automatically converted to plain text.
- Attachments: When sending e-mails, you are given the option of attaching files. If the option to add attachments does not appear or you are not able to add as many attachments as you would like, check your configuration at Administer | Configure | Global Settings | Miscellaneous. Note that adding attachments could reduce the deliverability of messages, as it is one of the things many spam filters take into consideration. For small volume e-mails this should not be an issue, but it is generally not recommended when creating bulk e-mails.
- Send E-mail button: After you click on this button, the message will be sent and copies of the message with appropriate tokens replaced in the subject, and body of message will be attached to each recipient's and sender's record as an e-mail activity.