Nice to know for UX, Product Designers, and Product Managers 

In the process of designing any digital product, there is always a time when you, as a UX or Product designer, need to make a tough decision.

It’s often combined with the limited time and pressure from customers, engineers, managers, and everyone else in the product development cycle.

You may need to accept that panic, fear, and lack of self-confidence are often part of the decision-making process.

Sounds familiar? In this article, I’ll share a six-step decision-making framework that will not only make your process faster but also easier to articulate to all those involved.

When making a decision, we form opinions and choose actions via mental processes which are influenced by biases, reason, emotions, and memories. The simple act of deciding supports the notion that we have free will. We weigh the benefits and costs of our choice, and then we cope with the consequences. Factors that limit the ability to make good decisions include missing or incomplete information, urgent deadlines, and limited physical or emotional resources.

Psychology Today

The ability to think critically is key to making good decisions without succumbing to common errors, bias, or intuition. “There is a need for disciplined intuition and what I mean by disciplined is delayed intuition. One of the many problems with our intuitions is they come too fast and we tend to confirm them.” (Kahneman, Daniel. Thinking, Fast and Slow. New York: Farrar, Straus, and Giroux, 2011.)When you look at all possible sources of information with an open mind, you can make an informed decision based on facts rather than intuition.

Let’s move on to putting the decision-making framework into action.

Design Decision Framework 

This process will ensure that you make a good decision in a complex situation, but it may be unnecessarily complicated for small or simple decisions. In these cases, jump ahead to step 5.

Step 1. Investigate the problem

Start by considering the decision in the context of the problem it is intended to address. You need to determine whether the stated problem is the real issue or just a symptom of something deeper.

To make a proper problem investigation, first you need to know the user that is facing this problem, why it happens, and how often it occurs – to name a few. There are many things to know about your user and product when you’re working on a new problem. To make sure that you understood the core problem, using the 5 Whys framework can be helpful.

Step 2. Set up the environment

Enable people to take the discussions without any fear of the other participants rejecting them and their ideas. Make sure that everyone recognizes that the objective is to make the best decision possible in the circumstances, without blame. This is often referred to as psychological safety, and it’s a key part of the process.

Step 3. Generate good alternatives

The wider the options you explore, the better your final decision is likely to be. Generating a number of different options may seem to make your decision more complicated at first, but the act of coming up with alternatives forces you to dig deeper and to look at the problem from different angles. Make sure that all of your options are good enough – you don’t need to create options just for illusion of choice or quantity.

When you’re satisfied with the choice of realistic alternatives, it’s time to evaluate the value, feasibility, and risks of each one.

Step 4. Select the best solution

This is the step where you make a decision!

In the design process, you can’t really develop a product by yourself, so you will probably make a decision as a group of people – and of course more people make it a more complicated decision process. It is optimal to keep the total number from 3 to 7, depending on your company process.

If there’s a tendency for certain individuals to dominate the process, you can arrange anonymous voting or assign a facilitator who will ensure equal participation.

To simplify the final decision, you can use the product design principles of your company to find the solution that will perfectly fit into your brand and strategy.

“Product design principles (or, in short, design principles) are value statements that describe the most important goals that a product or service should deliver for users and are used to frame design decisions.”

NNGroup

To make small design decisions—components, colors, alignment—lean into your design system and guidelines, as they should cover most of the cases. If they don’t, make a note and discuss it with a design system owner to make sure that your idea will fit into the general strategy.

If your product, for one reason or another, does not have an established design system, you can use well-known systems like Material Design, IBM, etc.

Step 5. Evaluate your decision

Now is the time to check your decision one more time. Before you start to implement your decision, take a long, dispassionate look at it to be sure that you have been thorough and that common errors haven’t crept into the process.

Your final decision is only as good as the facts and research you used to make it. Make sure that your information is trustworthy and try to avoid confirmation bias.

Of course, sometimes you are limited by resources for implementation, release date, or budget, so it’s impossible to implement the best solution. And that’s okay! As a designer, you should always remember that the development of the product is an iterative process, so you just need to choose the most suitable option in the current circumstances for your product to evolve, even if you personally do not like the solution. If this decision will have a balance of usefulness for the user vs. resources used – then you made the right decision.

Step 6. Communicate your decision and take action.

Once you’ve made your decision, you need to communicate it to everyone affected by it in an engaging, informative, and inspiring way.

Get them involved in implementing the solution by discussing how and why you arrived at your decision. The more information you provide about risks and projected benefits, the more likely people will be to support it.

Summary

• Remember, we’re all humans. It’s okay to have emotions involved in the decision process – you just need to know how to handle it.
• Think critically and make an informed decision based on facts rather than intuition – don’t allow the desires of others to dictate your decision.
• You’re not alone: collaborate with your project team.
• Communicate the decision that you made in an engaging and inspiring way. Explain why you came up with this decision – don’t present a decision as a fact.

Involved or interested in design? For further reading, check out our other blog posts by the Keepit design team, such as how Keepit puts UX first and why customers love Keepit’s ease of use.

It’s easy to get a false sense of security and assume that your Microsoft 365 data is safe and secure because M365 automatically backs up your SaaS data for simple recovery, right?

 

Well, not so fast.

 

While M365 and most other SaaS platforms offer some sort of data protection and recovery features, it’s bare bones at best. For healthcare organizations, this opens Pandora’s box for compliance and continuity issues that can end up costing hundreds of thousands of dollars in fines. And on top of that, add the inability to serve patients and conduct daily business.

 

It’s critical to have timely and secure access to patients’ highly sensitive personally identifiable information (PII), protected health information (PHI), financial information, intellectual property, and credentials. However, given how this information has grown exponentially, data loss prevention has never been more necessary to ensure business continuity.

It’s crucial to understand that retention requirements far exceed what SaaS applications typically deliver natively, making it vital to close the gap with a reliable backup and recovery tool.

For healthcare organizations, compliance and continuity are the two main factors driving the need for third-party SaaS backup.

Regulatory Compliance
The Health Insurance Portability and Accountability Act of 1996 (HIPAA) makes healthcare delivery organizations legally obligated to preserve certain types of information for periods that exceed a SaaS service’s built-in capabilities.

As the HIPAA Journal explains, each state has its own laws governing the retention of patients’ medical records. To complicate things further, those retention periods can vary considerably. 50 states with 50 retention requirements: Is this something your healthcare organization wants to (or can afford to) manage?

Individual U.S. state laws govern the retention of patients’ medical records, while HIPAA imposes requirements on how long HIPAA-related documents must be retained.

According to the HIPAA Journal, “In Florida, physicians must maintain medical records for five years after the last patient contact, whereas hospitals must retain them for seven years. In North Carolina, hospitals must maintain patients’ records for 11 years from the date of discharge, and records relating to minors must be retained until the patient has reached 30 years of age.”

The hard truth is that SaaS services do not deliver the level of backup and recovery required for healthcare organizations, and what they do provide isn’t seamless.

Business Continuity
Imagine the worst-case scenario where your mission-critical data is suddenly gone—it’s not hard to imagine since it happens to companies every day. Healthcare organizations rely on the information stored in SaaS systems to maintain their business continuity. If the information suddenly becomes unavailable, then significant disruption results.

Continuity Considerations
Things can (and do) go wrong with SaaS data: a simple misconfiguration can cause primary data sources to become unavailable, making accidental deletion a real risk, which may not be discovered until it’s too late to recover from the SaaS app – and may be unrecoverable even if you do find it quickly.

In fact, according to ESG Research, the most common reasons for data loss are service outages and accidental deletion, as seen here:

2 Reasons Why: M365 Data Backup for Healthcare Organizations
Compliance 26.10.22 9 Minutes
It’s easy to get a false sense of security and assume that your Microsoft 365 data is safe and secure because M365 automatically backs up your SaaS data for simple recovery, right?

 

Well, not so fast.

 

While M365 and most other SaaS platforms offer some sort of data protection and recovery features, it’s bare bones at best. For healthcare organizations, this opens Pandora’s box for compliance and continuity issues that can end up costing hundreds of thousands of dollars in fines. And on top of that, add the inability to serve patients and conduct daily business.

 

It’s critical to have timely and secure access to patients’ highly sensitive personally identifiable information (PII), protected health information (PHI), financial information, intellectual property, and credentials. However, given how this information has grown exponentially, data loss prevention has never been more necessary to ensure business continuity.

It’s crucial to understand that retention requirements far exceed what SaaS applications typically deliver natively, making it vital to close the gap with a reliable backup and recovery tool.

For healthcare organizations, compliance and continuity are the two main factors driving the need for third-party SaaS backup.

Regulatory Compliance
The Health Insurance Portability and Accountability Act of 1996 (HIPAA) makes healthcare delivery organizations legally obligated to preserve certain types of information for periods that exceed a SaaS service’s built-in capabilities.

As the HIPAA Journal explains, each state has its own laws governing the retention of patients’ medical records. To complicate things further, those retention periods can vary considerably. 50 states with 50 retention requirements: Is this something your healthcare organization wants to (or can afford to) manage?

Individual U.S. state laws govern the retention of patients’ medical records, while HIPAA imposes requirements on how long HIPAA-related documents must be retained.

According to the HIPAA Journal, “In Florida, physicians must maintain medical records for five years after the last patient contact, whereas hospitals must retain them for seven years. In North Carolina, hospitals must maintain patients’ records for 11 years from the date of discharge, and records relating to minors must be retained until the patient has reached 30 years of age.”

The hard truth is that SaaS services do not deliver the level of backup and recovery required for healthcare organizations, and what they do provide isn’t seamless.

Business Continuity
Imagine the worst-case scenario where your mission-critical data is suddenly gone—it’s not hard to imagine since it happens to companies every day. Healthcare organizations rely on the information stored in SaaS systems to maintain their business continuity. If the information suddenly becomes unavailable, then significant disruption results.

Continuity Considerations
Things can (and do) go wrong with SaaS data: a simple misconfiguration can cause primary data sources to become unavailable, making accidental deletion a real risk, which may not be discovered until it’s too late to recover from the SaaS app – and may be unrecoverable even if you do find it quickly.

In fact, according to ESG Research, the most common reasons for data loss are service outages and accidental deletion, as seen here:

Still, accidents, misconfigurations, and other ‘innocent’ causes aren’t the only ways to lose data.

In recent years, ransomware gangs have set their sights on the healthcare sector and, unfortunately, have been successful in their efforts to disrupt and demand payment for the data’s return.

Fulfilling Regulatory Obligations
Few people like being told what to do, but it turns out that governments do have the authority to compel action.

In the U.S., federal and state laws impose strict requirements around data retention for different healthcare records and information types. Additionally, regulations are subject to change, adding more pressure to comply to avoid a regulatory audit and heavy fines. Failure to comply can lead to significant financial and legal exposure, such as lawsuits, fines, settlements, and certification losses, further increasing the risk of data breaches.

For Healthcare delivery organizations (HDOs) committed to minimizing or avoiding these risks, having a proper backup and recovery practice in place is key to compliance.

Third-party backup and recovery services help you stay compliant by ensuring your data remains immutable and tamperproof. Immutable data and metadata make it possible for you to document and recover not just all data but all data processing, ensuring that auditors have complete visibility of everything that has impacted the data.

If complying with laws (and avoiding potentially hefty fines) isn’t enough to secure the budget, there are other reasons to invest in SaaS backup, such as mitigating downtime and costs.

Protecting Business Continuity
In a presentation titled “Conti Ransomware and the Healthcare Sector,” the United States Department of Health and Human Services (HHS) relayed that:

the average length of a general ransomware incident is 19 days.
Cybersecurity provider Sophos reported that 25% of healthcare organizations disrupted by ransomware took up to a month to restore operations. Sophos’ research also suggests that:

the average remediation cost for healthcare organizations soared to USD 1.85M in 2021 (up from USD 1.27M in 2020).
Keeping services operational is essential for maintaining the revenue that sustains an organization. That’s why having reliable backups that can quickly and easily be restored is paramount.

Unfortunately, the reality is that data outages are a matter of when, not if, making your ability to recover key data (and fast!) a necessary part of business continuity planning. Additionally, the shorter the outage, the lower the recovery and remediation costs, making loss avoidance a compelling part of the value proposition.

Recovery processes and costs can also include Digital Forensics and Incident Response (DFIR) activities, whether mandated by cyber insurance coverage, necessary for root cause analysis, driven by a motivation to prosecute, or some other reason.

Third-party backups assist DFIR activities by providing trustworthy information that extends further back in time than what can be pulled from SaaS applications.

But being able to restore services quickly from a dedicated SaaS backup doesn’t just protect revenue and minimize recovery costs, it also means you avoid paying the ransom and lower your cyber insurance fees.

Protect Your SaaS Data Today
If you can recognize some of the data backup and recovery vulnerabilities discussed here within your own healthcare organization, the good news is that it’s easy and cost effective to address those challenges and help secure your organization’s data.

Unintentional and malicious data losses don’t offer the convenience of a “heads up,” so it’s a wise business decision to have a proper backup and recovery solution in place before you need it – and as such, it should be an integral part of your cybersecurity approach. Only backup allows you to go back in time and recover to before bad things happened!

If you’d like to learn more about compliance and continuity for healthcare organizations, access the

Say you’ve taken the wise decision to have your corporate cloud data be backed up by the Keepit cloud solution: you’ve selected one of our many data centers, configured relevant connectors, and are now seeing how snapshots are blissfully parading into eternal archive as you log in to the Keepit web user interface. But perhaps you want a bit more assurance and perhaps you are not keen on logging into a separate web application several times a day to get that assurance.

Many of our customers have their own monitoring solutions and communication systems that they wish to enrich with information from their Keepit account. Luckily, we have a very elaborate API (Application Programming Interface) to allow for all sorts of queries on the state and history of your backups; while we do publish the full API documentation, some might find a small appetizer easier to comprehend.

If you’re already a Keepit customer and if you have an account and working connectors, then this blog post will guide you through creating a PowerShell API agent that prints the timestamp of the last completed backup on your screen. It is very simple: it will not integrate into any monitoring or alerting system, it will not print fancy messages in any messaging platforms, nor will it draw graphs on its own – but it is a small building block that you can extend and transform into whatever you might need.

Getting Access to the API

In order to make calls to the API, your script needs to have the proper credentials and those are obtained through the web user interface. So, log in with a user that has at least ‘Job Monitor’ privileges and create an API token by doing: Users -> Your user – Edit User (the grey cog wheel) -> Security -> Add API token. Give the token a name and decide when it should expire; the API token cannot outlive the user it is associated with. Click ‘Create’ – confirm your password and you will get an API token username and password. Those you need to store in a secure place.

You are now ready to make API calls. For this example, we will be using PowerShell, and the first API call to be made is the call to obtain your account GUID. Now, the account GUID is also available in the web user interface, but obtaining this via the API is a nice, small exercise to verify that the API token and your script is working. 

Launch your favorite text editor – it can be Notepad, Notepad++, VSCode, Vim, or whatever you fancy the most, create the file accountguid.ps1 and paste this code into it:

try {
        $username = '<API Token username>'
        $password = '<API Token password>'
        $basicauth = [Convert]::ToBase64String([System.Text.Encoding]::ASCII.GetBytes('${username}:${password}'))
        $headers = @{
            'User-Agent' = 'PowerShell-Keepit-API-Agent-1.0/jakob-dalsgaard'
            'Authorization' = 'Basic $basicauth'
        }
        
        $response = Invoke-WebRequest -UseBasicParsing `
          -Uri 'https://de-fr.keepit.com/users' `
          -Method:Get -Headers $headers -ErrorAction:Stop -TimeoutSec 10 
        
        $userlist = [xml]$response.Content
        $id = $userlist.user.id
        
        Write-Host $id
}
catch {
        $line = $_.InvocationInfo.ScriptLineNumber
        Write-Host 'Cannot query Keepit API due to: $_'
        Write-Host 'at line $line'
}

Make sure to get the backticks and single and double quotes correct – computers can be very pedantic. In this file, you need to put in the API Token username and API Token password where specified. On line 11, this example reads ‘de-fr.keepit.com’ – thus valid for a Keepit account on our German data center – please change this hostname to the hostname of the data center for your account (i.e., ‘dk-co’, ‘uk-ld’, ‘us-dc’, ‘ca-tr’ or ‘au-sy’). Then, in a command terminal, you execute the script by typing:

Powershell .\accountguid.ps1

Depending on your security setup, you might need to confirm that you really want to execute a script, but please do – and you should see the script print out your 20-character account GUID. This GUID can then be used, along with the API Token, to obtain the list of connectors available in your account.

Save the following code block as devices.ps1:

try {
        $username = '<API Token username>'
        $password = '<API Token password>'
        $userguid = '<Account GUID>'
        $basicauth = [Convert]::ToBase64String([System.Text.Encoding]::ASCII.GetBytes('${username}:${password}'))
        $headers = @{
            'User-Agent' = 'PowerShell-Keepit-API-Agent-1.0/jakob-dalsgaard'
            'Authorization' = 'Basic $basicauth'
        }
        
        $response = Invoke-WebRequest -UseBasicParsing `
          -Uri 'https://de-fr.keepit.com/users/${userguid}/devices' `
          -Method:Get -Headers $headers -ErrorAction:Stop -TimeoutSec 10 
        
        $devicelist = [xml]$response.Content
        foreach ($system in $devicelist.devices.cloud) {
                $name = $system.name
                $guid = $system.guid
                Write-Host 'Name: $name'
                Write-Host 'Guid: $guid'
                Write-Host
        }
}
catch {
        $line = $_.InvocationInfo.ScriptLineNumber
        Write-Host 'Cannot query Keepit API due to: $_'
        Write-Host 'at line $line'
}

Again, put in API Token username and password, the Account GUID, and correct the hostname. Then execute as:

Powershell .\devices.ps1

Your terminal will then be filled with a list of connector names and GUIDs, and among those you will have to select one that can be used in the final script that will be called latest.ps1– this script will print out the timestamp of the latest backup performed by one specific connector:

try {
        $username = '<API Token username>'
        $password = '<API Token password>'
        $userguid = '<Account GUID>'
        $connectorguid = '<Connector GUID>'
        $basicauth = [Convert]::ToBase64String([System.Text.Encoding]::ASCII.GetBytes('${username}:${password}'))
        $headers = @{
            'User-Agent' = 'PowerShell-Keepit-API-Agent-1.0/jakob-dalsgaard'
            'Authorization' = 'Basic $basicauth'
        }
        
        $response = Invoke-WebRequest -UseBasicParsing `
          -Uri 'https://de-fr2.keepit.com/users/${userguid}/devices/${connectorguid}/history/latest' `
          -Method:Get -Headers $headers -ErrorAction:Stop -TimeoutSec 10 
        
        $history = [xml]$response.Content
        $tstamp = $history.history.backup.tstamp
        if ($tstamp) {
            Write-Host $tstamp
        }
        else {
                Write-Host 'Backup not completed yet'
        }
        exit 0
}
catch {
        $line = $_.InvocationInfo.ScriptLineNumber
        Write-Host 'Cannot query Keepit API due to: $_'
        Write-Host 'at line $line'
        exit 1
}

Again, put in API Token username and password, account GUID, connector GUID, correct hostname, and then execute as:

Powershell .\latest.ps1

If your selected connector has completed a backup, you should now, in your terminal, see the timestamp of completion of the latest backup for this connector. It might look something like: 

2022-12-24T18:30:00Z

This would say that the latest backup completed on Dec 24, 2022, at 18:30 UTC. The timestamp is given in the ISO8601 format with the Z designator for UTC.

Further Integration

While such a neat PowerShell script is nice to have on the command line, it will bring much more value as part of a monitoring platform or other reoccurring automatic execution. For your business, it might make sense to execute this script once per hour and alert if no backup has been completed for 24 hours. You might want to explore our public API for more information and status.

Keepit is known for delivering a certain quality of User Experience (UX), which is reflected in customer feedback examples, such as: 

‘Keepit’s user-friendliness is a financial win-win’ and ‘I like to call Keepit a Steady Eddie. I know it’s working; I know it’s running, and I don’t have to sweat it.’.

Behind Keepit’s simple design and ease of use lies a deliberate approach, rooted in the idea that our whole system, from the deepest backend layers to the user interface, is built to support a solid User Experience.

However, in the software field, UX has been interpreted in various ways and caused confusion in how it differs from User Interface Design. So, what is UX to Keepit? And how does Keepit go about all this in practicality?

Foundation

UX goes beyond the immediate visual impression and beyond isolated interactions within the product. It is a silent ambassador that ensures a seamless experience throughout any touchpoint. A journey sprinkled with an undefined X factor that leaves our user with instant recognition without the need for explanation -a quality that flows through every vein of Keepit.

An experience starts before the product is even used by our customers. As Don Norman, the inventor of UX, puts it, ‘No product is an island […] It is a cohesive, integrated set of experiences […] Make them all work together seamlessly.’

Leveled circulation

On both conscious and unconscious levels, a human experience is perceived and processed as a sum of different events. The more you know about people, the better experience you will be able to design. To translate such a complex sum into a consistent Keepit experience, we use our Design System as a single documented source.

Here all Keepers will find Design Principles, components, guidelines, patterns, and themes. However, the UX circulates on more levels. To grasp this in a software context, mapping out different levels of the experience can help.

Interaction level

On this level, we work with both look and feel when interacting with the product, from visual design to Information Architecture to navigation. The focus is to design the experience of a certain interaction that a user has with Keepit to perform a task, such as restoring data in Keepit’s application.

However, a user interaction can also exist outside the product interface. One example is receiving support. Each of these interactions are single strokes of experiences that play a role in the relationship with our customer.

On the interaction level, our Design Principles, guidelines, and patterns play a central role. We operationalize this with a pyramid logic in layers, with a theme on the top level and dos and don’ts on the bottom level. Here is an example:

Design Principle: Keepit Sets Me Free

• What users should feel: In every interaction, I as a user should feel the freedom of being in control. This means being offered the most relevant choices at the right time. The choices should lower my cognitive load so that I feel enabled to effortlessly succeed at my tasks.
• Examples of what users should think: ‘I control the situation’ – ‘This is unbelievably easy’- ‘Keepit makes me better at my job’- ‘I get what I need when I need it’
• Examples of what users should see: Recognizable patterns – An easy first entry to the system – Understandable language
• What designers should do: Always give feedback – Build a strong visual hierarchy – Know and understand the user – Always remember what problem we are solving for the user
• What designers should not do: Don’t make the user wait, don’t speak in system language, don’t overload the user with information

Journey level

Zooming into the journey level, we recognize that putting UX first is not isolated in the product interaction itself. The key word here is ‘journey’. Mapping out journeys enables us to discover user needs and pain points, in the quest of providing seamless and consistent experiences across Keepit’s channels.

There are methods to identify key needs and transform them into design challenges. Apart from organized methods, such as usability tests, analytics, and organized customer interviews, there are also more organic user dialogues. From support, through live events, from sales, and so on. In all these touchpoints there are chances to identify key user needs and discover how the Keepit product can solve real user problems.

The key point here is to identify where the needs and pain points are rooted; define the root problem and translate this into design challenges. Further down the road, when ideating on design solutions, the user experience should be consistent in every chosen design solution. Again, this is where the User Experience pyramid, with its design principles at the top, plays its role as a foundation for the other experience levels.

A level connecting the dots

This means that UX is related to the spirit of Keepit, across the whole company. Throughout the different areas of expertise of Keepit, UX connects the dots and remembers to keep the users’ needs at the core of what we do: to deliver simple and safe backup solutions that can set our customers free from the worries of losing data. Keepit’s UX delivers this X factor in its tone of voice, the product’s look and feel, user touchpoints, and customer dialogues.

Keepit’s UX goal is to deliver a consistent heartbeat of look and feel throughout the user journey, anytime, anywhere – pumping it through Keepit’s veins.

UX metrics

As designers, we recognize the challenge in measuring UX, since we are dealing with human behavior and attitude. Here we use deliberate approaches such as confirmation bias. When working on improvements to Keepit’s UX, our main goal is to gather insight, combined with quantitative results.

We want to understand the context and situation that the user is in when encountering Keepit, as well as how this context affects the user.

We also want to know what works, what doesn’t, and why. These insights are gathered through activities such as user interviews and observations. The outcome should be an understanding of user values, supported by quantitative data on average numbers or rates. Additionally, usability metrics give value to the work of measuring. Our different approaches have the common mission of delivering an excellent User Experience, based on data-informed decisions.

Zendesk backs up your data for large-scale disaster recovery — a rare scenario — but it doesn’t provide granular restore of your data, nor does it protect against accidental deletion of or breaking changes to your automations.

How much the data is worth to you, and the depth of backup you are comfortable with, only you can decide. But since we’re talking about things like automations, macros, and triggers — workflow controls that your entire support organization relies on every day — you deserve to make that decision based on factual information.

If you work in IT: When something goes wrong, you may suddenly be asked to recover lost data with a quick RTO (recovery time objective). If you aren’t able to do that, it puts you in the unpleasant position of having to explain why not, not to mention the business impact of not being able to restore the data the business needs.

If you work in Support: An accidental delete or breaking change in your automations, triggers, macros, or views can tie up your support workflow, thereby risking the smooth functioning of your service organization.

How Zendesk backs up your data
Technically, Zendesk does have features to make your data in their system more available. But these are designed for a specific, very broad, purpose.

All Zendesk data is automatically backed up regularly. Not to protect your account data specifically, but the entire platform in case of a . So Zendesk can recover all accounts if there was, for example, a platform-wide hacker attack, but they don’t promise to recover information for your account specifically if an incident were to occur.

This may not seem like much of a problem; after all, Zendesk hasn’t publicly reported any large losses of customer data. But there are some significant potential problems that can still bite you despite Zendesk’s automated backups.

5 costly problems Zendesk won’t protect you from

1. Somebody accidentally breaks your workflow
Automations are one of the key reasons why companies love Zendesk. But what happens when you lose automations due to a simple mistake? A lot.

Take a look at a typical example of Zendesk automations:

• All billing-related tickets are automatically routed to the finance team.
• If a ticket is left untouched for more than four hours, it is automatically escalated.

Now imagine the havoc caused by losing any of these automations. If you didn’t have these automated processes to begin with, your support system would be far less effective. But if you do have them, your entire support system will suffer if you suddenly lose access to them. You would need to quickly recreate everything, get the processes up and running, and hope the customer forgives you.

In this scenario, if you have a third-party backup tool in place, your automated daily backups of your Zendesk automations mean you can simply restore to a time before the automation was deleted. Search for your automation in the system, and with a few clicks, your automation is restored.

2. You can’t restore data at a granular level
As I mentioned earlier, Zendesk has a disaster recovery feature they use in extreme cases. It is designed to recover huge amounts of data in bulk.

If a disaster happens and Zendesk performs a disaster recovery, you get your data back in a big downloadable blob of CSV or XML data. Recovering a single, important ticket or customer interaction would force you to look for a needle in a massive haystack.

On the other hand, if your data is backed up in a third-party system, you simply “Search.” “Preview,” and “Restore.” That’s it. You find the needle right there, within a minute.

3. You lose all deleted data after 40 days
When you delete an item in Zendesk, it goes in the recycle bin. But it only stays there for 40 days, then it is gone forever. It is very simple, yet far too few Zendesk users realize the finality of this functionality.

You delete so many things every day. Usually, you never think of them again, but every now and then, the wrong item is deleted. Or circumstances change, so you realize you need it back. But forget it — after that just-less-than-six-week window, it’s gone.

Not so with your data backed up with a third party. Everything is still there. You leave your options open.

4. When an employee leaves your company, all her data is automatically archived
Now and then, you probably see support agents leave the company. This is a normal part of the business. As a matter of fact, companies worldwide face a among their support agents.

When the agent is no longer an active user in Zendesk, what happens to all their views, tickets, and other data associated with their account? If you still need access to it, you have three options:

• Continue to pay the fees for the person’s license after they leave. But with a license cost of $49 to $215 per agent per month, that will be an expensive option with a 30% turnover.
• As a best practice, Zendesk recommends you reassign the tickets and downgrade the agent’s account and finally suspend the account. Please keep in mind that downgrading the agent’s account will automatically delete all macros and views permanently. Losing out on macros and views permanently could be a costly mistake.
• When you back up the data with a third-party backup service, you continue to have access to all data. Your data is backed up daily, so you can simply go back to any point and restore or preview any data.

5. Zendesk’s enhanced disaster recovery is expensive
Zendesk will sell you an system that includes multi-zone data replication and a host of other features that help protect your data in event of a disaster. Please note that it is available only in enterprise plans ($215 per agent per month). Even worse, it doesn’t even protect your automations, triggers, macros, and views.

With a third-party backup you can save a lot of money for your organization and benefit from a comprehensive backup starting at a few dollars per agent per month.

A 60-second summary, with the Keepit glasses on
As I mentioned at the start, you will have to assess your risk tolerance if you conclude that suddenly losing your Zendesk data would be too costly, whether, through human error or malicious intent, the time to act is now. There are third-party solutions out there, so you just need to find the right one.

is one of them, designed for fast, easy recovery. And for your convenience, here are five quick benefits:

1. Protect automations — automations, macros, and triggers are the lifeblood of Zendesk, and with Keepit, you can also protect these.
2. Retain unlimited data — all your data is saved in four copies across multiple data centers.
3. Keep backup costs down — With Keepit for Zendesk, you benefit from a comprehensive backup solution with unlimited hot storage and data archiving starting from $2.95 per agent per month.
4. Keep it simple — with an easy interface, anyone can recover data with no training needed.
5. Recover fast — get your data back in seconds. Search-Preview-Restore, using smart search and granular restore.