You might also like
Did you know that by 2020, Medicare is projected to [...]
The reinstatement of the OEP (discussed in our last [...]
Blog for us
We're always on the lookout for guest bloggers. Submit your email below and we'll set you up.
Recruiting developers, especially good ones, is not an easy feat these days. There are so many options for developers in the marketplace. If you’re a smaller organization that doesn’t necessarily have a strong brand, it becomes somewhat challenging to recruit. Sometimes it may feel like you’re fishing for an endangered species.
You’ll cast your net and post the job through various online and offline outlets. You’ll sift through resumes with the hope that your net was cast wide enough to snag some good candidates. Given some good candidates are present, interviews will follow. Once you’ve identified some potential candidates that fit your organization, you’ll make them an offer.
If all goes well, the elusive developer will be caught. Once they join your organization, time will pass and they will develop solutions for your customers. Over time, if not right away, your customers will require some support.
In a large organization this may be handled by multiple levels of support teams and varying support strategies. But what if you’re a smaller organization with a small support team or a large organization trying reducing support overhead? It’s inevitable that your developers will get pulled into support issues, but without providing your support team with the proper tools, your developers may start acting more and more like support staff, and doing less development. Projects may slowly start to fall behind schedule or developers may feel overworked and frustrated.
Unfortunately, there’s no silver bullet to solve this. However, there are various solutions that can be utilized depending on your circumstance. The end objective is to provide the support teams with tools that provide visibility into your solutions to identify and solve issues without getting developers involved. Of course there will still be times when developers need to assist, but this should be the exception and not the norm.
Before we dive too deep into this, let’s quickly take a step back and look at some of the software solutions that can be provided to customers. Today’s marketplace really has two main types of solutions; Software as a Service (“SaaS”) and On-premise Software. You could also have a combination of these to provide a hybrid model. For this article, we’ll focus on supporting SaaS solutions.
There are typically a couple classes of support issues that can arise. A support issue can arise if a customer doesn’t know how to complete a specific task or if something is not working as expected. The former of these two should be exclusively handled by your support staff. On the other hand, the later can possibly be handled by your support staff, but if it relates to data or processes that aren’t transparent, then what? This could mean a backend process isn’t working correctly or that data on the backend is incorrect or in a state that’s causing issues. This is where support tools that enhance visibility really excel.
Depending on your specific SaaS solution, there may already be tools out there that can provide the level of visibility required for support staff to be more self-sufficient. However, if your solution is primarily built in-house, or if your solution has significantly customized off-the-shelf components, a more tailored set of support tools may be necessary.
The support tools should be comprised of an easy to use interface and allow support teams to get to the information they need quickly. Sounds easy, right? Not necessarily. The key to developing effective support tools is to understand how your solution is leveraged by your customers and how it impacts their business. The goal here is to expose data and processes in a way that is easy for support staff to consume. We’ve found a combination of dashboards, on-demand reports and search capabilities that allow your support team to utilize data in a meaningful way works best. Access limitations may need to be in place, especially if the support staff can modify data on-the-fly.
Developers should not only develop the solution for your customers, but they should also develop the tools that are required by the support team, especially when dealing with SaaS solutions. Yes, this does increase the scope and cost of the project, but it will pay huge dividends to your organization in the long run. Keep in mind that this is not a onetime project and the support tools will continue to grow and transform over time just as your customers do.
Not only will these tools provide your organization with happy developers who aren’t acting as support staff all the time, but these tools will also assist your organization with troubleshooting issues during development and testing. You’ll also have a better equipped support staff that can be leaner and quicker to respond to support issues. This will inevitably result in happier customers, which is the most important thing of all.