Want to hear something shocking?
According to ZoomInfo, at least one-third of CRM data is suspected to be inaccurate. Yikes!
But the data issues don’t end there—that’s just the beginning.
Research by ZoomInfo found that companies use an average of 75 technologies. And as orgs grow, technology expands, which can lead to a tech stack of more than 200 different tools.
A lot can go very, very wrong if these tools are brought on without the right policies and procedures in place. As tech stacks grow, there are more and more opportunities for data silos to build, impacting data cleanliness and organizational efficiency.
Is there a way to keep these data silos at bay? How can you ensure data integrity best practices are followed as your tech stack expands? The answer: create an acceptable usage policy.
What Is an Acceptable Usage Policy?
An acceptable usage policy is a document that outlines the most important information, guidance, and practices regarding the use of the internet, a network, or a specific piece of technology.
Each piece of technology your organization uses should have an acceptable usage policy. This ensures all parties understand how the tool should and should not be used. It also explains the who, what, why, and how of a tool. This helps all teams understand a tool’s functions and purpose, improving data transparency and reducing duplicate tools.
Oftentimes, an acceptable usage policy for a specific tool will replace the “acceptable” term with the tool’s name. For instance, if your organization is a Formstack user, you may find the acceptable usage policy named “Formstack Usage Policy” or simply “Formstack Policy.”
If your organization has multiple tools used for similar instances, you may also find the usage policy titled by the product type versus product name. For instance, it might be titled “Online Form, Document, and Workflow Software Usage Policy” if you use more than one workflow automation tool.
Related: Automation Can't Save You from Broken Processes
Why is an Acceptable Usage Policy Important?
“As long as data remains siloed, you will never reach that data-informed decision-making,” said Rose Anne Martinuzzi on a recent episode of Formstack’s Practically Genius podcast. She joined us to discuss the data best practices she’s gleaned from more than 15 years of experience in data governance, tech acquisitions, and business process improvement.
One thing she pointed out in her episode is the importance of data governance to an organization's overall success. Without strong data policies in place, there’s no single source of truth (or control) for your data. That’s why having an acceptable usage policy for the tools in your tech stack is crucial.
As she explains in the episode, strong data governance can help address data cleanliness, duplicate data issues, and disparate systems. Acceptable usage policies are a foundational piece of any data governance structure.
A tech governance committee plays a big role in the creation, management, and updating of an acceptable usage policy. They should be included in every tech acquisition to help departments better understand tech requirements and needs as well as how to build data policies and follow best practices.
Want to learn more about tech governance? Listen to Rose Anne’s full episode How to End Data Silos and Make Better Decisions to learn how to build out and maintain a tech governance committee.
.gif)
Key Pieces of an Acceptable Usage Policy
It’s clear that acceptable use policies are important for maintaining tech cleanliness, ensuring tools are used properly, and bringing transparency about an organization’s tech stack to all teams. But what actually goes into an acceptable usage policy?
These types of policies are flexible and will adapt and grow as your use of a tool changes. No two acceptable usage policies are alike, but here are a few key pieces to consider including in yours.
Pro Tip: Want to see an acceptable usage policy example? Rose Anne shared an example of an Online Form, Document, and Workflow Software Usage Policy, which includes a Formstack Usage Policy.
Product Definition and Description
This might be the easiest part of creating an acceptable usage policy. The very beginning of the document should provide a clear description of the tool, defining what it does and how it is used.
You don’t have to create this yourself. Simply go to the tool’s website and copy and paste information that describes the tool and its functionality. This product description does not need to be paragraphs long, but it should provide enough detail and information to make the tool’s use, purpose, and abilities clear.
Intended Use Cases
Using a single tool across an organization is a great way to ensure data cleanliness, eliminate duplicate data, and improve security. One way to increase the adoption of a new tool across different teams and departments is by adding an intended use case section to the product’s usage policy.
This provides potential and/or new users insight into how the tool can be used in their role or on their team. The more expansive this section, the more likely it is that others will see the value and uses of the tool, hence improving overall adoption.
Start this section by creating generalized guidelines based on overall data collection needs. If you’re planning to use the tool across departments, it may be best to outline use cases by department to make this section easily scannable. A great place to begin is outlining use cases aligned to any compliance guidelines your organization must adhere to.
Here’s a look at the intended use section from Rose Anne’s acceptable usage policy example:
- Forms needed for official processes of the university. (i.e., FERPA)
- Forms needed for collection of health information
- When workflows require multiple signatures or approvals
- When SSO authentication or ID verification is required to acknowledge documents or statements and/or make the signature legally binding for a court of law (i.e.: student financial responsibility agreement)
- When Personally Identifiable Information (PII) data is collected that requires secure encryption
- When documents need to be pushed into Onbase for retrieval via Colleague
Outlining intended use cases provides clarity on how a tool can be used. This section is likely to expand as your organization dives deeper into the functionality of the tool.
Special Circumstances
This section outlines any situations where the tool should not be used. For those working in highly regulated fields, this section is incredibly important. If there are any types of data that should not be collected with the tool, outline that here. This could include Personally Identifiable Information (PII), such as Social Security numbers, driver’s license numbers, and medical records.
If only specific departments are allowed to use the tool to collect certain information, such as credit card numbers, that should be noted here as well. For instance, your HR team may be the only department allowed to collect information about salary, or your finance department may be the only one able to access payment processors.
User Roles
Depending on the technology, there might be quite a few different user roles or levels of access. Outlining all of these within a single section brings clarity to what type of role or access a new user may need to request.
Here’s a look at some potential user roles to outline:
- Administrator
- Folder Administrator
- User
- Participant User
The role types will differ depending on the tool. Each user role should be followed by a detailed description of what is included in this level of access. Some items to consider in the description include:
- Ability to add, manage, and/or change account information
- Access to security features
- Ability to build, edit, approve, and/or view
- Access to various portions of the tool (i.e., specific folders)
- Number of licenses or seats available
It’s also smart to add information to this section about how to contact internal support or the help desk. This ensures users know who to contact if they are running into user permission issues or need assistance changing their user role.
Requesting Access or Expanding Usage
Controlling who has access to what tools is a crucial part of data management and tech governance. Having a clearly defined process for how to request or expand usage is an important part of any product usage policy.
This section should also outline how new users should go about onboarding, setting passwords, and getting started with the product. But don’t think you have to spin up your own assets—most products provide helpful customer webinars or events that can be highlighted in your product usage policy.
Break Down Data Silos with Documentation
When you have clarity on the tools used across your organization, you’re able to make better decisions overall. By focusing on data documentation and policies, you can help all employees get a grasp on the tools at their disposal, as well as understand where there may be gaps or potential tech overlaps. Start strengthening your data governance by drafting an acceptable usage policy today.
This is just one of many data governance strategies Rose Anne shares on her Practically Genius episode. Listen to How to End Data Silos and Make Better Decisions now to hear all of her excellent insights.
.png)
