Cloudwell Conversations: Becky Reyes on Automation, Adoption, and Why Business Processes Are Never Really Finished

Kelvin Helmholtz (KH): Can you share a little about your background and what brought you to Cloudwell?

Becky Reyes (BR): Interestingly enough, I actually worked at one of Cloudwell’s clients before I joined.

I was doing an internship while I was in school for my associate’s degree in application development. While I was there, I ran into a pretty complex issue with PowerShell.

My boss said he would get Cloudwell to come help with it, and that’s when I met Owen. We worked through the problem together, and after that he said Cloudwell wanted to hire me.

During that time, I finished my associate’s degree and went on to get my bachelor’s in application development. Now I work on a mix of projects, a lot of Dynamics and Power Platform work, plus some SharePoint migrations and other solutions.

I do a little bit of everything.

KH: You’ve worked with organizations that manage complex, process-heavy workflows. What’s something you’ve learned about how those processes evolve over time?

BR: I feel like these processes are kind of alive.

A client might think this is exactly how they want it to be. You implement the solution and show them, and it’s exactly how they described it. Then they realize something can be tweaked or that what they thought they wanted was actually a little different.

So, it’s never really A to Z. It’s more like a winding path.

What I’ve learned is you really have to question everything. Really question what the client wants as it can better help to develop the project’s requirements.

KH: When designing new systems, how important is it to match the solution to the user’s level of technical comfort?

BR: It’s important to learn how their existing processes work and how to improve them in a way that fits how they do their work.

For example, with one client we worked with, they wanted to move away from Excel. But they’re also not very technology-savvy.

So, we have to make sure the solutions we build for them are not too complex to use, even if they’re doing complex things behind the scenes.

It’s all about understanding their processes and also what tech they’re comfortable with using.

KH: A lot of teams rely on Excel because it works. From your experience, when does a spreadsheet-based process start becoming a risk instead of a solution?

BR: First and foremost, when it has sensitive information in it.

You’re not supposed to put sensitive information in Excel, but companies still do that. They think because it’s on their personal work machine it’s fine, but it’s not.

Another situation is when Excel starts holding a lot of data.

Excel can technically hold a lot of data, but that doesn’t mean you should put that much data in there. It gets hard to sort through and organize, and it gets really slow and clunky.

At that point it affects how effectively people can do their work.

KH: We often see workflows managed by one or two people who just know how everything works. From a governance and continuity perspective, how sustainable is that as organizations grow?

BR: It’s not sustainable.

Even if you have automated processes, if only one or two people know how everything works, that becomes a problem when the workload grows or if those people aren’t available.

If someone new has to step in, they still need the processes explained to them and how the automation works. Having an understanding of workflows not only allows individuals to effectively carry out their work without needing to take time from others but it also allows them to troubleshoot issues more efficiently if any were to arise.

It reminds me of situations with legacy technology where only one person knows how to use it. That person’s time is usually spent on maintaining the legacy solution and helping others complete their tasks instead of improving the solution or carrying out other needed tasks.

KH: You’ve invested time in building documentation, walkthrough videos, and user guides for clients. Why is enablement so important for long-term success?

BR: For one client, I created documentation with GIFs and walkthrough videos explaining how to use the solution we built.

The main goal was to avoid the constant back-and-forth emails asking how to do things, which wastes their time.

Instead, they can refer to the documentation and find the answer themselves.

I think documentation should really be done for all clients because these solutions aren’t one-and-done. They’re going to be using them to accommodate their ever-growing needs.

KH: Does documentation help you as well as the client?

BR: Yes, it’s really helpful for us.

If I leave and someone takes over the project, they can see the documentation and understand everything it does.

Sometimes I might not work on a project for a year and then the client comes back asking for improvements. When that happens, I can review the documentation and refresh myself before making changes.

KH: When helping a client move from manual to automated processes, how do you decide what to automate first?

BR: We usually decide based on their immediate needs.

For example, one client wanted to automate parts of their accreditation process because of their timeline. They needed to send letters and complete certain steps first, so those were the processes we prioritized.

Other times we start with simpler things to implement first, because automation builds up and can becomes more complex as you go.

KH: How much of successful modernization is about the technology itself versus user adoption and behavior change?

BR: I feel like it’s probably half and half, maybe even a little more on the adoption side.

We can implement the solution, but if people aren’t willing to change their behavior or learn how to use it, then the solution is kind of useless.

For example, with one client we built a solution that works off their database. The automation works, but if the data in the database isn’t kept up to date, for example letters might be addressed to the wrong person because the contact details aren’t current, then things stop working properly.

So even though the solution does everything it’s supposed to do, it falls short if the data isn’t maintained.

KH: Can you share an example of a recent project where improving adoption made a measurable difference for an organization?

BR: Right now I’m working on a project for an insurance organization.

Previously, they would get the quote document together, upload it to PandaDocs to send for a signature, review it again, and then put the information into Dynamics.

We’re updating that workflow so now they can just click a button.

The document gets generated automatically, it’s uploaded to PandaDocs, and all they have to do is review it and send it for the signature.

Once it’s signed, it comes back automatically into Dynamics and the quote that the customer chose is already uploaded there.

So, it removes a lot of manual steps and lets them focus more on selling insurance.

KH: You’re also working on SharePoint migrations. Are there any lessons organizations should keep in mind?

BR: One thing we’ve run into is issues with OneDrive sync after migrating to SharePoint.

If an organization tries to sync a folder with over 300,000 files through OneDrive Sync it causes problems with loading times or moving and renaming files.

One of the simplest solutions is to split large document libraries so they stay under that limit. That way users can sync the folders they actually need without running into those issues.

KH: For organizations that know their current process isn’t scalable but feel hesitant about making a change, what’s one practical first step you’d recommend?

BR: I think the first step is just looking at your current processes and thinking about where automation might fit in.

A lot of organizations have the mindset that if something works, they don’t want to change it.

But usually people wait until things start going wrong before they try to improve the process.

Looking at those processes earlier can help avoid bigger problems later.