Resolve the rule before building the tool
Software can make an agreed rule easier to apply. It cannot reliably implement a decision the organisation has not made. A request workflow with disputed acceptance rules may need a business conversation before it needs another screen.
The question is not whether a new application is possible. It is whether the organisation can describe the decision that application should carry out or support.
Look for disagreement hiding inside a status
Suppose a fictional team calls a request “confirmed” as soon as a salesperson replies, while the warehouse uses the same word only after checking the selected variant. Customers receive different expectations depending on who handled the case.
Adding a shared “confirmed” button would give the disagreement a common interface without resolving it. First agree what the state means, who can apply it and what evidence they need. There may be two legitimate states rather than one word everyone must interpret differently.
Test a small operating rule
For a limited sample of fictional or appropriately handled real work, use a clear manual distinction. Record receipt, specification review and business acceptance separately. Identify who owns a request at each stage and what happens when an answer is missing.
The trial reveals details that a feature list may miss. Does the team need to reverse an acceptance after a correction? Can the buyer request an alternative while the original enquiry remains open? Which questions must be visible to the customer? These findings help define the future software.
The manual trial should not become an uncontrolled store of private records. Use the organisation's approved tools and information-handling arrangements. If the test requires a new provider or sensitive access, those dependencies still need review.
Check what existing tools can already do
A missing filter, a clearer message or a supported configuration change may address the demonstrated problem. Consider whether the current product can express the agreed states without making maintenance confusing. A smaller change is worthwhile only if it remains understandable to the people operating it.
Conversely, a temporary workaround can become expensive when staff repeatedly copy information or cannot preserve the relationships between changes. The evidence for new development is the specific limitation and its consequences, not simply frustration with the current interface.
Decide what would justify the next step
Write the result the new tool must improve and the operating rule it must preserve. If nobody can approve that description, more design work may be premature. If the rule is clear but existing tools cannot support it adequately, a bounded development scope becomes easier to assess.
The project options compare content, configuration, repair and workflow work. The deeper questions help expose decisions that a first feature list often leaves open.