A scope should help suppliers understand what they need to deliver. If it mainly asks for something “fast, modern and intuitive”, each company will fill the gaps with its own assumptions. You will receive prices for different solutions.
Start with users and tasks. Then add technical constraints, supplied materials and the conditions for checking the finished work.
Replace a label with behaviour
Instead of “advanced search”, describe what users search for, which fields they use and what happens when there are no results. Instead of “easy content editing”, explain who publishes, who approves and whether a change history is needed.
You do not need to design every button. Focus on decisions that affect the work and the result. Sample data or a user scenario can be clearer than another paragraph of broad requirements.
Show the boundaries
Record what the supplier provides and what your organisation supplies: content, translations, system access, accounts and test data. If something is not ready, identify the expected date and responsible person.
Include exclusions. If you are buying interface design without development, say so explicitly. If an integration reads data, establish whether writing data is outside the scope. This helps suppliers avoid silently pricing different assumptions.
Read it as an outsider
Pick several requirements and ask: “How will we know this has been delivered?” If the answer introduces another feature, improve the description before requesting prices.
Finally, ask someone outside the project team to identify unclear points. This content review does not replace formal procurement documentation, but it gives that work a stronger starting point. Use the short project brief for early conversations and the acceptance scenarios to define results you can check.
Every number in this article, plus thousands of other contracts, is in the database.
Open the database