By
Mendy Green
December 18, 2022
•
20 min read
Business
“Should my business be going to Cloud?”
This is one of the most popular questions that comes up in my conversations with clients, and like every other question I get, I like to answer it with “It depends”.
Before we can address this, we need to address the ongoing struggle between IT Professionals and Marketing Professionals. This was cleverly outlined in the classic Project Management meme
We won’t get too far into the specifics of this as Marketing can be a post all by itself, but suffice to say, the…let’s call it exuberance to sell something new, tends to make for overly aggressive messaging targeting the Stakeholders which does not generate tingly-friendly feelings on the people who actually have to implement, support, or answer questions about the technical specifics. This is true no matter if the “Expert” person is at your company or the company the marketing person is sitting at. If you need a further demonstration of what this looks like you can watch the skit on YouTube called “The Expert” which should give you an idea of what frame of mind to approach this question with
Keeping this in mind we need to immediately increase our level of skepticism when we hear about Cloud Computing (or really any new technology).
Let’s switch tracks for a moment. One of the things I always talk about is how there’s at least two sides to everything. Literally you can take a specific item, scenario, concept, etc. examine it and you’ll see two or more sides that reflect or are directly opposite to each other. In business finances for example we have Operating costs and Cost of Goods Sold (COGS). Traditionally Operating costs were made up of things like Rent for the office, Utilities, supplies and things like that. Supplies would include the cost of equipment (such as computers) Utilities would include cost of the internet and so on. COGS would be made up of how much money the business would need to spend, in order to provide the service that they offer. This is essentially two sides to the same thing (money being spent), but you track them separately because they help you break down the cost of running the business vs the cost of providing services.
In other words, Operating Expenses can be broken down to the point where you would assign a Per Dollar amount for each Employee that you have, and COGS would be broken down and assigned a Per Dollar amount for each Customer
Now let’s get back to the point of this. Cloud, like everything else, has 2 or more (way more actually) sides. There’s Infrastructure as a Service offerings, Platform as a Service, Software as a Service, and so on and so forth and all of these items get mixed up and placed into the “Cloud” category. If you dig into what Cloud actually is, you’ll find that it’s just…rented computers. Really. If you’re skeptical, you can read more on this here from one of the bigger software platforms on their reasons why they’re leaving the cloud.
The questions we’d want to answer so that we can determine if you should be moving to the cloud are as follows.
Would you be moving your Operating Expenses to the cloud or your COGS. Specifically, are you providing an online service to your clients that requires you to rapidly scale up if you were to grow, or that allows you to measure out the cost of running in the cloud against the number of users you’re servicing?
Running in almost any cloud has pricing that is broken down to the minute, generally speaking. This is one of the big things marketing likes to tout “Scale up or down as needed, so it’s very cost effective”. Cost effective compared to running them 24/7 sure, but not cost effective compared to buying hardware. Marketing is selling you on the idea that if you needed to turn down services, you can do rapidly and save money with it off, but if you never need to turn down services, and your scaling doesn’t happen rapidly, then you’re actually spending way more over the same period of time of hardware life. Up to 4 or 5 times the amount potentially.
Do you have a need either from a compliance standard or your own security policy for enhanced security, physical auditing, a requirement to be highly available or a guaranteed uptime of 4 or more 9s (99.99%)?
Here is where it starts making sense to consider, although the question of finding a datacenter that will rent you hardware or allow you to place hardware vs running in something like Google Cloud, Azure, or AWS is still debatable. In the end the level of redundancies that exist in the cloud or datacenter are harder to build (read, more costly) than using an infrastructure that is already built and essentially being shared. This isn’t a new phenomenon, if you’ve read my article on the MSP Business Fallacy, or even just paid attention in the world the idea of pooling resources to save on costs is a well-established and very successful pattern. This is something that can range on a spectrum from sharing power costs, to sharing full on hardware and running your services on segregated containerized workloads.
Are you concerned about control of your data. Specifically, does it matter to you if your data is physically on equipment that you solely own and control, or is your business okay with the data being placed onto equipment owned and controlled by a trusted Third Party
Data sovereignty is an important part of the equation, even if you do trust it to a third party, the question of which region and where it is physically located is still an issue. In the end the agreements you sign with vendors and clients state that the data you hold for them is your responsibility to protect and keep safe and you do not have the right to assign that responsibility to anyone else. These are all concerns that should be evaluated and addressed in your assessment of moving to cloud.
In the end there’s no real good right answer, as most of these questions are ones you’ll need to decide for your business. I’ve outlined a table below to help with the decision matrix, but it is still only just a suggestion.
Have you implemented unique colors for your Ticket Statuses in HaloPSA?
Coloring these Statuses adds a great Quality of Life to your Agents working tickets. Often, it is treated as a nice-to-have or “let’s just make it look pretty,” which are fine if it works for you. However, we invite you to imagine instead with us: what if you could leverage symbolic colors that guide an Agent through your defined ticket process. What if you could implement that in a reasonable way?
So, to help lessen that decision fatigue for you since we know you’re busy customizing every other setting in HaloPSA as well, here is the framework that Rising Tide uses to approach customizing these settings to help you quickly and sensibly label your Ticket Statuses. In a future article, we’ll tackle Ticket Action color codes; however, the concepts will generally remain the same.
Before we jump into coloring statuses, let’s start by defining a ticket’s lifecycle according to how your Agents need to allocate their attention to those tickets, whether that is dictated by standard professionalism or ensuring SLAs are kept. For the sake of this conversation, we are going to address these ticket attention phases with the segments: Normal Attention, Elevated Attention, or Inert Attention.
Ideally, your Agents receive a ticket and all things are “Go,” they have everything they need to start working, and then Close the ticket when they've successfully completed the task and can rest on their laurels (or move on to the next ticket!).
We recommend all Normal Attention tickets to be assigned “cool colors” like greens, blues, and purples. (And not cool because we think they’re rad, cool as opposed to warm colors, more information here on color theory) Statuses like New and In Progress generally belong here. We have the ticket, everything is going as planned. What a perfect, serene world. Peaceful, isn’t it?
Unfortunately, that’s not the reality in most of our businesses! What happens when tickets require extra attention or action to ensure their timely completion?
Here in Elevated Attention is where we see statuses like Escalated, Pending Approval, or Reopened: tickets that we need to be actively thinking about and revisiting, especially ones that are keeping our SLA clock running. To inspire action and increase visibility, we’re using warm, fiery colors like Orange, Red, and Yellow.
What if there is a ticket where we cannot take immediate action, or it doesn’t warrant it? That’s our last category: Inert Attention.
There will be times when our tickets are active but there is literally nothing we can do but wait. The SLA clock isn’t running, so we don’t need to worry about taking action on these just yet: statuses like Waiting on Client or Waiting on Vendor. We recommend using greys to signify these statuses’ inactive character.
In general, we recommend you set up HaloPSA to do most of the status setting and remembering to move tasks in and out of statuses, especially Inert-type statuses. Specifically, when setting up these Inert Attention statuses in HaloPSA, be sure to build those Ticket Statuses, Ticket Type Settings, and your related Workflows so when a ticket enters or exits an Inert status, it automatically puts the ticket on or removes it from SLA hold. You can see examples of these settings in the screen captures below.
Some examples of this recommendation in action could be:
With all of these ideas in mind, we suggest as you approach customizing each ticket status, you ask:
What type of Attention do I expect of my team at this status: Normal, Elevated, or Inert?
When you have that answer, choose a color from the suggested family. Remember that color for other statuses you may have for other Ticket Types so it stays consistent regardless of what Area your Agent is operating from!
Here are some examples for what we specifically recommend to Rising Tide Customers. You will likely not need all of them, depending on your MSP’s needs:
As with most rules, there are going to be times when items cross between phases, or you may operate differently and not define a ticket status the same way we did here.
Maybe you have some color-blind technicians on staff and decide to use completely different colors completely or none at all. (If you do want to create a color-blind friendly palette, here’s a great resource.)
Maybe you want to choose different values (light or dark) within a certain family than what Halo provides.
Good! Break our rules. They're just here to help you decide what you do or don't actually want.
Our main recommendation is that you use your best judgement on what is right for your team and just be consistent which sometimes means keeping it simple. And let us know what you ended up doing, you may help someone else. Happy customizing!
Over the years of training and assisting various technicians, I've formed a set of guidelines that I've been known to drill constantly. The other day while talking to a newer technician and working with them I realized that I now have the time I didn't have before to actually write down what I've been ranting about for 14 years. I've dubbed them as the Laws for the Practical Technician.
There's a lot of nuance in each "law" so now that we got the TLDR version out of the way let's dive into the specifics. Note for the purposes of this post, each law has been given a title.
If you run around with your eyes closed expecting nothing to get in your way, you're bound to smack into a wall (or something) and fall down. If you keep your eyes open and aware of your surroundings you can navigate the obstacles and overcome them.
End users typically expect systems to work seamlessly and view issues as problems needing external help. Technicians, on the other hand, approach systems with the expectation that things might not work and are prepared to "figure it out" each time.
Key Points:
Example: When dealing with a software bug, an end user might see it as "broken" and wait for a fix. A technician, however, will explore various angles—checking logs, considering recent changes, and testing different scenarios to identify the root cause, or find a viable workaround
Computers and software are designed to be used, (it's actually the only way they make money!). Therefore, the information needed to operate or troubleshoot them is generally available on the screen or in logs, (although the language can be context-specific for the industry). To effectively identify and solve issues, it's crucial to explore the interface and ask questions. Thoroughly reading on-screen messages and prompts can provide insights into what might be wrong and how to address it.
When encountering an error message or unexpected behavior, don’t rush to conclusions, AND DO NOT SKIP IT!
Instead, read all the details provided. Error codes, system messages, and even seemingly minor details can offer significant clues. For instance, a message that seems obscure at first glance might make sense when considered within the context of the application or system you're working on. Even comparing against a computer that is working, looking for differences in behavior, or order of operations, screen activity, and so on, can provide clues (for example an error that takes a while to appear is likely caused by a timeout, vs an error that appears immediately is likely caused by an immediate rejection).
Example: If a user reports an issue with a software application crashing, instead of just noting "application crashes," you should read any error messages, logs, or system prompts that appear when the crash occurs. These details can guide you towards understanding the root cause and potential fixes.
To effectively troubleshoot, ensure you can recreate the problem and understand its significance. Start by asking the person reporting the issue why it's a problem and why it's important to solve it. Gather as much information as possible to understand all sides of the issue. You should be able to understand the problem at least as well as the person reporting it to you, otherwise how do you expect to fix it? Or even explain it to the next escalation point if you have to reach out for help?
Here are some ways you can work to understand the problem.
Example: If a user cannot access a shared network drive, ask them about any recent changes to their system, any specific error messages they receive, and how critical this access is to their work. Look at what the shared drive is mapped to, and if other people have access to it that are working. Identify the network the user who is complaining about is on and if it has connectivity to the shared drive host. This comprehensive understanding allows you to troubleshoot more effectively and escalate if needed.
Being intentional in your actions means making deliberate, thoughtful decisions rather than taking random stabs at fixing an issue. This approach prevents exacerbating the problem and leads to more efficient troubleshooting. Most technicians below Tier 3 will perform troubleshooting by way of "trying different thing to see what works", this is essentially closing your eyes and trying to pin the tail on the donkey, make sure you understand what is going on, and the logical reason why what you're attempting will affect (either negatively or positively) the current outcome so that you can make progress with every step.
Expand on This:
Example: If a printer isn’t working, don’t randomly try different fixes like restarting the printer, reinstalling drivers, or changing settings. Instead, follow a logical sequence—check for error messages to help point you towards a connection issue or a driver issue.
Always be prepared to reassess what you know. Technology and systems evolve, and what was true yesterday might not hold today. Keeping an open mind and questioning assumptions can lead to discovering the true cause of an issue.
Expand on This:
Example: If a network issue arises, don’t assume it’s due to the same cause as last time. Reevaluate the situation - start the troubleshooting process from scratch everytime until you've identified the root cause to the be the same as last time.
Always have a contingency plan before making changes. Ensure that any action you take can be reversed if it doesn’t resolve the issue or causes new problems.
Expand on This:
Example: Before modifying a system registry, backup the registry or export the key in question. Rename something instead of deleting it, or cut/paste it somewhere else. This way, if the change has unintended consequences, you can easily revert to the previous state.
In any business where you’re not billing Time and Materials, the amount of time you spend on a project directly correlates to how profitable you are. In an MSP, this applies even more. MSP Businesses were designed years ahead of their time, bringing into practice concepts such as recurring revenue, outsourcing, efficient resources, and more; before people even realized the value. It’s the reason that today the MSP Businesses are blowing up with everyone you meet starting their own. Unfortunately, there’s a complex side to the framework of an MSP that is very often overlooked, especially by those just starting out.
Let’s discuss how the MSP business model is built. MSPs pitch to their prospective clients that they can provide the same level (or often times better) IT Services to their organization than they themselves can find if they go with someone internally. They ask for less money, and offer a bigger team with greater experience. These same MSPs then have to turn around and hire the same people that would have been hired directly, and not just one, but two or three or more depending on the size of the MSP.
MSPs have to pay the same salary with a smaller budget. How can these numbers possibly work?
This is where efficient resources come in; an MSP needs to stack multiple clients reusing the same resources for each client so that together all the clients combined pay enough money for the MSP to pay the technicians salary and make a profit. The income also needs to cover all base expenses of the MSP which includes infrastructure such as an RMM, PSA, Email, Phones, over-night team for emergencies and so on.
With an internal IT resource, that resource would be solely focused on the business they were working for and getting paid a full salary of say $52k/year, now the same resource at an MSP is getting paid $52k/year and needs to stay on top of not one company IT needs, but actually 3 or 4 (or more depending on the contract size of each). This kind of expectation is unreasonable and when maintained results in high-stress work environments and eventual burn out for the technician. The saying “trial by fire” is very applicable to the technicians who work at an MSP. They are under constant barrage of tickets and stress, jumping from company to company each ticket wildly different from the next. This makes them unusually skilled and also rapidly exposes them to a wide range of experience they may not have received working for just one company. A good MSP technician of the lowest tier can easily go head to head in ability (if not knowledge) to a mid-tier internal IT resource.
Now keep in mind that when MSPs started we were a new phenomenon. There was no standard to follow, no existing business to copy, except for the existing internal IT department within a Company. We didn’t know what kind of pay structure was fair to offer a Tier 1 or Tier 2 technician because there was no “average pay” metric. The only thing we did know is that we are building a business with a stress on smaller dollar amounts per client, and more total clients. This means what we paid our technicians had to be less too, or that we keep the MSP as lean as possible with only the amount of technicians truly needed. Following the 80/20 rule we determined that 80% of the time with our clients running smoothly we would be fine and only 20% of the time when some kind “perfect storm” would occur we would need to motivate our technicians to put in more effort (or what was generally called “figure something out”).
What’s being described is not a sustainable long term plan. Simon Sinek likes to stress that business is an Infinite Game and that those who are not playing by those rules are doomed to failure eventually. The only way to stay in the game is by having resources, and the will to keep playing. We’ve already established that MSPs do not have the same pockets as a normal business, not without drastically imposing upon “will”, our employees, making them work in stressful environments and constantly being battered by the next broken issue.
The fix for this is easy, and its an iteration of what we already started. Efficient use of resources. Efficiency can help us spend less time per ticket, less time per client, and improve our technicians stress in the environment. There are two side to the efficient use of resources, one of which we already started (Sharing resources among companies) but the other is often overlooked “Work load management”. If we can make our work load efficient we can easily improve upon all the issues we just brought up. Here are some ideas that can be used to help facilitate the efficient workload.
Efficient resources is way more than just sharing resources. Making your workload efficient is just as important. Remember how profitable you are directly correlates to how efficient you can be
Remember, in the MSP business time isn’t a loss of potential profit, its actual profit lost as your contracted rate is the same every month. Automation and bulk actions are extremely important as the less time you spend doing something the more your Per Hour amount goes up.