Describe the work from arrival to completion
Choose a representative request and follow it through the business. Record how it arrives, who receives it, where the information is stored, who makes the next decision and what counts as complete. For example: an enquiry arrives, the office qualifies it, a person prepares a quote and someone follows up. Include the actual tools and handoffs. This gives the team a shared process to discuss before selecting screens or technology.
Show the problem with an example
Bring a redacted example of the spreadsheet, form or report your team uses. Describe a recent delay, correction or lost handoff and the time it takes to resolve. Explain how often it happens and who is affected, marking estimates as estimates. Avoid sending passwords or customer data in an initial enquiry. If sensitive evidence is needed later, agree access and handling before sharing it.
Name the users and their access
List the roles that will use the first version and the actions each role should be able to take. Include who can assign work, change a price, see a customer record, approve an exception or export data. If staff work away from a desk, describe the devices and connectivity they actually have. Offline access is a design decision: say which information needs to remain available and what should happen when two people update the same record.
List the data and connections
Identify the current owner of each important record and the systems that must exchange information. Name the calendar, accounting tool, CRM or messaging service, and confirm whether you have access to its API. For imported records, describe identifiers, duplicates, attachments and the checks needed to reconcile totals. An integration proposal should include how failures become visible and who will recover them. Access being possible in a sales description does not prove it is available in your account.
Keep a small set of acceptance examples
Write a few concrete examples that show whether the workflow works. A new enquiry should have an owner and a next action. A failed message should be visible to the office. A user without export permission should not receive the data. A repeated submission should not create duplicate work. Include a cancelled request and incomplete information alongside the successful path. Review these examples with the staff who will use the system.
Separate the first version from later ideas
State the starting point, finishing point and required roles for the first version. List tasks that can stay manual, features that can wait and the existing systems that will remain in use. Record the desired timing and any fixed dependency, such as an account approval or a seasonal busy period. A realistic scope explains what happens after launch: training, support, upgrades, backups and who owns the source and service accounts.
Bring a brief that can be reviewed
A useful opening brief can fit on a page: the business and users; the workflow; the repeated problem; current tools; necessary connections; a few acceptance examples; timing; and the owner of the decision. Add redacted supporting examples when they clarify the work. Moxisync can use that evidence to compare improving an existing tool, connecting tools or building a focused custom workflow before agreeing a written scope.