Business owners often know that work is slower or harder than it should be without knowing what kind of system would help.
That is normal. Many inefficient processes still get the job done because someone counts, checks, and fills gaps by hand. Over time, the workaround becomes “just how the work is done.”
I usually look at three things before discussing features.
1. Does the work repeat every day?
An occasional ten-minute inconvenience may not justify a project. Daily repetition, several people performing the same reconciliation, and frequent checking are stronger signals.
In the factory-reporting case, more than one hundred workers posted production reports in WeChat groups. Two clerks then counted and consolidated the messages. The work finished, but the same data had to be rebuilt every day.
Before sketching a user interface, write down who does what during an ordinary week and where the rework happens.
2. Where does the data go next?
Some spreadsheets are submitted once and never used again. Others feed operations, management and finance. An error at the first step then creates more work everywhere downstream.
The factory data later fed daily output, machine capacity, exception tracking, and reports required by finance. The goal was not a single reporting page. It was a shared dataset that did not have to be rebuilt for each downstream use.
3. Will the change create more work for frontline staff?
A convenient architecture for engineering can still be a poor change for operators.
Workers already reported in WeChat. Replacing that entry point would have added accounts, training, and extra work before the team had seen a useful result. We kept WeChat and moved parsing, cleaning, review, and aggregation behind it.
It was not the neatest starting point, but it gave the project a better chance of being used.
Then confirm the rules with each team
Operations had to define valid reports and exceptions. Finance had to confirm counting rules. Engineering needed to see how inconsistent the input could be.
One large meeting rarely settles all of this. I prefer to ask each team directly, then record the open decision, owner, and next step. People are more willing to help when they understand which repeated task could become easier and exactly what they need to confirm.
A short checklist
When no one has formally requested a change, ask:
- How often does the work repeat, and how many people touch it?
- Which step creates the most errors or depends on one experienced person?
- Who needs the resulting data later?
- Who gets more work if the entry point changes?
- What is the smallest useful result that would justify continuing?
Only then decide whether the solution is software, automation, or a simpler process change.
Related case: connecting the data behind WeChat factory reporting.