Find where the spreadsheet stopped helping
A spreadsheet can be sufficient while the team can find the right version, understand the work's status and identify the next person to act. A change starts making sense when these tasks require repeated clarification. Record those difficulties before deciding that the business needs its own application to manage approvals.
Imagine a team preparing commercial proposals in a shared sheet. Each row contains the customer, a document, a responsible person and an approval cell. After a while, the person responsible needs to ask in chat whether the linked document is the latest version and whether a comment refers to the current price.
This is a hypothetical example, but it supplies a concrete question to investigate: which information sits outside the record? If decisions live in messages, different files and colours whose meaning varies, the spreadsheet no longer lets people reconstruct the process. The team spends effort confirming the status before it can start working.
It also matters who uses the sheet and in what circumstances. A mobile review may require opening a document, enlarging an image and returning to a cell to write. The portal's design should shorten that particular journey, instead of merely displaying the same grid in different colours for the people involved.
I would start by following a few complete requests, from preparation to final decision. I would note uncertainties, mixed-up versions and manual steps. This observation provides material for planning an application before starting to code and lets you explain what AI should improve without asking it to invent the process.
To prepare your next step, explore Developing applications with AI.
Define what each state means
States need to represent different situations and have clear conditions for entering and leaving them. Draft, in review, changes requested and approved may be enough to start. For each transition, define who acts, what must be completed and which information is stored after the decision so that others can understand it.
“In review” might mean the author has finished preparing the work and handed a specific version to another person. If required attachments are still missing, the request remains a draft. This distinction prevents reviewers from receiving incomplete work and having to discover for themselves whether they can begin assessing it.
“Changes requested” should include a reason that someone can act on. In the proposal example, writing “review the price of the second option” is more useful than merely changing the row colour. The author knows what needs correcting, and the reviewer can later confirm whether the observation was addressed.
Approval must be associated with the version examined. If someone changes the amount, wording or a relevant attachment after approval, define whether the previous decision remains valid. I would return the new version to review when the change affects what was approved. The earlier history should remain available to consult.
Write these rules with examples of allowed and forbidden transitions. Someone may be able to withdraw a draft but should perhaps not silently archive an approved request. There is no universal sequence for every business. The portal needs to represent the responsibilities agreed for that work, including exceptions that actually occur.
Separate preparation, review and decision
Permissions should follow each person's responsibility in the process. The preparer may need to edit; the reviewer may request adjustments; the approver makes a decision with a defined effect. Clarify whether someone can combine roles and how the system confirms that authorisation before accepting a change to a particular request.
A hidden button does not demonstrate that an action is protected. The application should check on the server whether that person may change that request, even when the attempt arrives through another route. This matters particularly when the portal holds information about different customers or some collaborators only participate in certain projects.
Define how the responsible person can be replaced as well. If the approver is absent, who may take over, and who authorises the switch? Without a rule, the team may start sharing access or asking someone to approve on another person's behalf. The history then stops explaining who actually made the decision.
The criterion resembles defining who approves what in a project with an external team. The tool should show each intervention's limits and preserve the decision-maker's authority. Comments, preparation and approval can coexist without being merged into a single permission to edit everything in the process.
AI can help summarise observations or prepare a suggested change. That does not automatically authorise it to mark the request as approved. If you add this assistance, make the suggestion visible and retain the decision at the point in the process defined for the responsible person to assess it.
Build the first version around one complete request
The first version should allow one type of request to finish from beginning to end, including a return for adjustments. Show the material under review, its version, the responsible person and available actions. Test this journey before adding reports or integrations that depend on states the team does not yet understand clearly.
In the hypothetical example, the reviewer would open the proposal and find the amount, document and conditions needed for a decision. They could approve or request a correction without searching other conversations for information. The author would receive the observation in the same request, attached to the version being assessed.
When transferring data from the sheet, do not infer approvals from ambiguous cells. A green row may mean “sent” to one person and “approved” to another. Preserve the original record and identify cases that need confirmation before assigning them a state with consequences in the new portal.
Test simultaneous situations too: the author edits the document while the reviewer still has the previous version open. The application should prevent a decision based on old information from silently approving new content. This is a concrete rule to give the implementer and then verify using two test sessions.
Include mobile use and errors in the trial. An attachment that will not open, an expired session or a slow connection should not leave someone believing they approved when the decision was never saved. The confirmation displayed needs to match the actual result, with a clear way to try again when appropriate.
Check whether the portal made decisions clearer
Assess the portal by the ability to find the right request, understand what is missing and complete the decision without reconstructing conversations. Compare these journeys with the starting situation and collect the team's difficulties. Adoption is only demonstrated when people can work within the new process and its history remains understandable.
I would observe how many requests require clarification about version, responsibility or status. I would separate the time spent preparing a review from the time the work waits for a decision. A portal may simplify preparation without fixing an internal rule that makes every approval depend on the same person.
After the trial, choose a date to stop using the sheet as the current record and preserve it as a reference archive. Keeping two sources in parallel without a rule creates contradictory decisions. The team needs to know where a change is recorded and which history takes precedence when records differ.
Maintenance continues after delivery: managing access, adjusting fields, recovering information and fixing failures. Define who handles these tasks and how data can be exported. The ability to build bespoke software does not remove the work needed to keep it usable as the team or its process changes over time.
This is a concrete use of AI in business processes beyond the chatbot. The spreadsheet helps reveal the process; the portal can make it easier to carry out and follow. The transition is worthwhile when it removes real uncertainties while retaining the decisions and responsibilities the work requires.