The Four Questions Your Monthly Custom Software Review Has to Answer

The insight: software you don't review on a schedule quietly becomes software nobody trusts

Put 30 minutes on the calendar once a month and make your custom software answer four questions: what changed, why, what it affected, and who owns the next move. That's the whole agenda. If your team can't answer all four without going digging, the tool has stopped being an asset under management and started being furniture — something everyone works around instead of through.

This matters more every year because more of the firm runs on these systems. The U.S. Chamber reported that 84% of small businesses planned to increase their use of technology platforms. That's the direction of travel for firms your size. More platforms means more surface area, more handoffs between tools, and more places where a change made in March silently breaks an intake step in June. Increasing your use of technology without increasing your oversight of it is how firms end up with six systems and no reliable answer to "where did that lead go?"

The four questions, and why each one earns its place

1. What changed?

Not "what did we discuss." What actually changed in the system: a new field, a rerouted notification, a modified intake form, a permission update, a vendor-side update you didn't request. Write it down as a list. Most firms discover the list is longer than anyone expected, and that at least two items on it were nobody's decision — they just happened.

2. Why did it change?

Every change should trace back to a problem someone named. If the answer is "the paralegal asked for it" or "the vendor pushed it," that's still an answer — but it tells you where change authority actually lives, which may not be where you think it lives. Changes without a stated reason are the ones that get reversed in six months by someone who doesn't know why they existed.

3. What did it affect?

This is the question that saves you money. A change to how a case type is labeled affects reporting. A change to intake routing affects response time. A change to a required field affects whether staff start faking data to get past the screen. Software changes don't stay inside the software; they land on people and on numbers.

4. Who owns the next move?

One name. Not "the team," not "IT," not "we'll circle back." A single owner with a single next action. Reviews that end without named ownership produce the same discussion again next month, which is a very expensive way to hold the same meeting twice.

Software changes don't stay inside the software. They land on people and on numbers.

Add two metrics to the agenda: steps removed and error rate

Four questions tell you what happened. Two numbers tell you whether it was worth it.

• Steps removed. Custom software should be subtracting work, not relocating it. Count the clicks, copy-pastes, re-entries, and status-check emails you eliminated this month. If the number is zero, you didn't build; you decorated. Steps removed is the cleanest proxy there is for whether the system is actually earning its cost.
• Error rate. Missed follow-ups, duplicate matters, leads entered twice, fields left blank, conflicts checks skipped. Track the rate, not just the incidents, so you can see direction over time. A tool that removes steps while pushing errors up isn't a win — it's a faster way to make mistakes.

Two numbers, tracked monthly, in a document your team can see. That's enough. Firms that try to instrument twenty metrics end up instrumenting none of them, because nobody has time to maintain the dashboard between reviews.

End the meeting with one commitment — and it isn't about screens

Here's the part most firms skip. Close every review by committing to one action: write the current steps, owners, data, exceptions, and desired outcome before anyone discusses screens.

Say a firm wants a better intake dashboard. The instinct is to start sketching layouts. The discipline is to first write down:

• Steps: what actually happens today, in order, from first contact to signed engagement.
• Owners: who performs each step, and who covers it when that person is in court or out sick.
• Data: what gets captured at each step, and where it currently lives.
• Exceptions: the referral that skips intake, the after-hours call, the case type that needs a conflicts check first. Exceptions are where software goes to die, because they're the cases people handle manually and then stop trusting the system.
• Desired outcome: the specific result you want. "Every lead gets a call attempt within X minutes" is an outcome. "Better visibility" is a wish.

Write those five things and the screens design themselves. Skip them and you'll spend the build cycle debating button placement while the underlying process stays broken — and a beautifully designed interface on top of a broken process is just a broken process with better lighting.

Firms in this situation often find something uncomfortable during the writing exercise: two people describe the same step differently, or nobody can name the owner of the handoff between intake and the case team. That's not a failure of the meeting. That's the meeting doing its job. You cannot automate a process you can't describe.

Your next step

Put the review on the calendar as a recurring monthly item before you close this tab. Thirty minutes. Invite the person who touches the system most, not just the person who pays for it. Bring one document with three sections: the four questions, the two metrics, and the one commitment.

Run it three times and you'll have something most firms never build — a written history of why your systems work the way they do, and a short list of the steps standing between your team and the outcome you actually want. That list is the real specification for whatever you build next.

If you want to see how we approach the design side of this — starting from steps, owners, data, and exceptions rather than from screens — take a look at how BOSSEO approaches custom software.