You don't need to explain the code. A good Excel project brief describes how work happens today and what should happen after the tool is built.
1. Show the starting point
Describe your existing workbook and data sources. Does the work begin with a CSV, an exported report, a manually entered form, or several separate spreadsheets? Include sample column layouts when possible, but remove confidential or personal data.
2. Explain the desired result
Don't stop at “automate this spreadsheet.” Describe the final output: an updated master table, a printable report, an order list, a dashboard, or a file ready for upload to another system.
3. Describe the business rules
What happens with duplicates? What if an end date is missing? Which records are excluded? Who is allowed to edit a field? These rules often take more effort to design than the actual buttons.
4. Clarify the environment
Specify whether you use Excel 2019, Microsoft 365, Mac, or browser-based Excel. Some functions and VBA features are not available everywhere. Mention if files need to be stored on OneDrive or used by multiple people.
5. Agree on acceptance tests
Choose a few realistic examples—including exceptions—that make it obvious whether the tool works. This helps avoid misunderstandings and gives everyone a clear definition of success.
Shortcut: a two-minute screen recording of the current process can be more useful than several pages of technical descriptions.
Start small if the workflow is unclear
For large projects, a discovery or workflow-audit phase can produce a blueprint before development begins. That reduces rework and makes pricing more predictable.
Have an Excel workflow like this? Tell me what you're trying to improve.