Describe the outcome
Write down what should become easier or more reliable. “The office can review completed field jobs without retyping them” is more useful than “we need an app”. Name the people who will use the result and the person responsible for deciding scope.
Show the current process
Map the steps, roles and exceptions. Include what happens when information is missing, approval is declined or a customer changes a request. Sanitised examples help a delivery team understand the details without exposing private customer records.
List the systems involved
Record which applications hold customer, stock, booking or payment information. Identify who controls those accounts. An integration depends on approved access, provider capabilities and reliable data, so avoid assuming that a logo means the connection is available.
Separate essential from later
Choose a first release that solves a complete problem. Put useful additions into a later list. Discuss timing and budget openly, including uncertainty. “Need guidance” is a reasonable starting point when the scope has not been assessed.
Plan the handover
Identify who will maintain content, manage access and receive support notifications. Training, backups, ownership and ongoing maintenance belong in the project discussion from the beginning.
Have a workflow in mind? Turn it into a useful starting brief.
Open the Solution Architect