“Which software should we use?” sounds practical. It can also skip the part that determines whether any tool will help: understanding what people are trying to get done and where the work breaks down.
Tools make assumptions
Every product has a model of how work should happen. Its fields, permissions, notifications, and reports all encode assumptions. If those assumptions fit the business, the tool can make work easier. If they do not, people build spreadsheets and side channels around it.
Before comparing products, follow one real piece of work from its starting point to its outcome. Note who acts, what information they need, what decisions they make, and where they wait. Include unusual cases; they are often the reason a process feels unreliable.
Define the change first
Describe the result in observable terms. For example: fewer repeated data entries, a clearer view of work awaiting approval, or a reliable record of customer follow-up. Avoid defining success as “installing a CRM” or “using AI”; those name a tool or technique rather than a business outcome.
Then decide what can change: the process, the tool, or both. A configuration change may be enough. A product may fit with a small adjustment to the workflow. Custom software only makes sense when the gap matters and simpler options cannot close it.
Keep the decision reversible
Test the proposed workflow with the people who will use it. Use a small sample of real work, agree how to measure the result, and identify what would make you stop or change direction. This exposes mismatches while they are still inexpensive to fix.
Good software decisions start with the work, not with a demo. Once the problem is clear, the right tool is usually easier to recognise.