In this article14 sections
A poorly written request often leads to a weak project
Companies often request offers for AI, software or IT services by sending a list of features, an approximate deadline and the question of price. That may be enough for simple procurement, but it is weak for digital projects that change how work is done. If the request is poorly defined, the offers may look comparable, while actually solving different problems.
A good request does not have to be a perfect technical document. But it must explain the business context, problem, goal, current state, expected outcomes, constraints and decision criteria. Without that, suppliers guess what you need and you later compare prices for solutions that are not truly the same.
The biggest mistake is defining the solution before defining the problem. Then the process becomes a race to satisfy a list of requirements, not to solve the business pain.
Describe the problem before the desired solution
If the request starts with “we need an AI assistant”, “we need a CRM” or “we need new IT support”, there is already a risk that the most important step has been skipped. Why do you need it? What is not working today? Who feels the consequences? How often does the problem occur? How do you know this is the right solution?
A better start is a clear problem statement. Employees spend too much time searching for procedures. Sales loses follow-up because data are spread across tools. Management does not trust reports. Documentation is not up to date. Customer support repeats the same answers. IT issues are solved reactively. Backup exists, but is not tested.
When a supplier sees the problem, they can suggest a better approach. When they see only the requested solution, they will probably answer that request, even if the real need is different.
Explain the current state clearly enough
A good request should explain how the company currently works. Which tools are used? Where are data stored? Which teams participate? How many users will use the solution? Are there multiple locations, remote teams, legal entities or access levels? Which systems already exist? Which processes are formalized and which depend on habits?
This is not unnecessary documentation. It is the basis for a realistic offer. Without a clear picture of the current state, the supplier cannot estimate scope, integrations, risks, timelines and required resources accurately.
For AI projects, it is especially important to describe knowledge and data sources. Where are the documents? Are they up to date? Who maintains them? Are access rights defined? Is integration with CRM, ERP, DMS, ticketing or SharePoint needed? These questions directly affect the realism of the solution.
Define outcomes, not only features
A feature list is useful, but not enough. It is more important to define the business effect. What should change after the project? Less manual work? Faster customer response? More reliable reporting? Better records? Lower risk? Easier onboarding? Better access to knowledge? A more stable IT system?
When goals are defined through outcomes, the supplier can propose a solution that may be simpler, phased or different from the initial idea. When goals are defined only through features, the system can tick all the boxes and still fail to change how work is done.
A good request should separate mandatory, desired and later requirements. Everything marked as mandatory increases cost, scope and risk. If the goal is an MVP, do not request every possible feature. If the goal is stability, do not skip prerequisites.
State constraints, risks and internal prerequisites
Companies often describe what they want, but not what limits them. That is a mistake. Budget, deadlines, people availability, data quality, existing contracts, security rules, internal policies and employee readiness directly affect the project. A supplier who does not know this cannot provide a responsible offer.
It is especially important to state who will own the project on the client side. Digital transformation cannot be delegated only to the supplier. The client needs a person who makes decisions, gathers people, provides feedback and removes blockers.
A good request should also state what is out of scope. Are you asking only for strategy or also implementation? Are integrations included? Will historical data be migrated? Will all users be trained or only key users? Will the supplier maintain the solution after delivery? These boundaries protect both sides.
Define decision criteria before receiving offers
If criteria are not defined in advance, the decision often comes down to price, impression and the best-looking presentation. That is not enough. Digital projects should be evaluated by understanding of the problem, methodology, proposed sequence, experience, integration ability, security approach, post-implementation support and realism of the estimate.
Price matters, but it is not the only criterion. The cheapest offer can become the most expensive one if it skips analysis, migration, training, security or expects the client to solve all prerequisites alone.
A useful criterion is also the quality of questions the supplier asks. If no one asks for clarification, the request may not have been read carefully, or the supplier may be preparing a generic offer.
How Positive can help before the request is sent
The most useful step often happens before a formal request is sent. A short diagnostic can help management separate symptoms from causes, define priorities and decide whether the company needs strategy, implementation, AI, business software, IT foundation or a combination of areas.
A request prepared in this way is not only a procurement document. It becomes a decision tool. The company knows more clearly what it needs, suppliers provide more responsible proposals and the project starts with fewer assumptions.
Frequently asked questions
Does a request need to be technically detailed?
Not always. For complex digital projects, it is more important to describe the business problem, current state, goals and constraints clearly. Technical details can be refined during diagnosis.
Should we ask for the price immediately?
You can ask for a range, but a precise price without understanding the scope is often unreliable. It is better to define scope, prerequisites and phases first.
How can we avoid receiving offers that are not comparable?
By clearly defining the problem, goals, expected outcomes, scope, decision criteria and what is out of scope.
When do we need a strategic partner instead of a vendor?
When the problem includes several areas: processes, software, data, AI, infrastructure, security and employee adoption.
What is the most common mistake when choosing a partner?
Choosing based on price and presentation, without checking whether the partner understands the business problem and implementation sequence.
Call to action
If you want to define the right problem, priorities and scope before choosing a digital transformation partner, book a consultation with Positive.
Related service: business consulting.
