Why Does Your Software Make Employees Ask So Many Questions?

Open your team's Slack and count the questions that already have a right answer somewhere in the building. 

Whether a return past the window still gets approved, and by whom, has a right answer that somebody in your company already set. 

The software everyone is working in has a free-text field where that rule should be.

A good system makes the right decision easier, the wrong decision harder, and repeated decisions unnecessary. 

When software leaves a rule open to interpretation it hands that rule to whoever happens to be logged in, and you get as many versions of the answer as you have employees. 

In almost every system we are brought in to improve, the decisions have already been made by someone senior enough to make them, and the only place they are stored is in people.

‍

What does it mean when your team keeps asking the same question?

A question that comes back every week is a business rule your software never encoded. 

The answer exists, your operations lead is the one who keeps giving it, and every one of those conversations is work the product could have done.

Ninety percent of developers lose six or more hours a week to organizational inefficiencies, across 3,500 developers and managers surveyed in 2025, and the friction they named first was finding information. 

That number gets measured in engineering because engineering is where companies bother to measure it, while the same tax runs through operations and support with nothing counting the hours.

Around 80 percent of how a company actually operates was never written down anywhere. 

It lives in habit and in one person's memory, and that arrangement holds up right until the week that person is out and the rest of the team is guessing.

‍

Why does the same data get entered differently across departments?

When two people can record the same situation two different ways, your reports stop describing one thing. 

A status field with eight options and no definitions is eight opinions, and by the end of the quarter finance is counting deals your sales team would not call closed.

Leadership then meets to talk about the number and spends the first twenty minutes establishing whose version is right. 

The decision was never made cleanly, so the software had nothing to carry, and the ambiguity travels up the chain until it is being resolved by the most expensive people in the company.

We find the same five symptoms in almost every system we audit:

• The same record type gets handled differently by two teams
• One person's export is the version leadership actually trusts
• A status means one thing when sales sets it and another when fulfillment reads it
• Two systems hold the same customer record and neither is authoritative
• A workflow has an exception that only one person knows how to apply

Every item on that list is a decision the business owns and the software never received, which is why cleaning the data does not fix it for long.

‍

Which business rules should be built into your software?

Build in any rule that has a right answer today and will still have one next quarter. 

Those are the ones your team is carrying by memory right now, and encoding them is the least expensive reliability work in a build:

• Thresholds. What amount needs approval, and from which role
• Eligibility. Which customers, plans, or job types qualify for what
• Field definitions. What each status actually means, written where someone will read it
• Defaults. What the system does when a user chooses nothing
• Sequencing. Which steps cannot happen before others
• Ownership of exceptions. Who is allowed to override, and what gets recorded when they do

A document tells someone the rule after they go looking for it, which only helps the people who already suspected there was a rule to find. 

Encoding it puts the rule in front of the person who did not know to ask.

‍

Do more options make software easier to use?

Every option you add moves work from the people who designed the system to the people using it. 

The interface looks more capable, and the person in front of it now has to hold your business logic in their head to use it correctly while a customer waits on the phone.

Defaults settle this more reliably than training does. When Instagram moved teenagers into built-in restrictions in September 2024, 97 percent of 13 to 15 year olds were still inside those settings months later.

Every one of them could have opened the settings and turned the restrictions off, and almost none did. A default decides on behalf of the people who never open that screen, and that is nearly all of them.

Sequencing does the same work inside a business tool. On Bignition we built a game plan wizard for goal tracking, so an insurance agent opens it to a first question that has already been chosen for them. 

Agencies using it now have a more complete view of their growth activity, and the wizard is what makes that view repeatable from one agent to the next.

‍

What should you automate first in a business process?

Automate the rules your business has already decided, and keep the rest visible to a person. Automation makes an existing decision faster and more consistent. 

Point it at a rule that was never settled and it will freeze one employee's interpretation into the workflow and give that interpretation the authority of the system, which is how a company ends up defending a policy its executives never approved.

Maintenance scheduling is a clean example of a rule worth encoding. For BeaconMedaes we built MyMedGas to handle inventory management, asset tracking, maintenance scheduling, and training education across the medical gas industry, where service intervals come from published standards. 

The platform carries the schedule, so a technician arriving at a site is executing a plan those standards already settled.

Whatever the system decides on its own still has to show its work. 

We believe that business is built on transparency and trust, and that good software is built the same way, which in practice means an automated action should record what it did and what it used to decide.

‍

Which business decisions should not be automated?

Keep a person on any decision where the situation is genuinely new or the cost of being wrong is hard to reverse. 

Leave that line undrawn and the software starts making calls your team disagrees with, and they go build workarounds that cost you the consistency you automated for. 

Five categories belong to a person:

1. New situations. Anything the rule was not written for
2. Judgment about a person. Hiring, credit, discipline, eligibility for care
3. Expensive and irreversible outcomes. Money leaving the company, or a record deleted with no way back
4. Reputational calls. Anything a customer will read as your company's official position
5. Rules the business has not actually settled. If two executives would answer differently, it is not ready to encode

The last one is where projects actually get stuck. A requirements session that cannot resolve a rule is telling you something true about the business, and the fix is to go get the decision made. 

Building a configurable option moves the argument inside the software, where it will be more expensive to have.

‍

What should leaders look for before building or rebuilding a system?

Before approving a build, find out which decisions your team is currently making by hand. 

These six questions surface them faster than a requirements document does:

1. What question does your team ask in Slack most often? That is your first candidate for a rule.
2. Which number do two departments report differently? Settle the definition before the rebuild, not after it.
3. Which approval needs a manager, and can anyone name the threshold? If nobody can name it, it does not exist yet.
4. Which spreadsheet exists because the software would not let someone record reality? That spreadsheet is a specification.
5. Which rule exists because of one incident years ago? Confirm it still applies before you encode it permanently.
6. Which decisions are you willing to let the software make, and who reviews those? Answer this before a vendor answers it for you.

We run a free two to four hour Exploratory before writing a proposal, and most of that session is this exact conversation. 

We are working out which parts of your workflow are settled rules and which parts need judgment, because that split determines what gets built and what the fixed fee on it looks like.

‍

How do you find the decisions your software should be making?

Good systems reduce the number of decisions a person makes in a day, and the ones left over are the ones that needed a person's judgment in the first place. 

Everything else should already be settled by the time someone opens the screen.

Pick the questions your team answered most this month and try to write the rule behind each one in a single sentence. 

Some of those sentences come easily, and every one of them is a rule your software should already be enforcing. 

The ones that come hard are decisions your company has not actually made, and getting them made is worth more than the feature you were about to put in the backlog.