It’s been a few months since we last touched base on the process of adding a new tech toy to the agency (read my first article here). Our homework assignment was to evaluate our current processes to determine if/how the new tech will enhance them. What have we found?
Evaluating a process usually takes me about 2-3 months. During that period, I like to thoroughly comb through the process the new toy will be enhancing from A to Z: A being what happens at the beginning of the process or its “trigger,” and Z being what the outcome is and how I as the agency owner determine that it’s working. It’s critical for the process to end with reportable data, allowing you to show your team that this new item you may have thrown on their plate to adapt to is bringing more value to the agency.
We have accountability for ourselves and our team. It’s important to have accountability for our processes.
Accountability for Processes
I’ll use an example of one we have that I know we need to improve on. Where it falls short is at the very end. A retention process of ours ends with a touchpoint determining what action the agency is taking next. This REQUIRES a manual note by a team member. Unfortunately, sometimes this suspense is simply just “closed” without a note.
How does one determine the outcome of the process? What decision was made? “If it’s not in Hawksoft, It DIDN’T Happen” – these are the words my agency sees when we log into our dashboard. It’s a daily reminder that our hub needs to have the utmost accurate and valuable information pertaining to our clients and the processes we deploy. If the end of the process wasn’t documented, was it successful? No.
Nothing wastes more time than tracking down what happened in an incomplete process. For small teams it may be as easy as saying, “Hey Mary, did you talk to Mark about his renewal? Are they staying put or are we rewriting them over to X?” On larger teams it’s much harder, as team members could be split between offices or even on different work schedules. Maintaining accountability in the process is of the utmost importance to determine its outcome. The same goes for the 3rd party tech you’ve added. You should easily be able to view what was done.
Two Buckets for Process Changes
As you’re evaluating and updating your process because of your new tech, the needed changes will generally fall into one of two buckets: current processes that now need to be changed due to the added tech, and new processes that need to be developed and deployed because a gap was discovered in a current process.
Bucket A: Updates due to new tech
This should be the easier one of the two, if you’re lucky enough to be one of the few that had a solid process created from the start. You should be able to add your supportive tech into the process without much change. If you uncovered some gaps in this process, put them in bucket B to start rebuilding from the beginning. Whatever you do, don’t just slap your new tech on top of inadequate processes and call it a day. You’ll thank me later. Take your time.
Bucket B: Updates due to process gaps
Bucket B comes into play when you’ve already touched Bucket A and have found that within that process a gap or need was discovered that requires its own additional supporting process. I’ve learned the hard way that processes from Bucket B should always be rolled out along with the processes from Bucket A. This will ease the learning curve for your team. I’ve done this separately in the past, but it’s clunky and never results in the desired effect because too much time has passed between the corresponding processes, frustrating both me and my team. Your processes are part of your ecosystem. Makes sure it makes sense and is easy to understand.
Don’t get discouraged if you become frustrated while working on your two buckets. Take a step back and reassess frequently.
That’s all for now. Check back in for Part 3 when we go over how the changes are going and tips on how to track if they have been successful.
Chief Operating Officer – Handzel & Associates Ltd.