Toolset Creation for Triage / Support

While customers themselves have an application engineered to show them the data they need, often times support personnel need expanded views of this data created so they can look for problems and issues. In some companies this toolset is a standard part of software, and in others its more of an afterthought. If you are in a small to medium sized software company, it can often be the latter. What can you do to get the data correctly visualized for your support teams to be able to do their job?

Pick your battle: do you need an official product solution for support toolset or can you suffice with homegrown data visualization tools?

Map out Use Cases

---

If you have applications to manage which do not have supporting toolsets created along with them, start by mapping out use cases your support people need to do their jobs outside of the application.

• Additional data. There are oftentimes fields in the database not shown to end users for legitimate reasons. It can be helpful to see the values of these fields as support personnel to know when data is incorrect or corrupt. Document these fields.

• Bypassing actions. There are validations in the user interface preventing users from doing things they should not. However in some support cases it is appropriate to override or bypass these validations to be able to fix customer issues.

• Account setup. Depending on your business model customers may be able to self service onboard themselves, or you may have legal requirements to perform before they are allowed into your system. How much of this is done inside of the software or outside?

In an ideal world, this exercise should be done while the application is being planned and architected. As much as possible of this should be incorporated into the application itself. If this was not done, try to inject yourself into early planning so this can be the new norm in the future.

Tooling Options

---

Now that you have gone through the exercise of mapping out what your support users need to do, lets decide what the right step is going forward. How much of these tools could you embed into your product? Here are some options:

• Hidden fields for support. Add "layers" to your existing applications where hidden fields are shown to support personnel when logging in to give them the visibility they need to see these extra data points.

• Hidden actions for support. Can you add extra buttons visible only to support personnel inside of the existing application? These would bypass user validations inside of your application where they can perform the needed support actions.

• Customer based setup and data entry. How much data entry can you front load on the customer for setting up their own account? What other touch points are needed internally to complete this setup that can be streamlined?

• Product lifespan. How long will this product be alive and what are its future roadmap plans? If the application will be around for years to come its wise to invest in some proper support tooling.

• Custom separate support application. As a last resort you can always develop a separate application for your support personnel which gives them all of the custom functionality they need to be able to perform their jobs.

When Needed: Create Yourself

---

When you need to visualize data fast for support personnel to be able to see issues, this is something which can be done relatively painlessly if a productized option is not available.

Out of the box data visualization tools. There are plenty of these out there from old school SSIS to open source industry standards such as Metabase and Redash. These allow you to display data from the database just with some queries and assemble into a dashboard.

Just be careful with these alternatives as they can be slippery and quickly become the new accepted standard norm. Support and maintenance of them falls on your team. Do you want to become responsible for support of your own products when you are not development?