How to Choose Workplace Survey Tools That Document Evidence

Amy C. Edmondson's The Fearless Organization nicely sums up why people need to feel safe before they'll speak up about problems.

But what about the other 50% of the equation: creating a safe environment for people to actually take action based on what they hear?

Imagine you have an inspector, works council, or plaintiff's attorney asking for documentation related to your most recent psychosocial risk survey.

Do you have the exact question wording presented to employees in each language? Do you have a system in place to show when specific documents were sent to each entity, including reminders? Can you present the inclusion/exclusion criteria and scoring rules that were applied to that specific survey?

How can you show what specific risk assessment decisions were made, and completed?

If you only have a presentation to a steering committee with a few charts and a green light up arrow or a vendor comparison, you're not in great shape.

While a dashboard may help you quickly understand whether your overall score has improved, it's not great for helping you recall which version of a survey was used. It also can't show whether someone re-aggregated the data by applying different inclusion/exclusion criteria after the fact.

Nor can it show whether the insights were ever presented to anyone with the budgetary power to implement change.

This is important, because survey results are increasingly being used in psychosocial risk inspections, harassment investigations, pay equity exercises, constructive dismissal claims, and human capital disclosures.

In other words, your organization's employee engagement survey data could be subject to disclosure and other parties will carefully scrutinize your original survey questions.

How do you design a survey experience that captures all the necessary steps without ever compromising personal identification?

The survey tool you choose directly impacts whether you can create a defensible audit trail or if you'll be forced to scramble to put one together later.

When a dashboard stops being enough

We know this has been a long feature checklist, but it's not wrong to have these in your buyer's guide.

You need a validated question library, multi-channel distribution including non-desk workers, multilingual distribution, real-time reporting, heatmaps by business unit, HRIS integration, role-based user access, and all within a cost-effective budget.

The only advice we have is to stop using these to score your vendors.

Historically, employee engagement platforms were designed to generate a story for managers. Today, there are very different needs: producing an interactive platform for management illustrations and also giving customers different products and services.

These are very useful resources to help companies derive insight, but we know that when it comes to audits and compliance needs, we're going to need specific information to answer legal and regulatory questions.

We're going to need detailed information for psychosocial hazards, harassment, pay equity, and employee rights.

Not all of your employee surveys will need to generate the same level of information. So it's often impractical to have one overarching corporate policy for employee surveys.

To make compliance easier, you can create a system that divides your survey tools into three categories:

• Tier 1 - internal management signal: For something like a quarterly employee pulse engagement survey, which is not meant to serve as a compliance tool. For this kind of survey, it's enough to keep a record of which version of the survey was used, the population it was distributed to, and how it was scored.
• Tier 2 - survey cited as a control: For surveys you would cite as evidence for assessing psychosocial risks, monitoring inclusion, or assessing employee climate after an incident. For these kinds of surveys, you would need a full evidence package including your actions in response and acknowledgement of realistic risks.
• Tier 3 - negotiated or contested instrument: For surveys where the language has been agreed upon with employee representatives or when you're conducting a survey in the middle of a labor grievance, workplace inspection, or other claim. These surveys would need to include formal document control and a legal review of the language before distribution. Any rule changes made after the tool's launch would have to be recorded and approved as well.

When organizations go through this process, they often realize they've treated Tier 2 surveys like Tier 1 surveys.

The estimated number of work-related days lost due to depression and anxiety worldwide sits in the billions.

So it's no surprise that regulators and boards are interested in how employers identify and mitigate psychosocial risks.

ISO 45003 provides guidance on managing psychosocial risks within an occupational health and safety management system. It's not a certifiable requirements standard, though, and it doesn't turn your quarterly employee pulse survey into a psychological hazard assessment. Instead, it helps companies decide which surveys can be claimed as controls.

Duties also vary depending on where your organization operates. Some regimes explicitly require a commitment to assessing psychosocial hazards. Others include this under their general duty of care.

The key here is understanding the level of evidence required to show your organization acted responsibly and reasonably as determined in court proceedings.

Before you shop for a platform, ask Your Legal and Risk teams what kind of records your organization may need to produce and for how long you should keep those records.

This is important. You don't want to assume that an industry or security certificate is enough. An ISMS certification defines how a platform secures and manages data, but it says nothing about a product's ability to save a survey question version history that will stand up to a regulator.

The same is true for your board and human capital reporting initiatives. When you eventually include an employee engagement score in your annual reports or ESG disclosures, someone will sooner or later ask for the methodology and population details for that report.

What 7 records an audit-ready survey should generate?

A solid, defensible survey project should have more than just a final report.

At a bare minimum, your evidence/specification should contain:

• Survey instrument: The approved survey items, scales, instructions, and translations that were administered to participants in the population, along with documentation that these items were approved. This should not be the current items in your survey editor.
• Distribution record: Documentation of the population eligible for this survey at the start, how you planned to distribute the survey for each audience segment (e.g., email, SMS, kiosks, paper surveys for non-desk workers), when you distributed it and re-distributed it, and when you closed it
• Participation evidence: Number of respondents and response rate compared to the pre-identified denominator, at an appropriate level of granularity
• Data lineage How data moved from survey answers, to cleaned data, to indexes or other scores for your dashboard. Who can re-run the aggregation? Are there prior aggregation output?
• Analysis method How you did your analysis, including details about scoring rules, excluded data, suppression thresholds, weighting, and how you accessed and incorporated external benchmarks
• Action record Did stakeholders make decisions linked to specific findings? Who made sure these decisions were implemented? Were they implemented on time? Did they impact specific populations? Proof of successful implementation.
• Access records Which roles had access to which reports? When did access rights change? Did any vendors support on your platform and impersonate any user?

Survey projects often run into version control problems, because it's easy to overlook seemingly minor edits while creating a survey.

For example, changing a survey question from "I can raise concerns safely" to "I feel comfortable raising concerns" may seem like a copy editing change, but it's not. It changes the construct from perceived risk to personal comfort. This version change also affects your trend analysis or previously set up benchmarking that relies on the original survey item.

Survey-method research reviews have consistently demonstrated that changes in wording, order of response options, and changes to scale labels can affect how people respond.

Your translations are subject to these same rules. One simple way to ensure that your translations are consistent is to keep a record of back-translations or reviews by bilingual verifiers. An audit-ready survey should have this.

Otherwise, you may end up with a seemingly harsh French translated survey item compared to the English translation, resulting in an apparent, but inaccurate, regional differences in survey results.

Similarly, you want to avoid stealth changes that impact how you interpret survey data. Relabelling response scales from levels of agreement to levels of frequency, removing the "neutral midpoint" from a response scale, switching survey items from mandatory to optional - these all can impact your data collection. Even introducing new logic to the survey that makes a specific question only appear for a subset of the population can impact your participation results.

This compromises your ability to compare datasets because it changes the denominator or the construct, but the survey question looks identical. This is why your data change needs before/after values, instead of a general note that says "survey updated".

The distribution record is equally important.

As Don A. Dillman explains in Internet, Phone, Mail, and Mixed-Mode Surveys: The Tailored Design Method, response results from the entire contact sequence and the mode of contact through which respondents receive the survey, not just the exact questionnaire. This means that the design of the invitation, the number of contacts, and the specific mode of delivery are part of your survey methodology and should be included in your distribution record.

Research reviews on the impact of reminders on response rates generally find that reminders increase survey response rates, with an impact that ranges from a few percentage points to the low double digits depending on the population and methodology.

If one division sends out 3 reminders via supervisors and another simply sends out one email to shared shop-floor terminals, you're setting up a participation rate artifact rather than a culture difference. Make sure to document the reminder schedule for each unit that will eventually be part of a league table ranking.

This is even more important when you consider shift work subtleties. A survey window that allows a full rotation of shifts to complete the survey in one plant, but cuts out that night shift just in another, can create false participation rate differences that you're tempted to interpret as morale or cultural differences.

Similarly, it's important to freeze your denominator. If new employees join, others leave, and others transfer during a two-week survey fielding period, the resulting impact on response rates could be enormous. A response rate that isn't backed by a preserved population of eligible participants is just a number on a slide.

Similarly, organizations need to consider whether and how to include contingent workers like agency staff, contractors, and interns in their surveys. Whether these individuals are included or excluded in the survey population can impact both your response rate (either positively or negatively) and in some cases, your organization's duty of care.

What a good, reliable evidence trail looks like

This is important, because not all "audit logs" or "activity feeds" are created equal.

Some activity feeds only record that an administrator updated a survey.

They don't record what the value was updated from or what it was updated to.

They also don't record what the object of the change was.

This makes it pretty much useless for an auditor.

Even more troublesome are activity feeds that allow an administrator to delete log entries.

They might even merge a support engineer's activities into the tenant's activity feed.

These are all red flags.

First, you want an activity feed (audit log) that is system generated, not something an administrator writes themselves as a change log.

Each system log entry should identify what the event was, the timestamp with timezone, who made the change (including service and support user accounts), what object was changed, and what version of that object was changed.

Plus, it should identify what the values were before the change and what they were after.

For sensitive actions like changing thresholds, creating exclusion rules, or granting entitlements, the system should also record something that ties back to the overall process indicating who approved it.

You want an append-only logging system. This means that if an entry is corrected, a new log entry is created but the old log entry also remains available.

That said, a vendor doesn't necessarily need a fancy blockchain or other ledger that the founder is particularly excited about this year.

Highly scoped administrative privileges, an immutable log storage system, and periodic entitlement reviews can cover most bases.

The vendor may also want a hashing method to prove that an exported file hasn't been altered since it was actively used within the software.

And despite the cost, WORM storage may be worth the investment if there's a lot of controversy around data retention.

Vendors should also think about whether these controls apply to the right objects.

Can the vendor provide an activity feed of the entire history of changes to a question set, including saved reverts?

Can they provide an activity feed of when the suppression threshold changed from 5 to 3, who approved that change, and which reports were generated with the latest approval?

Can they prove which version of scoring was used to come up with a number that went into an important board document last year?

A simple login activity feed won't do any of this.

Lastly, it's important to recognize that implementing data immutability carries some trade-offs.

For instance, creating append-only logs seems to run counter to data minimization practices.

On the one hand, data minimization means you want to keep as little information as possible.

On the other hand, an append-only audit log or activity feed is something you cannot easily edit or purge.

One way to create a workable compromise is to avoid putting a lot of identifiers into the log entries.

Instead, you can keep the identifiers of the actors and objects referenced in the log entries, but limit putting the content of the survey or free-text values into the log entries.

This means the immutable data will be process metadata instead of personal data.

Data retention is another consideration.

Creating a datastore that just saves everything and anything indefinitely can pose a privacy risk and increase your compliance exposure.

Instead, consider a data retention policy that extends different amounts of time based on data record type.

For instance, you probably don't need the same data retention period for invitation and contact files as you do for the raw response data or derived data aggregates.

You probably don't need the same retention time for free-text comments or action plans either.

Free-text comments often pose the highest re-identification risk, so it's worth remembering their potential impact.

A good general rule is to retain invitation data and raw response data for a short amount of time, but retain data about instrument creation, methods, and action details for a longer time.

Data about instrument creation, methods, and action details are what help you prove your process while they likely don't contain much personal data.

Finally, there's the concept of a legal hold.

Your records team may put certain records under legal hold outside of the platform.

This is okay as long as the platform gives users the ability to disable automated deletions for certain record classes.

User should also be able to export these record classes in their current form without transforming them.

Balancing auditability and anonymity

First thing's first: It's important to note that auditability and anonymity can comfortably coexist since auditability refers to maintaining logs and records of actions while anonymity refers to storing the survey results in a way that's anonymous.

The audit trail doesn't have to record who provided what answers. Its goal is to prove that the process was followed.

So be honest with yourself about which survey model you're truly running.

Does your operation look like the first model where no human can link responses back to invitation tokens? Or does it look like the second model where administrators, engineers, or support agents can link invitation tokens to responses?

If it's the latter, you don't have confidential or anonymous surveys. You have confidential surveys with an access control policy.

Be upfront about which one you're running, and don't lull employees into thinking they're participating in the former when it's the latter.

When employees choose not to speak up, two common reasons are consequence-related fears or beliefs about a lack of effective changes.

A committee-written privacy notice that hedges its bets on these points may fuel both problems instead of alleviating them.

Clearly state what is being captured about identifying employee information, when and if that data is disconnected from the survey results, and whether any roles can link the two datasets back together.

At the same time, clearly explain what the reporting threshold is.

Sure, setting a minimum number of participants helps avoid deductive disclosure. But this is only true if the minimum number applies across data filters, exports, drill-downs, and comments views.

For example, if a data manager wants to see the results of 3 responses, can they get that by viewing a parent data set of 8 responses and choose to ignore the results of the other 5?

This issue can multiply with organizations that commonly apply filters based on specific departments, time with the company, role level, or demographic. It can also multiply when dramatically different exports of the same population occur within short timeframes.

Similarly, creating verbatim reports inherently compromises anonymization. Posting a comment that explicitly shares information about the employee's shift, client, or experiences can easily reveal who wrote the comment even if the results were grouped.

Will you display the raw comments? Will a small group of trained specialists review them first? Will comments only be released as themes?

Make these decisions ahead of time and ensure they're documented. You don't want to see a bunch of raw comments on your site labeled under your current white paper when a different rule applied in the past.

Privacy research has demonstrated that a small number of attributes can lead to individuals being identified in supposedly anonymous datasets.

While the exact risk varies from one labor force to another, organizations with smaller groups of executives or specialists should be especially thoughtful.

All in all, it's a good idea to test your organization's confidentiality rules against the smallest real teams in your organization, rather than an idealized version of your org chart.

Finally: What happens if there is an employee investigation that requires knowing who a respondent was?

In a truly anonymous survey, your platform should not be able to provide the respondent's identity. Make sure this is clear during your platform demo, so you're not caught on the ropes later.

Here's another consideration where opinions differ: Should your organization offer anonymous surveys and separate means of reporting that gather names? Some concern that asking about issues like harassment, for instance, even anonymously, will lead the organization to a legal duty to act. And if the organization has a duty to act, they need a lawful way to investigate.

Sorting this out ahead of time with your legal team can give you a confident answer once your project launches.

For your next consideration, online privacy experts suggest thinking about how your organization will handle an employee data request. What if an employee wants a copy of his or her survey response, or to have the information deleted, and that isn't possible because the data was designed to be completely unlinkable?

Usually a strong case for anonymity is that it makes it easier to respond to privacy requests.

Questions to put in your rfp and demo script

You have your potential vendors answer questionnaire questions. You want them to have "audit logs" as a feature. Unfortunately, all vendors claim they have it, so you don't really know whether they do or not.

Instead, you want your vendors to demonstrate this feature.

During your vendor evaluation, you can ask prospective companies questions like:

• Export the raw audit log from a completed test survey from the system and walk us through the architecture of this raw data
• Edit one item from an approved test survey after it has been launched in front of the user and show us all of the events this took place including the before and after values
• Can any administrator, engineer, or member of the support team edit, delete, or replace a submitted response? Will this action be logged under their user or ours?
• How are changes to scoring rules, exclusions, and suppression thresholds logged? Will the impacted reports be flagged as requiring re-generation?
• Which of these logs can a customer admin export on their own? How long will these logs be stored for?
• How will timestamps, timezones, and actor IDs be formatted when these logs are exported?
• How will the data for survey invitations be stored separately from survey responses? Will the key that links these two datasets be deleted or stored?
• Can the vendor demonstrate that survey results from overlapping reports cannot be subtracted from each other to reveal suppressed groups?
• Can we temporarily disable automatic deletion of specific types of records due to a legal hold?
• What data can we access at the end of the contract? In what format? How long will you keep backups after contract termination?
• Who are your subprocessors and where is data processed? Can customers object if you add a new subprocessor to the process?
• What is the required notification period for informing us of a confirmed security incident? What information will you guarantee to provide in this initial notification?

These should be scored on a pass or fail basis instead of weighted questions. Otherwise, you may overlook a critical compliance need when dazzled with an excellent analytics demo.

If three things turn out to be no's for a tool listed as a Tier 2 or Tier 3 tool, you should re-consider that option. You are referring to:

• Support staff acting under customers' accounts with restricted visibility
• Administrators' ability to delete log entries
• No or limited versioning of changes for question sets

Once you think you're moving forward with a survey tool, put it through a real world test.

Create a survey, activate it, distribute it to a test population, modify a survey item midway through, add an administrator, and change suppression thresholds.

Ask the vendor to demonstrate that these features will provide you with the appropriate evidence.

"We can build that!" is not the same as evidence that you will have this capability.

If your vendor shares a roadmap with you, push them to clarify whether these features are contractually committed or aspirational. This helps you decide if you can include these new features in your survey program controls.

Your security review should also be thorough.

If your vendor is ISO 27001 certified, ensure that you read the certificate's scope statement, check which legal entities are covered under the certificate, and understand if there are any exclusions in the Statement of Applicability. A common but easily overlooked gap is that the corporate network is included in the certificate while the production platform is not.

If your vendor has a SOC 2, understand whether it's a SOC 2 Type 1 or SOC 2 Type 2, what the observation period is and if there's a period since the last audit, (ask for a bridge letter), and what the letter stated were exceptions. You also want to know what the accompanying user entity controls are. These are data protection obligations the report places on your organization that you may not be aware of.

Furthermore, your Data Processing Agreement should cover key items. You want to know how to provide instructions, what the customer can do if there are changes to subprocessors, how to delete data once the contract ends, when the vendor will notify your organization of any data incidents, what the vendor offers in terms of international data transfer mechanisms, and if the vendor will help with data subject requests. You need a plan to deal with access and erasure requests if the data is anonymized.

This is something you want to put in your documentation in case an employee asks about it.

You may also want to include an obligation that the vendor will support audits on data protection. What if the vendor needs to provide records to a regulator or a court and the vendor is the only one who can generate these records? You should include a timeline for a response, a designated contact, and a transparent costing model.

Industry studies often put the average lifecycle of a data breach at well over 200 days from discovery to containment, although this can vary depending on the type of security incident.

All in all, you want more than a "promise" to take security seriously when conducting your pre-procurement due diligence.

At Sparkbay, we can help enterprise teams configure how they want their surveys to be worded and how their dashboard displays content based on their approved listening program.

This is useful because when you've negotiated your survey instrument with your Legal or Risk teams or employee groups, you want to ensure this is the wording you're committed to using, as opposed to whatever text comes pre-packaged with your survey.

Our main metric is an engagement score out of 10. That said, teams can also use eNPS for their main metric if they want, but our engagement score metric would still be the primary measure.

That said, you should still keep a copy of your approved survey instrument and scoring system specification as part of your enterprise records management policy. While we can help you configure your product, it's not a substitute for formal document control if your regulatory compliance requirements include drafting controls.

Furthermore, your dashboard will only let users view reports based on your org hierarchy, so that a manager can only see the results from their teams. This means you should evaluate the accuracy of your HRIS's org hierarchy structure, including dotted-line reports or matrix reporting.

Additionally, we shield small group results based on a response threshold you can modify. The default threshold is 5.

We suggest you thoroughly test your response threshold based on the smallest teams you have before publishing a manager-level heatmap. While 5 is the default setting, it's meant to be a starting point.

Sparkbay is ISO 27001 certified. Your procurement team can use this certification as part of their security evaluation.

If you're interested in learning how Sparkbay can help you build a more engaged workforce, you can click here for a demo.

Document what management did next

Survey results only serve half of their purpose.

If you're an inspector reviewing psychosocial risk, you want to see what you did with the identified risks. How you evaluated the risk and what control you chose. Plus, it's critical that you see who accepted the level of residual risk.

Unfortunately, this is the step that many organizations don't follow through on.

Employee relations teams and other departments need this documentation as well in case an employer is alleged to have known about an issue (based on their survey results).

Unfortunately, many survey programs end at the presentation deck.

Managers discuss what to do about three weak scores, "agree to communicate more" and move on without assigning an owner or setting a due date.

This turns psychosocial risk assessments into a checkbox exercise.

Your survey program should help you link each planned action to the specific finding that prompted it.

You want to document who is responsible for the action, who approves it, the due date, the relevant employee population, the expected proof of effectiveness, and the action's status.

Plus, you want to document what kind of controls these are. This is important for inspectors. Are your planned controls activities and communications (relatively weak controls) or are they stronger controls like workload re-design, changes in staffing, changes to work schedule (rotation) or increased accountability among management?

It may look like you decided on psychosocial risk controls by simply going for the cheapest options. Were all your responses to workload issues in the form of a webinar? That may suggest that your organization identified the psychosocial risk but decided on the cheapest possible control.

If management decides not to act (which is a possibility), you want to document why. Why did management accept the risk level instead of acting? This is important because a documented and reasoned acceptance of risk is better than leaving an action field blank for a red score.

Yes, this is a tedious step that may cause some counselors distress since they want to protect their clients.

But the alternative is even worse. Your organization will have collected many warning signs and will have no way to demonstrate that anyone took a look at them.

To that point, you want to clearly state who has the power to accept the level of residual risk, and make sure they are the appropriate people. Having a frontline manager accept a staffing risk when they don't have the authority to fix the staffing issue is a problem.

Research on employee voice shows that workers are more likely to keep speaking up when they see their leaders take their input seriously.

Studies of larger workforces tend to show a correlation between positive engagement and key business metrics like turnover rates and overall business performance. The difference is often estimated to be in the double digits, though numbers vary depending on the industry and job type.

So be sure to communicate what is changing, what isn't, and why.

You may need to keep certain details under wraps if there's an ongoing confidential investigation, but you don't want to pretend nothing happened.

Finally, consider re-doing your psychosocial risk surveys to close the loop on your controls.

You want to keep the questions the same where you want to collect trend data, but update the employee population, distribution methods, channels, etc. if they've changed in a way that limits your ability to compare (e.g. how often you send surveys to employees).

If you collect higher scores, don't assume that this is proof of the effectiveness of your previous controls. Instead, consider this data point alongside how many grievances you've received or reduction in sick days, employee turnover, or other relevant metrics for the new employee population. This way you can use converging evidence instead of relying on the survey scores alone.

Also keep an eye on second-order effects. Once managers know that a weak score will trigger scrutiny, some will coach employees on how to complete the survey, wait until a good week to carry out the survey, or encourage employees not to participate at all.

Consider your evidence management model before visiting the vendor

Where should you start?

First, gather your key stakeholders in HR, Privacy, Legal, Records, Risk and IT functions for a collaborative working session.

Consider the different objectives of your surveys (e.g., employee engagement pulse survey, psychosocial hazard assessments, confidential sensitive cases) and, subsequently, how each should be managed from a data and document controls perspective.

For each of your use cases, try to answer these questions:

• Which legal entities, employee populations, and works council frameworks will be in scope?
• Which legal obligation, regulatory standard, or internal policy specific requirements does the survey help you meet?
• Will the data or records be anonymous or confidential? Will the join key be deleted or retained?
• What types of data or records must be saved? Will a Personal Data Impact Assessment be required?
• Who can access data at different levels (e.g., group-level results, access to raw comments, objects to enable data to be downloaded)?
• Are there specific data suppression rules that must be applied, and how can these be tested for conflicts with company subtraction policies?
• What are the applicable retention requirements for different types of data or records?
• Who will approve changes to the survey after it is launched, and how will this approval be documented?
• Where will data or records related to actions (if not stored in the survey tool) be stored?
• Who will be tasked with putting together the audit package, and how much time will that reasonably take?

Write these answers into your data and record evidence specification before you start meeting with vendors.

If you don't, your data and record requirements will be dictated by a vendor's sales demo. You may purchase something that looks great from a sales demonstration video, only to wind up scrambling to fill data and record management gaps once you begin implementing your digital tools and no longer have any negotiating power.

Identify a single owner for the entire, end-to-end data and record management.

Your HR team may own the implementation of the instrument while your IT team owns some of the access logs information and your Records Team manages data retention. This split is perfectly reasonable.

But there should be a clear, identifiable person or role who owns the entire project's end-to-end development and management.

Flag potential areas of tension and special consideration while you have everyone in the room.

If your survey is run by an external consulting team, for example, your survey instrument, population file, and survey responses will be stored on a third party's system. You'll need to decide if you will receive a copy of the audit log and what you'll be entitled to receive if things go south with the external consultancy.

The same considerations apply to entities being divested or newly acquired. Will the survey data of divested entities still be part of your data or records management system? Will new entities come with survey methods you did not approve?

Plan a mock audit 90 days after go-live.

Take the results of a completed test survey and give them to someone who wasn't involved in its set up. Can they find the approved survey instrument, data showing how the survey was distributed, data showing how the responses were scored, data showing who had access to the records, and/or data showing what actions were carried out?

Time this process. Also note what information this person had to get from the vendor and what they had to get from other team members' notes or memory. These highlight your critical gaps.

Check your current tool before starting the next survey

You may not need to replace your platform.

A number of your current gaps may be addressed by scheduled exports into your records system, tighter admin rights, or a named owner.

We recommend taking this approach where possible. Just keep in mind that it's not always feasible to shoehorn action plans, approvals, and risk acceptances into your survey tool. Don't prioritize keeping your survey tool clean over making sure you have the right evidence.

Use this as a guideline, but don't get trapped by it.

Before you launch your next survey, export data from your current tool.

Export the exact question set and scoring rules they will use when fielding the survey.

Export a frozen copy of the eligible population and the planned send/reminder schedule for each unit.

Test your suppression filters. Can you easily suppress certain units using your filter settings? Can you remove all others from the dataset to find any previously hidden units?

Generate a change history. Can you do this without asking the administrator who made the changes?

Finally, follow a poor survey result through the entire process. Can you easily retrieve approval documents, demonstrate why certain actions were taken, show evidence that the actions were successfully completed, and show any follow-up measurement?

If not, decide where you'll keep these documents or files and how they will be maintained before you distribute the survey to employees.

Finally, if you do switch vendors, consider the two different types of data you want to migrate: trend data that you'll want to use in your new dashboard, and your evidence file for previous survey cycles.

You'll want to keep your evidence files from previous survey cycles - at least - as exports before you stop using the old tenant. You don't want to lose these data if you terminate the contract.

If you're interested in learning how Sparkbay can help you build a more engaged workforce, you can click here for a demo.