An Interesting Case

An interesting case came up today that I wanted to translate into some insight from the SaaS (Software as a Service) side.

Developers commonly face conflicting feature requests. The best solution isn’t always clear, and they’ll never please all people all the time. We can aim to though!

Look at this case today with TechFlow: (which is what my conversation was based on)

TechFlow Particulars:

Shop A: Appointments scheduled today are appearing in TechFlow, which is where we do our dispatching. We only want to see vehicles/tickets that are on location. Can you make it not show appointments?

Shop B: We dispatch in TechFlow and like to prioritize appointments so our techs can plan ahead even though the vehicle isn’t here yet. We need appointments to show up.

Who is right?
This is a little like an ASE test, for those who are familiar.
Shop A?
Shop B?
Both A and B?
Neither A nor B?
What do we do? Pick which shop we like better?
Ask the shiny dome of wisdom on the recent issue of R&W for a golden method?

In scenarios like this, we aim to help both A and B!
But, how?
Add another company setup toggle? There are pros and cons to that approach. Plus, you just know there is a shop C that has a hybrid approach and wants it both ways!

This is what we did…

Take a look at last year when many of you may recall we expanded upon “Sticky Settings.” TechFlow filters received such treAutoflownt. This perfectly addressed the case referenced above.

Filters on TechFlow are sticky at the user level. That means filters that you prefer will remain established each time you return to that page. With user-level view preferences, the information available on TechFlow can be there for Shop B and remain uncluttered for Shop A (or even different departments at hybrid Shop C).

Filters are features that don’t get a lot of fanfare and appear rather mundane. This case, however, serves as a simple example of the types of quandary that developers routinely face and an elegant solution for the result.