Describe the difficulty first
A spreadsheet can be a useful tool. The question is not whether it looks sophisticated enough, but whether it supports the work reliably. Identify the specific point where people have to copy information, reconcile versions or ask someone else for the latest status.
Write down a few real examples. Repeated problems are easier to assess than a broad request to replace all the spreadsheets.
Check the process before choosing software
A better naming convention, clearer ownership or an existing platform feature may solve the problem. Consider those options before commissioning a new application. Custom software needs defined requirements and ongoing ownership.
If users need different access, structured approvals or a shared record that several steps depend on, map those needs carefully. The workflow should drive the tool’s scope.
Define a focused first release
Start with the essential user journey and a small set of acceptance criteria. Specify where the data comes from, who can change it and how it will be checked. Integrations need technical assessment, including API availability and permissions.
Agree hosting, licensing, source code, handover and support arrangements before development begins. A useful first tool is one the team can understand, test and own.