Client Management Must-Haves

A care organisation with a basic, solid client management system provides more contact hours than one with a poor-fitting system. The opportunity cost of a poorly functioning system might be hidden, but it's real. There are likely hundreds of contact hours being given up every month that could be creating a significant impact in the community instead of being wasted on demoralising, repetitive work for your most valuable staff.

It's a shame, but none of my customers have a client management system that provides the basic features I’ll cover below. As a result, a chunk of their funding is spent on a disproportionate number of team leaders filling in for their poor systems, with a host of spreadsheets they use daily, weekly, fortnightly, and monthly to plug the gaps.

Now, I'm not an advocate of change for change's sake, but in the case of core systems like client management and accounting, these inadequate systems create an extreme amount of manual work. They need to be replaced with something that does the basics. The manual work wastes valuable staff time, and hundreds of contact hours are lost every month due to demoralising, repetitive work. These hours could be better spent creating a significant impact in the community.

If you read this article and want to nominate a SaaS vendor you think satisfies most of these requirements out of the box, please let me know. Here are the must-haves for a solid client management system.

1: Capture of Contract Reporting Requirements at Source

Even a smaller care organisation has a host of funding sources, and every one of these comes with specific data we're obliged to capture and report on every six or twelve months. These requirements fall into roughly two categories: demographics and case note classification.

Most client management systems capture some demographics like age, sex, and postcode, but these need to be configurable. Most importantly, these need to be configurable per contract because the information required for one contract is almost always different from the next.

Workers don't want to be scrolling down a list of 100 data points when they're registering a new client. This should be as simple as selecting the relevant contract types for the client and then only being shown the information they need to capture for those contracts. One contract might need to capture information about "cultural background" and "relationship to care recipient," while another contract might not.

The other reason this needs to be configurable is that two contracts can require the same information in different formats or with different values. An example I've seen is "cultural background," which in some cases needs to be selected from a list of four specific entries and in other cases a list of more than ten.

The second area we need to capture configurable information is the classification of case notes. Again, these need to be configurable per contract. In this case, configuration needs to include the ability to multi-select some data points. For example, "service type" or "service category" is a common requirement for contract reporting, where the worker needs the ability to select multiple values per case note, like "carer support agreement development" and "house services."

2: Genuine SaaS (Software as a Service)

The reason we buy SaaS is to avoid the internal staff costs required to install, operate, and patch computer infrastructure to run old-school software. Most organisations have a SaaS-only policy, which is great.

There are some finer points though, where service providers have been caught out because software vendors are still using old-school technologies under the hood, but they're rebadging them as "SaaS" or "cloud." The main thing to look out for here is a vendor who uses words like "provision," "upgrade," "test," or "environment." These are words used in the '80s and '90s for infrastructure-based products, and they don't appear in the vocabulary of a true SaaS company like Gmail or Xero.

These concepts point away from "true" SaaS. They're more indicative of a transition service we refer to as a "managed service." It's old-school technology with a new-age veneer that the vendor hides from you by managing the overheads themselves.

The reason this distinction is important is that it points to a different technology, customer, and commercial philosophy inside the vendor's organisation, and these eventually manifest in less responsive communications, quality issues, and higher licence costs. They also place a higher vendor management load on your team.

3: Professional, Self-Service APIs

APIs are the integration points to and from a vendor's solution. Integration is synonymous with automation. Without easily accessible APIs, we can't integrate a vendor's products into our automations cost-effectively. We're tied to the vendor to make customisations, and they will generally charge for those.

It doesn't matter how many "out of the box" integrations a vendor provides into other popular systems - there's always an edge case where one of our other systems isn't supported, so we need to commission our own integration. For this, we need rock-solid, easily accessible APIs. Being tied to vendors for customisations is its own black hole I've warned against.

Most vendors will "tick the box" for APIs by having a few selected services available as an API. This isn't good enough though when selecting a product. We need two things: strong coverage and self-service accessibility.

Coverage means that we need an API for all of the common functions that the software handles internally, like new client, modify client, archive client, new case note, and so on. Taking stock of coverage before you buy is crucial because at that point you won't know what integrations you're going to be building in the following years - you need to know most things are covered. There's no need to do a detailed stock take of vendor services here. A seasoned developer will be able to pick out the weeds given a few hours - if necessary, pay someone to do this one-off, pay them for a day's work.

Self-service is important and also super easy to test. Firstly, if you type in "{vendor software} API" into Google, it should come up with public documentation about their API. If the vendor requires an NDA or hides their documentation inside their product, it's a really bad sign. Secondly, it should be possible for any developer to interact with APIs without contacting the vendor. This is super important because requiring vendor interactions to write and test integrations adds another zero to the development cost, as well as being frustrating for developers.

The good news with APIs is that there are some solid examples. My favourite is Stripe, the credit card gateway. Type "stripe api" into Google and have a click around. A junior developer can write and test an integration with Stripe in less than 15 minutes, which is what you're after.

4: Not Workarounds

With the requirements I've described here, it's important to distinguish between "out of the box" and workarounds. It's not acceptable to solve deficiencies using add-ons to the product, adding your requirement to the vendor's roadmap, or building customisations for you. These all come at a high price in terms of vendor dependence and/or manual work downstream.

The Must-Haves

These are fundamental must-haves for any vendor. If they're not provided, you'll regret buying their software. A quick recap:

• At-source capture of contract reporting requirements; configurable per contract.

• Genuine SaaS product, not re-badged old-school software.

• Self-service APIs.

• Provides all the above out of the box, without add-ons, workarounds, or additional vendor customisation needed.

Andrew Walker
Technology consulting for charities
https://www.linkedin.com/in/andrew-walker-the-impatient-futurist/