A vague request produces vague pricing. A useful brief gives vendors enough context to make assumptions visible before they become contract problems.
Start with the outcome
Describe what should be different for the users, the operation, or the organization when the project is complete. Avoid beginning with a product unless the product is already a fixed requirement.
A sentence such as 'field staff need secure access to case records without returning to the office' gives a delivery team more direction than 'we need a cloud solution.'
Describe the current environment
List the systems, user groups, locations, data, devices, suppliers, and support arrangements that matter to the requirement. If something is unknown, say that it must be confirmed during discovery.
Include known dependencies and planned changes. A supplier cannot price a clean migration if a connected system is being replaced at the same time and nobody mentions it.
Name the boundaries
State deadlines, budget ranges if available, security or handling needs, required standards, delivery locations, procurement rules, and any products that must or must not be used.
Separate fixed constraints from preferences. That lets vendors offer a better alternative without ignoring a real rule.
Define acceptance in plain language
Explain how the organization will decide that the result is ready. Useful acceptance criteria cover working functions, performance, security checks, documentation, training, handover, and support.
Ask suppliers to identify assumptions, exclusions, dependencies, and decisions needed from your team. Those four items expose more delivery risk than a long marketing response.