Menu Close

Guide to Governance for Digital Communications

Starting at the 10,000ft View

To get started, I like to back up as far as I can to see everything I should include in my planning, or what people sometimes call the 10,000ft view. Digital communications can encompass many different things, from Websites to social networks to broadcast email, so I suggest backing up to the point where you are looking at the various platforms that will be part of your planning. Here is a list of some common platforms encompassed in a digital communications strategy:

  • Public Websites
  • Private Websites
  • Intranets & Portals
  • Web-Based Applications
  • E-Commerce
  • Social Networks
  • Digital Media
  • Broadcast Email
  • Digital Communications Governance *

This list contains the common “properties” or platforms on which a digital communications strategy is built, or at the very least they are some basic categories for the grouping of such properties. For instance, your organization may have a main Website with many sub-sites or microsites. Others may be combined in your institution; for example, all of your web-based applications may be built within your Intranet site. Make your own list align with the properties you need to include in your governance plan. These will be your top level categories.

* Few among us would likely think to include “Digital Communications Governance” on this list, but I do so precisely for that reason, and because I want to reinforce that Governance (its documents, people, and processes) is a living thing that needs to be maintained over time, just like the rest of the list. It’s oddly self-referential to think about governance for Governance, but think of it like the part of the Constitution that describes how to amend the Constitution.

Properties and Platforms

Taking the top level categories you have listed for your governance plan, you will want to think of the properties and platforms within each of them. The following questions are intended to help you think through each piece carefully.

Public Websites

  • What are the Websites we own that are visible to anyone on the Web?
  • Do we have any public subdomain Websites, such as subdomain.mywebsite.com?
  • Do we have any micro-sites, or Websites with a URL that is different from our main site?
  • Do we have any blogs that may be hosted elsewhere, but would be considered part of our public Web presence?

Private Websites

  • What are the Websites we own that are visible to only those with access we control?
  • What are the Websites we own that are visible to only those who have access through machines running on our organization’s network?
  • Do we have any subdomain Websites, such as subdomain.mywebsite.com that require logging in?
  • Do we have any Websites for only a specific set of constituents?

Intranets & Portals

  • Do we have a network of internal-use Websites (a.k.a an Intranet), accessible only by password or by logging on to the organization’s network, or otherwise hidden (even by obscurity)?
  • Do we use any portal sites or pages as a means of aggregating links of importance for specific groups of users?

Web-Based Applications

  • Are there any web-based applications we use to perform specialized tasks, such as generating reports from data in a database or retrieving digital assets from a database?

E-Commerce

  • What platforms, systems, and/or services do we use for collecting payments online?
  • What platforms, systems, and/or services do we use for selling products online?
  • Where are these located relative to our other Websites?

Social Networks

  • What are the social media networks we use to communicate to the outside world?

Digital Media

  • What are the platforms we use to create digital media, such as video, audio, and photography?
  • What are the platforms we use to distribute digital media, such as video, audio, and photography?

Broadcast Email

  • What are the systems we use to send broadcast email to all or large segments of our internal group, members, staff, community, etc.?
  • What are the systems we use to send broadcast email to all or large segments of our external community, clients, constituents, etc. for the purposed of marketing and promotion?

Digital Communications Governance

  • What are the pieces that will constitute our official governance system?
    NOTE: You may not know the answer to this one yet, so leave it empty for now.

Ownership

Now that we have defined all of the digital properties and platforms that we will consider for our Governance Plan, we next need to establish who “owns,” or who will ultimately be responsible for the care, maintenance, and accuracy, of these properties.

Ownership is the cornerstone of governance. In fact, some may think of ownership as being synonymous with governance. From my experience, I believe that good governance of any digital communications platform involves more than simply defining who is responsible for each piece.

In most organizations, many people are using, sharing, and collaborating on the same systems together, and the processes and interactions between those users needs to be defined as well. But defining ownership first is the foundation on which we can begin to define the more complex relationships that exist in a shared system.

I should make one other important distinction, as well, between maintenance of the system and the maintenance of the presentation of content, as it relates to ownership. Since this Governance Plan is considering the guidelines for digital communications, it is explicitly NOT considering the roles, policies, and procedures for the maintenance of the infrastructure that supports the properties and platforms we are considering for the plan.

In other words, when we define who has ownership of the public Website or the Intranet, we are considering only the content and its presentation – not the underlying software and hardware that makes the Website or Intranet functional. Perhaps this is obvious, but it is an important distinction to make for those who are less familiar with modern Web technology, who may not fully understand where the functions of an IT department end and an Online Marketing or Communications department begin.

With those caveats out of the way, we can now begin to define who is responsible for each of the properties and platforms we listed earlier.

Obviously, I can’t tell you who is or who should be responsible for each piece within your organization – that must be defined by how your work responsibilities are distributed across the institution – but I can describe some general principles for defining ownership that should help.

  • Ownership of your organization’s Web presences ultimately should reside at the very top, with greater and greater detail of responsibility being delegated down the hierarchy of the institution.
  • The top leadership of an organization should be responsible ultimately for the accuracy and maintenance of the content contained within the parts of the properties they own.
  • Every Website, subsite, microsite, department site; every section and sub-section; every page, aggregated listing, and piece of content all the way down to each video, photo, paragraph, headline, and caption should fall within the ownership of someone at the top.
  • Responsibility for daily oversight and hands-on maintenance of those properties then may be delegated to staff within the owner’s groups, offices, or areas of responsibility.
  • Owners should have sufficiently trained staff who have the authority and capacity to make changes, corrections, and updates to the content as needed in a timely manner, such that inaccurate and/or out-dated content does not remain on the property for an unreasonable period of time.

In short, ownership has two essential aspects:

  1. top-level responsibility for the accuracy and efficacy of the content, and
  2. hands-on responsibility for the creation and maintenance of the content.

Both are essential and required for good governance, and very likely may be responsibilities held by one person, split between two, or shared among a group.

Intended Use

This may seem obvious and unnecessary to state, but in my experience it has been important to define the intended use of the Web property that is currently being described. This ensures that everyone is on the same page and understands a common set of goals for the property.

Public-facing Websites are commonly intended for the use of communicating information to audiences outside of an organization, which is why they are public and usually distinguished from private, inward-facing sites, such as an Intranet, which is intended for the purpose of communicating information to internal audiences within an organization. Not everyone understands this, so it is important to establish the reasoning behind the existence of the property so as not to confuse it with the purpose of another property.

Occasionally, the intended use of a property will be defined in part by the negative, or by that which it is NOT intended to be used. For example, it may be useful to state that no part of a public site should be used for personal content, especially if alternative resources exist explicitly for that purpose.

Here is an example of how intended use is sometimes defined by the negative:

  • Academic Department Websites are intended for the use of communicating information about the department, its faculty, degree requirements, course offerings, policies, etc.
  • Academic Department Websites are not intended for hosting websites of individual faculty, websites based on grant funding, research projects, or specific course-related materials, or for private (i.e. password-protected) websites or applications.

The negative in this example addresses some misperceptions about the intended use of a site about a department by listing some common misuses of the site previously.

Here are some questions to consider for explaining your own intended use policy:

  • What is the primary purpose of the property or Website?
  • What are the secondary and tertiary purposes, if they exist? Etc.
  • Are there any activities or content which occasionally find their way onto this property which should live elsewhere, and thus explicitly be listed as not intended for this property?
  • What are the “grey areas” or things which are unclear where they belong?
  • Is there a process for dealing with them?
  • Who would help determine that process if it doesn’t exist?

Intended use can be a controversial subject for many organizations, so think carefully and cautiously throughout this exercise.

Roles and Permissions

We live in an era where few institutions have Websites and other Internet-based properties that are managed and maintained by one or only a few people. Where these spaces were once controlled by the few who knew how to code in HTML, content management systems have now dramatically lowered (and arguably eliminated) the need to possess extensive HTML knowledge. This means that most organizations have lots of people editing their Web properties, and without some well-defined rules for all those cooks in the kitchen, things get messy quickly.

Whether or not the platform you are using has roles and permissions built into it, a good governance plan will define roles for users and then apply specific permissions to those roles. Based on my experience, here are some common, fairly generic, roles and permissions that many Websites have (or have variations):

  • ROLE: Authenticated User
    PERMISSIONS: Anyone who has activated an account on the Website, but has no editing or publishing permissions; authenticated users may be able to see content an un-authenticated user may not see.
  • ROLE: Contributor
    PERMISSIONS: A user with an account who can create new and edit their existing content on the Website, but may not publish or delete any content, including their own, or edit content they have not created.
  • ROLE: Editor
    PERMISSIONS: A user with an account who can create new and edit existing content on the Website, including content that is not their own; they may or may not publish or delete content.
  • ROLE: Publisher
    PERMISSIONS: A user with an account who can create new, edit existing, publish, and delete any content on the Website; typically a person who approves and publishes the work of Contributors and Editors.
  • ROLE: Administrator
    PERMISSIONS: A user with the same permissions as a Publisher, however they may administer accounts, roles, and permissions of other users on the Website, along with managing certain site-wide settings.
  • ROLE: Webmaster
    PERMISSIONS: A user with full permissions to all aspects of managing and administering the Website, a role typically reserved to the few, most highly trained and experienced users.

These common roles can be modified easily to address the specific needs of your organization.

You may also find that they are lacking certain roles your need, in which case I recommend using one of these for the basis of a new role you create to meet your specific need. For example, let’s say you have a microsite that is a subset of your main site, and you need to assign a user the role of Administrator ONLY for that micro-site and not the entire main site. Simply take the permissions assigned to Administrators and create a new role call Micro-Site Admin whose permissions as “Administrator” are limited to only the micro-site that role manages.

Here are some questions to consider to help you begin defining the roles your organization will need, along with the permissions each role should have.

Accounts

  • Who should have an account for accessing your Website?
  • How do users acquire or activate accounts?
  • What are the policies for using accounts?
  • Is sharing an account permissible?
  • What are the conditions under which users may lose their access privileges?

Roles & Permissions

  • Who is permitted to edit content on the Website?
  • Who is permitted to create new content on the Website?
  • Who is permitted to publish content on the Website?
  • Who is permitted to delete content on the Website?
  • Who is permitted to see unpublished content on the Website?
  • Are there users who should have higher levels of administrative access to perform site-wide changes or to administer user accounts?
  • Are there sets of users who need special access to only limited parts or functions within the Website?
    Are there limitations to the level of access different users should have?
  • Do all users have access to all content?
  • Do some users have access to only the content they create?
  • Do certain users need to approve content before it is published?
  • Does a workflow need to be established for defining how content is produced and published?

Content

In addition to defining ownership for every piece of content on the Website, it may also be beneficial to consider and provide guidelines for the many types of content which will appear on the site. Here are some common content types along with some of the questions to consider in defining appropriate usage for your organization.

News and News Listings

  • Who is permitted to publish news on the Website?
  • Which kind of news items are permissible for publishing on the site? Which are not?
  • Is there a set of required information that must appear in all news items, such as headline, sub-head, preview text, author name, thumbnail image, etc.?
  • How many sources of news or news listings are presented on the site, and what are they?
  • Who may publish news to or from these sources?
  • Are there editors or gatekeepers who monitor the news that is published or submitted?
  • If so, what are the criteria they use for determining which news items are permitted or not permitted?
  • What happens to those that are permitted? And to those that aren’t?
  • May users or groups of user request their own news listing?
  • What is the process for acquiring a news listing?
  • May the creator of a news item have his or her item appear in the news listings of others?
  • What is the process for sharing news?

Events, Event Listings and Calendars, Event Registration

  • Who is permitted to publish an event on the Website?
  • Which kind of events are permissible for publishing on the site? Which are not?
  • Is there a set of required information that must appear in all events, such as title, date, time, location, contact info, thumbnail image, etc.?
  • How many sources of events, event listings, or calendars are presented on the site, and what are they?
  • Who may publish events to or from these sources?
  • Are there editors or gatekeepers who monitor the events that are published or submitted?
  • If so, what are the criteria they use for determining which events are permitted or not permitted?
  • What happens to those that are permitted? And to those that aren’t?
  • May users or groups of user request their own events listing or calendar?
  • What is the process for acquiring a events listing or calendar?
  • May the creator of an event have his or her event appear in the listings or calendars of others?
  • What is the process for sharing events?
  • Are events, listings, and calendars hosted by third-party services (such as Google Calendar) permitted?
  • May third-party event and calendar content be imported into pages of your Website?
  • May events have a registration form?
  • How is the registration form developed and published?
  • Who collects the form submissions, and how is the data collected?
  • May payments be collected through the registration form?
  • How is the payment collection process managed?

Blogs

  • Who is permitted to publish a blog on the Website?
  • What kinds of blogs are permissible for publishing on the site? Which are not?
  • Are group blogs allowed, or are they all individual person blogs?
  • Who may publish to or from group blogs? How are bloggers added and removed?
  • Are there any rules about the authorship of blogs on the site, such as they must be publicly attributable to the person or group writing them?
  • Are there any legal qualifications that need to be addressed for blog content, such as blog content does not reflect the official opinions, policies, or beliefs of the organization as a whole?
  • Are there editors or gatekeepers who monitor the blog posts that are published or submitted?
  • If so, what are the criteria they use for determining which blog posts are permitted or not permitted?
  • What happens to those that are permitted? And to those that aren’t?
  • May users or groups of user request their own blogs?
  • What is the process for acquiring a blog?
  • May a blogger have his or her post appear in the blogs of others? What is the process for sharing posts?
  • Are blogs hosted by third-party services (such as WordPress or Blogger) permitted?
  • May third-party blog content be imported into pages of your Website?

Images, Audio and Video

  • Are images, audio files, and/or videos allowed to be published to the site?
  • What file types and sizes are permitted?
  • Are there any rules regarding where and how those assets are stored on the site or server?
  • Are there any guidelines for how images, audio, and video owned by your organization are to be used on the Website?
  • May they be edited or altered?
  • What types of attributions are required for acknowledging the creator(s) of those assets?
  • Do you require release forms from any individuals who may be captured in those assets?
  • Do you hire contractors to produce images, audio, or video assets? If so, who owns that material?
  • Are images, audio files, and videos hosted on other Websites permitted to be displayed on your site?
  • Are there any restrictions or limitations to the type, quality, content, authorship, or source of the images, audio files, or videos hosted elsewhere and displayed on your site?
  • Are there any guidelines for the use of these types of assets from outside sources?
  • What is your policy for using copyrighted material (images, audio, video, as well as textual copy, excerpts, etc.) from outside sources on your Website?
  • Who is permitted to publish images, audio, and/or video to the Website?
  • Are there editors or gatekeepers who monitor the images, audio files, and videos that are published or submitted?
  • If so, what are the criteria they use for determining which are permitted or not permitted?
  • Is there a workflow for the materials that are permitted? And to those that aren’t?
  • Should users of the site be permitted to download or reuse your copyrighted materials?
  • Do you clearly display permission rights on the website?

Embedded Objects and Scripts

  • Are embedded objects and scripts permitted to be used on your Website, using HTML elements such as embed, script, or iframe?
  • Are there limitations to how, when, and where these elements can be used?
  • Who is permitted to publish these types of code to the Website?
  • Are there editors or gatekeepers who monitor the publishing of embedded objects and scripts?
  • If so, what are the criteria they use for determining what code is permitted or not permitted?
  • What happens to those that are permitted? And to those that aren’t?
  • These are some common types of content and the issues that surround them, but you may have your own set of issues that need to be addressed specifically in your governance plan, so add those wherever it seems appropriate.

Organization

A Website’s organization is one of the most important factors in determining how effective and useful the site is for its visitors. Sites that are well-organized in a manner that visitors intuitively understand will be more effective and useful than those which aren’t. Therefore, it is important to define for your institution who will have the authority and responsibility to determine Website organizations and how they will make those decisions.

Here are some questions to consider with regard to main Websites and subsites within the main site.

Main Website

  • Who determines the overall, top-level organization of the main Website? How is it established?
  • Who determines the subsequent levels of navigation, order, labeling, etc.? How are those established?
  • Is there a process for addressing concerns or proposed changes to the site’s organization?
  • Who has the ability to make changes to the Website’s overall structure?
  • Are there site-wide taxonomies to be maintained? Who determines and edits those?

Subsites

  • Who determines the organizations of sub-sites within the larger Website?
  • Are there any guidelines or services for Website owners who must create their own site organization?
  • Are there limits to the size, quantity, or depth of navigation?
  • Are there any site-wide standards for how navigation and sub-navigation are displayed?
  • Are there any site-wide standards for where navigation and sub-navigation are displayed on sub-site pages?
  • Are there rules for the labeling of navigation?
  • Are there sub-site specific taxonomies? How are those determined and edited? Must they conform to any site-wide standards or rules?

These questions cover only the definition of responsibility surrounding Website organization. For more information on how to create a site organization, see my guide to re-organizing a Website.

URLs

A logical progression from Website organization is defining a naming convention for URL paths. URL paths should follow a consistent naming convention throughout all of your websites as much as possible. Only under exceptional circumstances should a URL path name deviate from an established naming convention for a Website. Best practices for URL path naming conventions recommend consistency in how sections, sub-sections, pages, and sub-pages are written. For most websites, I recommend URL paths follow the general naming convention below.

http://domain.com/SECTION/SUB-SECTION/PAGE/SUB-PAGE

This basic structure gives users an idea of where they are in the site’s hierarchy of pages. This can be especially important considering the volume of traffic that enters the site from web searches that will bypass the homepage and take visitors directly into deeper pages in the site.

Section

Under this convention, SECTION is the top-level directory, and generally refers to the category under which subsequent content resides. For example, in the URL path http://domain.com/about, “About” is a primary category that often appears in a main menu, and thus receives a top-level URL path.

I generally like SECTION names to be one continuous string of letters without hyphens or underscores (e.g. about, services, people, etc.) because that makes for shorter top-level URL paths, however two word hyphens may also be acceptable if they aren’t too long. Acronyms and abbreviations should be avoided because they often don’t make sense to outsiders, however some, such as http://domain.com/faq, may work so long as they make logical sense to most users.

If your Website has multiple users who are able to write URL path names, I recommended defining in the governance plan some limitation for who may write top-level directory names. These are typically the most highly sought-after URLs in a Website, and you will want to have a well-defined process for how those are distributed and assigned. A free-for-all is probably not a good process.

Sub-Section

SUB-SECTION is the second-level directory, if one exists. Using About as an example, “Meet Our Team” is the second-level directory in the URL path:

http://domain.com/about/team

since “Meet Our Team” is just one of the sub-sections under “About” in this example.

SUB-SECTION names also may be one continuous string of letters without hyphens or underscores, such as:

http://domain.com/about/team

or a string of words separated by hyphens:

http://domain.com/about/meet-our-team

The choice between the two really depends on whether the additional words add value to the user’s understanding of location, and/or if the string of words adds SEO value because it captures important descriptive words for the content of the page. In the example above, the words “meet our” really don’t add much information, and the shorter URL path name is simpler. Simplicity may become more important as you add pages to sub-sections and the URL path names become very long.

Some URL path names may appear to deviate from this rule if a sub-section does not actually exist, in which case the sub-section location would be occupied by the page name.

Page

Pages on the “Meet Our Team” site would then have a URL path structure of:

http://domain.com/about/team/PAGE-NAME

where PAGE-NAME could be any number of different page names. PAGE-NAMEs should generally describe the content of the page based on the page’s title. This can be expressed either as a single word (if a single word sufficiently describes the page), such as:

http://domain.com/about/team/consultants

where “consultants” is a page for information about consultants on the team titled “Consultants”; or by a string of hyphenated words, such as:

http://domain.com/about/team/website-consultants

where “website-consultants” is a page about Website consultants on the team titled “Web Consultants.” For the purposes of SEO, at the page level, I generally prefer to include all of the keywords in a page’s title (separated by hyphens) in the URL path, especially when it adds descriptive value.

Sub-Page

As follows, sub-pages for any of the pages in the “Meet Our Team” site would have a URL path structure:

http://domain.com/about/team/PAGE-NAME/SUB-PAGE-NAME

SUB-PAGE-NAMEs should follow the same rules as PAGE-NAMEs, however sub-page names may require longer strings of hyphenated names as pages become more detailed and specific:

http://domain.com/about/team/consultants/drupal-content-management-system

Conversely, if sub-pages are breaking out content into simpler categories, they may benefit from shorter names:

http://domain.com/about/services/web-platforms/drupal

rather than:

http://domain.com/about/services/web-platforms/drupal-content-management-system

All of that being said, you should determine the system that works best for your needs and stick to it. Just keep it simple, logical, and as memorable as possible so that it is easy for all users to implement.

Multiple-Word Names

When writing URL paths with multiple-word names, I generally recommend using hyphens, such as:

http://domain.com/about/services/web-platforms/drupal-content-management-system

rather than underscores:

http://domain.com/about/services/web_platforms/drupal_content_management_system

or concatenation:

http://domain.com/about/services/webplatforms/drupalcontentmanagementsystem

Use of underscores makes it far too easy for a user to misread an underscore as a space, especially when the URL path is hyperlinked:

http://domain.com/about/services/web_platforms/drupal_content_management_system

Most hyperlinks are underlined to indicate to users that a section of text is a hyperlink.

Concatenation is more obviously problematic because it simply creates confusing URL paths.

Aliases & Redirects

How URL path aliases and redirected URL paths are handled will depend on the policies of your organization and the platform you use for your Website. I highly recommend you define the rules and processes surrounding URL aliases and redirects in your governance plan, and here are some questions to consider along those lines.

  • How are URL aliases and redirects managed in your Web environment?
  • Who manages URL aliases and redirects?
  • Is there a process or procedure for requesting an alias or a redirect?
  • May anyone request a URL alias or redirect?
  • Are redirects to Websites outside of your domain or server environment permitted?
  • Who determines whether a URL alias or redirected URL path is appropriate or not?
  • Are there any special rules for using top-level directories as URL path aliases or redirected URL paths?

Design

Website design is handled differently by just about every organization I have encountered, but whether you are writing governance for one site with one design or several sites with varying designs and various owners, you will want to document policies and procedures for how sites are designed and redesigned. For the purposes of this article, I am going to assume we are writing guidelines for a governance plan that must consider multiple sites and site owners. Here follow some questions to consider for writing your guidelines.

General Guidelines for All Websites

  • Does your organization have an established visual identity or branding guidelines that will dictate the design of a Website?
  • Who oversees the adherence to visual guidelines?
  • What is the process for having a Website design evaluated for adherence to the visual identity or branding? Is there an approval process?
  • Are sub-sites within your main Website permitted to have their own design, or must they use the same templates designed for the main site?

Designing New Websites

  • Who is responsible for designing new Websites?
  • What is the process for requesting a design for a new site?
  • Are there limited design options?
  • Are external freelance designers, consultants, and/or design firms permitted to be hired to create a new graphic design for a Website?
  • Are external freelance designers, consultants, and/or design firms also permitted to produce the templates, themes, or HTML files which constitute the actual execution of the graphic design for the Web?
  • If external freelance designers, consultants, and/or design firms are permitted to translate the graphic design into files for the Web, what formats, languages, protocols, frameworks, and content management applications are permitted in your Web environment?
  • Are there specific guidelines that external freelance designers, consultants, and/or design firms must be given before starting work?
  • Are there dimensional guidelines for the size of the site, such as a maximum or minimum width (or height), or guidelines for breakpoints in responsive designs?
  • Are there image-size limits for the purposes of fast page-loading?
  • Are there rules about the use of images as text for the purposes of usability?
  • Are there existing style sheets (CSS) that should be used or incorporated?
  • Are there specific colors or color palettes that must be used? Or not used?
  • Are there specific fonts or font families that must be used? Or not used?

Redesigning Existing Websites

In addition to the questions for new Websites, you should also consider the following for redesigning sites.

  • When may a Website owner request a redesign of their site?
  • Is there a special process for redesigning a site?
  • Are there any costs associated with a site redesign?
  • May a Website owner, or their assignees, make design adjustments to their Website between official redesigns, if they have the ability and access to do so?

Personal Websites

Depending on the type of organization for which you are writing a governance plan, you may need to address the issue of personal Websites within the context of your institution’s Web properties and server environment. For colleges and universities, the questions you need to answer will likely be in relation to faculty, students, and alumni. For businesses, the questions will relate to employees. For non-profits, it may be employees, trustees, and/or volunteers. Regardless of who the people are, or what function they serve in the organization, if they have a website affiliated with your organization that they control, you probably want to have some guidance for how those properties relate to your organization. Here are some questions to consider for all types of institutions.

  • Are there services available for individuals in your organization to have a personal or independent Web property (i.e. Website, blog, social networking account, etc.)?
  • Who provides the service(s)?
  • How does an individual acquire the Web property?
  • Who owns and maintains the Web property?
  • Where is the Web property located (i.e. whose servers)?
  • Who designs and produces the property?
  • Are there guidelines related to visual appearance?
  • What happens to the Web property if the owner leaves the organization?
  • Are there subject matter limitations or guidelines for personal sites?
  • What happens if a personal Website owner violates subject matter guidelines?

Private Websites, Intranets & Portals

Most organizations these days have some form of private area for only staff, team members, approved contractors/partners, etc. These sites are sometimes guarded behind a firewall and a user authentication system, sometimes just user authentication, and sometimes simply hidden by obscurity! Most often, though, you can identify one of these types of sites because it requires a login and password and is not generally accessible by the public.

Most of the previous questions, regarding content, organization and design are relevant to internal Web properties as well, but here are a few questions you may want to ask yourself specifically with regard to private websites, intranets, and internal-facing portals:

  • Who owns each one? If they are shared responsibilities, who owns each part?
  • How are accounts distributed and access granted?
  • Who determines access and account creation?
  • What is the process for account creation?
  • What is the criteria for gaining access via an account?
  • Do user accounts have different roles with different permissions?
  • Who are the content editors and creators within the site?
  • How is the site edited and maintained?
  • Are there any workflows or approval processes for content?
  • What distinguishes content that is appropriate for external channels from content that is only appropriate for internal channels?
  • Who will be responsible for determining what is appropriate? And how will they enforce those rules?

Web-Based Applications

Your organization may have web-based applications – whether those are custom-built applications or 3rd-party solutions – which are used to perform specific functions and tasks.

  • Who owns them?
  • How are they edited or changed?
  • How are new custom applications developed?
  • How are new 3rd-party applications, solutions, or services acquired?

E-Commerce

Strict federal laws govern the transmission, collection, and retention of credit and debit card data, whether those interactions occur through the Web, by phone, or in person. Any organization involved in collecting payments via credit or debit cards should ensure that all staff involved in a payment collection process are appropriately trained and fluent in the organization’s policies regarding the collection and retention of credit and debit card data. And obviously, those policies should adhere to federal and state laws.

Minimum Requirements for Collecting Online Payments

Bank Account

Any organization intending to collect credit or debit card payments first needs a bank account in order to receive those payments. The bank account is where the money “goes” once a payment  transaction is completed.

eMerchant & Payment Gateway

Once you have a bank account where money can be deposited, you will then need to establish accounts with an eMerchant and Payment Gateway provider. Some eMerchant and Payment Gateway services are provided by the same institution. For example, PayPal will handle both the eMerchant and Payment Gateway functions of eCommerce, so all you need to use a service like PayPal is a bank account.

Some organizations have existing payment relationships with companies that serve as eMerchants. It may be more cost-effective to use a company with whom you already have a relationship, in which case there are various Payment Gateway providers that could be used to facilitate the transaction between purchaser and the banks involved in the payment process.

Secure (Encrypted) Online Form

The final piece required for collecting online payments is a secure (meaning encrypted) online form. This is the registration form users will complete with their credit or debit card information to make a payment. The form must be served over a secure and encrypted protocol (https).

Creating a Policy

The minimum requirements for collecting payments online only scratches at the surface of the issues you may need to consider in terms of governing the use of online payment collection for your organization. Here are some additional things to consider:

  • Who may have eCommerce capabilities?
  • What is the process for initiating eCommerce on the site?
  • What is the process for being added to the existing eCommerce solution?
  • How many parts of your organization need to collect payments online?
  • Do they each need their own implementation of an eCommerce solution? Or can they share?
  • Do they each need their own bank account? (This is often the case when reporting of online payments, especially charitable contributions, requires separation between departments or budget lines for accounting purposes.)
  • Who is responsible for ensuring that federal and organizational guidelines are followed?

Decisions surrounding eCommerce will invariably involve key decision-makers, stakeholders, and gatekeepers within the Finance department (or correlated function) within your organization. You are likely to need their cooperation in determining a governance plan for eCommerce.

Broadcast Email

A broadcast email (a.k.a. email marketing) is loosely defined as an email sent and addressed to a group of people rather than a specific person or persons, typically using an email list, contact list, or database of email addresses. It is frequently used for the purposes of email marketing, though it essentially refers to broadcasting a communication to a group of recipients via email to convey information.

When communicating with an external audience, broadcast email typically is sent through an email marketing service (such as MailChimp, Constant Contact, Campaign Monitor, etc.) or through the email platform of a larger enterprise system that may include a CRM and other marketing functions (such as Blackbaud or Salsa). Your organization may also have internal mass-email distribution systems in place for broadcast email to internal audiences. For the purposes of this article, we will be speaking mostly about email to external audiences.

Spam

An important issue to address in any broadcast email guidelines is the sending of spam email. Spam email is generally understood to be any email message that is unsolicited and sent in bulk. This applies to email sent to an address that was not given to the sender explicitly for the purpose of receiving mass email messages from the sender.

Common activities which may qualify as spam:

  • sending a mass email to a list purchased from a company
  • sending a mass email to a list borrowed from another organization
  • sending a mass email to a list compiled by scouring Websites for email addresses
  • sending a mass email to a list of recipients to which you have not been given permission to email
  • sending a mass email to a list compiled from a database without permission from the database administrator(s)

It is critically important to have policies governing broadcast email communication, as it will certainly impact your efficacy in communicating with many of your most important constituencies. Here are many other questions and issues to consider while crafting your governance plan:

  • What broadcast email platforms are available?
  • Who has access?
  • May individuals use their own email accounts for broadcast email?
  • Are there multiple lists of broadcast email recipients such as various subscriber lists, audiences, or groups?
  • Who is responsible for maintaining each of these lists?
  • Are permissions and approvals required for sending email to broadcast email lists?
  • Are there any regularly scheduled broadcast emails (such as newsletters)?
  • May an individual add information to regularly scheduled broadcast emails?
  • May broadcast email recipients unsubscribe from the list(s)?
  • Do you have an official unsubscribe policy?
  • May members of your organization create and maintain their own custom broadcast email lists?
  • What are the guidelines for custom lists?
  • Do you have a policy regarding the sending of spam email?
  • How does your organization define spam email?

Digital Communications Governance

Digital Communications Governance Document

This document describes the policies, practices, and procedures that should guide your organization’s decisions with regard to governing public digital communications. Given that circumstances and technologies change rapidly, this should be viewed as a living document in need of regular maintenance and updating to best reflect and address the needs of the organization moving forward. Therefore, this document should be approved and maintained by a Digital Communications Governance Committee.

Digital Communications Governance Review Board, Committee, or Group

The Digital Communications Governance Committee should be an advisory group to help inform policy and governance of the organization’s web and digital media. Led by a Chair who is well-informed about digital governance issues at your organization, this group should meet once or twice a quarter to give input on new issues and policies, as well as maintenance of existing policies. The Committee should have representation from the main administrative areas of the organization, preferably those with knowledge of the modern web and current technologies.

Digital Communications Governance Amendments

Any issues regarding the policies, practices, or procedures in your Digital Communications Governance Document – or those not considered under your document – should be settled by the Digital Communications Governance Committee, the results of which should be amended within or added to the document.

Guide Sections


View my on-demand webinar “Preparing for a Higher Ed Website Redesign” hosted by SiteImprove.

Download my guide to “Preparing for a Higher Ed Website Redesign” from SiteImprove.

Preparing for a Higher Ed Website Redesign graphic from SiteImprove