Let’s scope an email signature project for a corporate entity!

Having been at this for some time, we have noted a number of pitfalls, and steps that can ensure a better experience. 

The projects can certainly vary from the extremely basic, right through the highly complex, but in either case, we can ensure your success. 

I will split the scope into Branding and Campaigning, as some of you may opt to do Branding first, and move to Campaigns at a later date.

Branding

You want to unify the look and feel of corporate emails. 

You may have recently rebranded, or you may be looking to solidify your Brand’s recognition, by eliminating the homespun versions of email signatures in your corporation. 

Email signatures are seen by every recipient. Why this element has evaded the Branding team, for so long, is a mystery, but can be easily resolved.

This next piece may sound daunting, but know if you have a defined look for your signatures, and can answer the questions posed below, this doesn’t need to be a long winded venture. Making assumptions, at this point, has pushed a number of deployments back at the actual roll out stage, so let’s get the answers up front, and signed off.

Gather the stakeholders for a meeting of the minds

Doing work in a vacuum, only to find it doesn’t gain the approval you need, is a quick way to an unsuccessful deployment. 

Take input, and gain signoff as you go. 

Hitting a moving target is much tougher.

While you have the decision makers in the room, ask how willing they are to allow users to modify the content and layouts they have access to. The more choices you supply, the more complex the roll out. Our tool can be used to enforce compliance by removing all signatures that exist prior to a refresh. Is this something management would like to see occur? Knowing certain groups will require flexibility is also best known early on.

Gather graphic content. Get feedback on desired layout, and request logos and graphics be sized appropriately. Many browsers fight % scaling. Providing the graphics correctly sized, and then defined, in Pixels, in the HTML code, will prevent a number of scaling issues later on. Corporate standards for FONT choices, (and replacement fonts for browser replacement, in the event you font of choice is not available) Font SIZE, and things like background color, table borders, and minimum content, need to be defined.

Where is your data held? We can connect to your Active Directory (IT) and if the content is sufficient, this is easy. Identify if AD holds accurate data, and if not, define a data source that does hold the field data we need to build dynamic signatures. (HR database, etc.)  We can push user data in via XLSX spreadsheet, if AD isn’t available, or complete. We can also define Fields in the Cloud version. These UDFs can be populated by mapping AD fields, by the Signature Admin, or via the end user Applet, if you choose.

Define a corporate wide standard for Email Signatures. What logo should be included? What field data do you want displayed? Layout? Do you want Social Media icons included?(should they be hardcoded to Company landing pages, or should we allow the content to be built dynamically, offering personal LinkedIn/Twitter/Facebook page links?)

Additionally, define a standard for Reply / Forward emails. Many clients opt for a stripped version of the signature for RE/FWD emails, to prevent a repetition of logos, in a longer thread. Field content can also be reduced, at your discretion. (IE: why reiterate your email address in an email signature…they are in correspondence with you at this point…Do you need all phone numbers, in a reply, or is direct contact detail in the original email enough? These answers will vary by client)
Do you have situations where additional versions will need to be defined?

If you have multiple locations, is the varying field content enough to satisfy the required result?
We can deploy different signature definitions via RULE to users in different locations, departments, or using any consistent piece of data, around which we can define a deployment rule.

Build out approved signature mockups for each unique deployment Rule. Include a matrix for field values we can build RULES to test for, for proper deployment. If the logos vary by Country/Market/job role, provide additional logos.
Dept. Signature
  • Marketing and Sales
  • Campaign Signature
  • HR
  • Corp Standard (no campaigns)
  • Support
  • Support signature
Additionally, we can provide Optional Signatures to users running local Outlook clients.
You could have signatures with alternate job titles, office contact details, and or Marketing content defined, and delivered as non-default signatures. These can be accessed by the end user, as they author the email, using the Microsoft Outlook Signature Picker. Build out mockups for each scenario required, and a Matrix describing which users should have which Optionals.
Another feature to consider, is providing content based on Logic within a single template. Our tool has the ability to hide empty content, and its associate label. (IE: Fax: disappears and the space is reclaimed, when the value for FAX is NULL in a user record.) This can be done for any field we store. There is also a CASE/WHEN/ELSE function that allows for content to be driven by the presence of known values in a field. (IE :Display a TAX Disclaimer if Dept = Tax, Else display a corporate disclaimer, or When State = MA then include Massachusetts Office details, When State = NY then include NY and CT office details, etc.) We can make it work, if we know the deciding factors. The Cloud Solution extends this option by allowing us to create Custom Fields for use in the decision logic.
Now we know what signatures you want defined, and to whom you would like them offered, which should be the defaults for each deployment group (department, country, state etc.) and the amount of flexibility you are willing to extend to an end user. We know where we are sourcing the data from, to build the dynamic content, and we have the graphics required to start work.

Building the first, corporate standard will be fairly easy with the mock up to compare to. Subsequent templates are easily created by copying the first one, and editing the copy. Even making changes to the original template can be made without fear of roll back problems, merely by copying the original, and making the changes in the copy. Once tested and approved, you can always go delete the original and rename the newly changed version to deploy.

Campaign

Now you have signatures defined, which signatures should receive Campaign banners? 

Campaigns is the label we use to define the content that can be optionally appended to any signature. If you want to include Marketing Banners, and a Corporate Disclaimer below that, it’s best to define the Disclaimer as a Campaign. Additionally, this allows you to define the content once, and assign it to as many signature definitions as required. Any edits occur in a single location, and will affect all templates to which the Disclaimer is assigned.

What content do you want to provide?

  • Disclaimers:
    Provide the content, and the signature definitions to which it needs to be applied to. Schedules on Disclaimers tend to be ALWAYS ENABLED, but the decision to apply the disclaimer to all emails, to all but RE/FWD emails, or anything in between, is up to you.
  • Marketing Campaigns:
    Like signature definitions, we need the graphics correctly sized and the text which you need included. If logos/text should link to URLs, we need those paths, as well.
  • As noted above, anything can be appended to the signatures.
    Event announcements with links to registrations, Legal content, or direct sales advertising. 

The links can be tracked for click through metrics, and geolocation, and we have articles noting how to tie it into Google Analytics.

How long should the campaign content be visible?

The tool allows us to define the date the content should appear, and subsequently be removed from the signatures, (recurring schedules can be defined if needed) and the signatures which should receive the content. 


Generally, Disclaimers run all the time, while true Campaign content is usually a shorter deployment with a defined start and end date.

Multiple campaigns can run concurrently on a single Signature. The order they will appear is dictated by the order the Campaigns are listed in the WYSIWYG. Click and drag the Campaign definitions to reorder.

What Signatures should receive content?

Simple deployments require only that the signature definition be checked off in the Campaign’s Signature Tab.

If you need to deploy a signature to a particular group of users, and not others, you can accomplish this by creating a copy of an approved Signature, authoring a rule to assign that signature to the group of users, and assign the Campaign to the same signature definition. Plans to expand Rules to affect Campaign assignment are on the Development plan, but it’s easily done now, by using the Copy Signature function.

Did you find it helpful? Yes No

Send feedback
Sorry we couldn't be helpful. Help us improve this article with your feedback.
Quick 1-on-1 Demo | Ⓒ 2024 Xink