Do you run a business? Are you a manager or a supervisor? If you've ever struggled to hand off tasks to the people under you, whether they work for your business or report to you on a team, this one is for you.
The thing that makes delegation work has a name. It's called a business process. And in this post, I'm going to walk you through four different ways to build one, even if you're starting from absolutely nothing.
But before the four ways, let me tell you how I learned this the hard way.
The SOP That Took Me a Whole Month to Write
I've been a virtual assistant for almost five years now, working in systems and software. I've also been an employee many times over, both for local and foreign companies, though most of them were US-based. I'm Gen Z, and if you look at my resume, you'll see a lot of companies on it. Some were contractual. Some closed down. Some I resigned from. One let me go because of cost-cutting. But so far, I've never been terminated for doing something wrong.
Because I've moved through so many companies, I've had to train a lot of people. Before I leave, I train my replacement. That's usually a requirement when you render your notice. So I've had a lot of practice delegating tasks, whether I wanted it or not.
One of my most solid experiences in building a process happened when I worked as an accounts payable specialist in Davao City for a US transportation company, a trucking brokerage. My job was to record expenses and payables for our suppliers and truckers.
About five months in, once I had gotten the hang of the job and was honestly enjoying it, my team leader told me something I didn't expect. Part of my job description, it turns out, was to write an SOP for my processes. His reasoning was simple: if I ever left or went on leave, the team needed a backup document of everything I did.
I had almost no experience documenting my own work at that point. So I asked my coworkers for help. "Guys, TL asked me to make an SOP for my processes. Can I see yours? I don't really know how to do this."
The tenured ones handed me their SOPs, and most of them were outdated. Not because nobody cared, but because nobody was ever given the time to update them. They also gave me a template, and I was shocked at how long it was. A full SOP is one big document covering the description of the role, every step, the order of those steps, how to troubleshoot, and how to solve every possible problem. Everything laid out. I was overwhelmed just looking at it.
I was given one month to finish it. It wasn't urgent. The only requirement was that I submit something within that month so it could be reviewed.
So I built it bit by bit while doing my actual work. I never wrote a step I wasn't presently doing. For example, if that day I was receiving invoices and responding to suppliers who sent their billing, I would convert what I was doing into words as I did it, typing each step into a templated Word document. I took screenshots along the way, because an SOP needs visuals for the reader to actually understand it.
It took forever. I was so busy, and the process was painfully slow because I didn't know there were easier ways to do it. Mine was completely manual. Screenshot here, type there, type there again. It even had scenario-based sections. I'll be honest, I was irritated the whole time I was making it. My only goal was to submit it within the month because our supervisor needed it.
Eventually, I submitted it. I had my SOP.
The Mistake That Came Back to Haunt Me
Here's where it got interesting. Because I could now do my job quickly, I had a lot of idle time. So every month or every quarter, I kept adding to my scope. More tasks, more responsibilities.
And I never updated my SOP.
Not until I decided to leave the company. By then, my scope had grown so wide over the course of a year that I had a mountain of documentation to catch up on. I had to update everything so I could train my replacement on all of it. And I did. I knew my SOP was very detailed by the time I finished.
When my replacement arrived, my first instruction was simple: "You don't have to do anything else today. Just read the SOP I'm sending you."
That was the plan for the first few days, especially since it took a while for them to get system access. While I worked, I would talk to them and let them review the SOP. When I had free time, I explained the business model of the company and how I did my job. Because the SOP covered every scenario, they could see exactly what to do in each situation, and the handover didn't feel too heavy on my end.
But here's what I learned while actually delegating the work. I didn't dump everything on them at once. I'd pick one specific task and say, "This task, we're doing it today. You do it. And if you have questions about this specific task, ask me."
Training someone, or delegating a task, works best when you do it little by little and you let them make mistakes. That's exactly how I learned. Someone let me make mistakes and gave me tasks gradually. If you hand over the entire SOP and the entire scope on day one, the person will be overwhelmed. It might have worked for me at first, but it's a very heavy way to train someone.
So I told my replacement: don't be afraid to make mistakes. Almost everything is reversible. Almost everything can be fixed. Just learn, and enjoy the training.
I know it was still hard for them, and that was partly my fault. My scope had become so wide that the person after me had to absorb all of it. But I'm confident I delegated it the right way.
That approach followed me to the next companies. I installed software for different businesses, trained their people, and kept practicing delegation the same way: little by little, never rushing, until one person could handle a complete process on their own. Eventually, delegating just became natural for me.
I used to think delegating was difficult. It turns out there's just a right approach to it. What really slows you down is not knowing how to build the process in the first place, doing it all manually with no idea where to start.
So let's talk about that.
Step Zero: Just Delegate
Before the four ways, there's a step zero. It isn't one of the four, but it comes before everything else.
Just delegate.
I learned this when I started my delivery business. You have to first make the decision to delegate the work, because you can't do everything alone.
Once you decide that someday you'll hand this work to someone else, you'll force yourself to understand the entire process. You'll force yourself to document it so you know how to pass it on in the future.
Many business owners I've met don't have this concept at all. What they do is "just delegate" in the loosest sense. No formal process, no formal documentation. Just, "Here, watch this. Do this. Do that." And honestly, that's fine as a start. It doesn't have to be perfect. You just have to make the decision and get used to the idea that you need to delegate.
For me, once you've decided to delegate, building the process becomes much easier. The hardest part is deciding whether you'll delegate at all. A business process makes no sense if, in the first place, you don't want to hand work to other people.
So don't overthink it. If you have the money, delegate. If you have the resources, delegate. Hand off the work that's making things harder for you, so your own process as the owner becomes easier. The process will follow.
Way 1: Consolidate End of Day Reports
In every corporate setting I've worked in, as an employee and as a VA, especially in agencies, the end of day report never disappears. From rank and file to supervisors to managers, everyone does it.
Every employee has to tell the story of what they did that day. They count what they processed, the sales they closed, whatever needs to be counted. They share the problems they ran into, how they solved them, and what they did overall. Before they log out, before they leave the office, before the day ends, they submit an end of day report.
But it shouldn't stop at submission. Whoever the manager is, or the owner if you're managing directly, has to consolidate those reports. Why? Because that becomes one of your foundations for building a process. Every department will have its own end of day report format, because every department has its own procedures.
Take a B2B salesperson, for example. Their report includes their name, time in, time out, and the story of the day: "Today I reached out to five clients. Two agreed to meet, and we had coffee at Starbucks. I closed one deal worth a million, and here's how I closed it: the client trusted that we could deliver the quality they wanted. I also met other clients who requested quotations worth a total of five million. I followed up on pending quotations that might get approved, went to the office, recorded what needed recording, and submitted the documents. The problem I ran into today was clients not showing up to meetings."
It's just a story. But when you, as the owner, read those reports and consolidate them over a week or a month, that's already a process. You can hand it to ChatGPT and have it formalize a step-by-step guide for what a salesperson does. Because whatever your employee does in their day-to-day routine is already a process. It doesn't need to be perfect. What matters is that it's documented.
Every employee should be doing end of day reports, regardless of department: operations, sales, marketing, HR, accounting, IT. This is the foundation of a business process.
The four ways I'm sharing are for businesses with no business process yet, the ones starting from scratch. Consolidate the end of day reports, then simply formalize the structure of what people do every day.
Way 2: Observation
The second way is observation. You don't ask anyone anything. You just watch.
Go to the production floor. Or monitor through CCTV. Watch your people walk through the gate, scan their fingerprint, log in, whatever your process is. Watch them lay out their tools where they belong, clean what needs cleaning, open the office or the shop, do inventory, man the cashier, whatever their daily routine is. Just observe. That's already a process.
Write it down wherever you can, then note what could be improved and what could be added to their routine. That's a business process.
Observation matters because some things never make it into an end of day report, and you'll only catch them in real time. It works like a gap indicator, showing you the difference between what's in the report and what actually happens.
This is where you start asking the right questions. Is this really what this person does every day? What should be improved? Do they have a lot of free time? What tasks could I add to maximize their hours? Keep documenting. And once it's documented, implement it with them.
Way 3: Employee Interviews
The third way is one of the most underrated: employee interviews.
Picture this. You used to be an employee, and now you're the boss with your own staff. Whether we admit it or not, once you've been away from operations for a while, you lose touch with it.
There will come a point where your employees, because they're so immersed in operations, encounter problems you never faced back when you were the one doing the work. They will know more than you. You might understand when they explain it, but as time goes on, whoever is deeper in operations will know it better than the owner who isn't exposed to it anymore. The problems they've solved, the problems they've faced, and how they solved them, especially new problems you've never had the chance to teach them about because they didn't exist before.
That's where employee interviews come in. Their answers become your process. Ask them: What new challenges did you face this week? How did you handle them? Did you solve them or not? If not, why, and what help do you need? If you did, what did you do?
Asking the right questions matters, because many employees aren't great at putting their thoughts into words. The right question gets you the right answer.
I'd suggest doing this monthly so the information stays fresh.
Way 4: The Corporate Diary
The fourth way is an old-school method. Has anyone here experienced keeping a corporate diary?
Personally, I haven't. But I'm studying now, and one of our subjects is microfinance. A microfinance institution is like a mini bank. You can borrow, open an account, withdraw, deposit, get insurance, and so on.
Most of the people teaching us were once account officers at microfinance institutions. They were deep in operations, out in the field collecting payments and handling large amounts of cash. One thing they used to do was keep a corporate diary.
That diary was submitted to executives or managers on a set cycle, maybe weekly. It documented what they did within the week and within each day, so the higher-ups had a basis for what to improve, what to add to the process, and what to remove to make it more refined.
It's similar to an end of day report, but a diary is the most detailed of all. An end of day report is just a report. Observation is just your observation. A diary goes deeper.
It's also a great solution for people who are rarely in the office and always out in the field. How do you get reports from them? Use a diary, or better yet, a cloud-based diary they can access anywhere as long as they have internet.
You Don't Need All Four
Once you have these, whether it's consolidated end of day reports, observations, employee interviews, or diaries, you can build a business process. And you don't need all four. Even one or two is enough.
You could pair observation with employee interviews. End of day reports with observation. Diaries with end of day reports. Or just one of them on its own.
And building a business process is much easier today because you can use AI. Even handwritten notes can be understood by AI. Even if your handwriting is terrible, AI will still figure it out. What matters is that you have basic data and you consolidate it: what your people did today, what you observed, their answers to your interviews, and their diaries.
It doesn't have to be perfect. What matters is that it exists. Because once it exists, you can slowly formalize it into what we call an SOP.
Why a Business Process Is More Than Just Delegation
Once you've formalized it, if someone resigns or goes on leave, their coworkers already know what to do, because there's a document to follow. Their replacement knows exactly what to do too.
But that's not the only use of a business process. It also becomes your criteria for evaluating employees.
Once you have a business process, both the employee and the manager hold the same document. During monthly evaluations, or six-month reviews, the KPIs are based on that employee's process. The manager checks whether the employee is actually following it. Not doing it? Minus points. Doing it? Points. That's how they get graded, and that's how you determine whether someone is effective or not.
So a business process isn't just about delegating tasks. It's how you find out whether an employee is still fulfilling what the organization needs from them. It becomes the basis and criteria.
If they're not doing the work, you let them go. If you can't bring yourself to let them go, train them so they improve. And if it still doesn't work, then you terminate. It's that basic.
Now ask yourself: why is it so hard for you to let someone go right now? One likely reason is that you haven't documented the actual business process. As the owner, you don't know how to evaluate your employee because you have no basis. No criteria.
In auditing, our criteria might be the company's internal process or an ISO standard. Neither one is wrong. Using ISO is fine. Using your internal process is fine. Using both together is fine. But once you have an internal business process, it becomes incredibly easy to see whether an employee is doing their job or not. Believe me. Proving whether someone is performing becomes simple once you have this.
Without it, what happens when you confront someone? "That's not in our process." "We never agreed that was my job." "Why did you think I'd do that?" Checkmate. And if you fire them anyway? "What's your basis? Why did you let me go? Where's the criteria proving I wasn't doing my job?" Checkmate again.
Small Part, Big Foundation
A business process is a tiny element of a department or of the whole business. But it's still part of the business, and it becomes the criteria.
Think of it from the top down. At the very top is the company's constitution or policy. Below that come the system, the procedure, and the process. The business process is the smallest part of a business.
But it's one of the most important, because it's the most fundamental. It becomes your basis. It shapes the verdict you make about your employees.
So let me leave you with a question. If there's an employee you're thinking of letting go right now, what is your proof that they aren't doing their job?
Answer that for yourself.
If you can answer it, congratulations. You probably already have a business process.
If you want help building business systems, customizing business software, or training your team, I'd love to work with you.
To know more about my services, writings -- connect with me here --- here's my website: https://www.kylenelsonomac.com/
Faith without action is Fiction.