An effective RFP for a web or AI project in India should include a project overview, specific functional requirements, technical constraints, timeline with milestones, budget range (always disclose it — vendors price to your budget regardless), evaluation criteria, and submission format. RFPs without a stated budget range receive quotes that vary by 10x, making comparison meaningless and extending vendor selection by weeks.
Most Indian businesses that issue RFPs for tech projects have never written one before. The document they produce — often a vague email listing a few features, sometimes a Word document borrowed from a government tender — predictably yields proposals that are impossible to compare, vendors who ghost after initial contact, and a selection process that stretches for months without a decision.
I read RFPs as a vendor and help clients write them as a consultant. The quality gap between a well-structured RFP and a poorly written one is enormous — not just in the quality of responses received, but in the caliber of vendors who bother to respond at all. Serious Indian tech agencies and experienced developers pre-qualify RFPs before investing time in proposals. A vague RFP signals an unprepared client and filters out the vendors you most want to attract.
Why Indian Business RFPs Get Terrible Vendor Proposals (And How to Fix It)
The most common failure modes in Indian IT RFPs, observed across dozens of procurement processes:
Failure 1: No budget disclosure. "Please provide your best quote" is not a useful instruction. A vendor who builds enterprise systems at ₹50 lakh and a freelancer working for ₹15,000 will both respond, producing proposals so different in scope and approach that comparison is meaningless. Your budget is not a secret that vendors will undercut if they know it — they will either qualify or disqualify themselves appropriately, saving everyone time.
Failure 2: Requirements described as solutions. "We need a website built in React with a Node.js backend, PostgreSQL database, and Redis caching" may be technically sophisticated, but it prevents vendors from recommending better-suited technology for your actual use case. Describe what users should be able to do, not how you imagine the system should work internally.
Failure 3: No evaluation criteria. Vendors submit proposals with no understanding of how you will make a decision. Will you choose purely on price? On team experience? On technology approach? On references from similar projects? Without stated criteria, vendors optimize their proposals for what they think you want — which may not be what actually matters to you.
Failure 4: Unrealistic timelines. "We need this completed in 3 weeks" for a ₹5 lakh custom software project signals either unrealistic expectations or a request that will produce rushed, low-quality work. Stating a realistic deadline and asking vendors to confirm or propose an alternative gives you both an execution estimate and a signal about a vendor's capacity to push back constructively.
Failure 5: No format requirements. Receiving one proposal as a 2-page email, another as a 40-page PDF, and a third as a spreadsheet makes comparison painfully difficult. Specify a response format — even a simple one — so proposals address the same sections in a comparable structure.
The RFP Structure That Gets Useful Responses From Indian IT Vendors
A practical RFP structure for Indian IT and AI projects, sized to be genuinely useful without becoming a bureaucratic exercise that scares away good vendors:
Section 1: Company and Project Overview (1-2 paragraphs). Who you are, what your business does, and what problem you are trying to solve with this project. Include a brief description of your existing technology environment if relevant. Vendors use this to assess fit and calibrate their approach.
Section 2: Project Scope and Objectives. What the deliverable should accomplish, described from the user's perspective. For a website: "customers should be able to browse our product catalogue, filter by category, add items to a cart, and pay using UPI or credit card." For an AI project: "we want to automatically categorize customer support tickets into 8 predefined categories with at least 85% accuracy, and route them to the appropriate team." These are requirements. "Build a website with Shopify" is a solution specification — save that for the technical discussion with your selected vendor.
Section 3: Technical Constraints. Existing systems this project must integrate with. Technology requirements that are genuinely non-negotiable (must use AWS if your team only knows AWS). Compliance requirements (payment data, health records, DPDP Act considerations). Hosting preferences. This section should be short — list actual constraints, not technology preferences that could reasonably be overridden by a better approach.
Section 4: Budget and Timeline. State your budget range. "₹3-5 lakh including first year of hosting and maintenance" is a useful budget statement. Include your desired go-live date and explain the business reason for the deadline if it is firm. If the deadline is flexible, say so — some vendors will propose faster delivery at higher cost, others will propose phased delivery that fits a tighter budget.
Section 5: Vendor Qualification Requirements. For web development projects and AI projects above ₹3 lakh, reasonable qualification requirements: minimum 3 years in business (reduces risk of startup closure mid-project), 2-3 reference projects similar in scope, and named project manager and lead developer who will work on your project. For AI projects specifically: demonstrated experience with the relevant domain (NLP, computer vision, predictive analytics) with examples of production deployments, not just proofs of concept.
Section 6: Proposal Format and Submission Instructions. What you want vendors to submit: company background (1 page), proposed approach and technology stack (1-2 pages), project timeline with milestones, team composition and CVs of key personnel, pricing breakdown (not just a total — show cost per phase or component), 2-3 client references with contact details, and any questions or assumptions about the scope.
Writing Requirements That Work: Functional vs Technical Specs for Indian Projects
The distinction between functional and technical requirements is fundamental to writing an RFP that gets useful responses. Mixing them — or getting them backwards — is the primary quality failure in Indian business RFPs.
Functional requirements describe what the system should do from a user's perspective. Examples: "A vendor can register using their GST number and receive verification by email within 2 hours." "An operations manager can view the real-time location of all delivery agents on a map." "The system should send a WhatsApp message to the customer when their order status changes." These requirements are technology-agnostic and specific enough to test against.
Technical requirements describe constraints on how the system should be built. Examples: "Must integrate with our existing Zoho CRM via API." "Must support at least 500 concurrent users during peak hours." "Must be HTTPS-enabled with SSL certificate." "The mobile app must run on Android 11 and above." Technical requirements should be real constraints — not preferences that could reasonably be overridden by a better technical approach.
For AI projects specifically, requirements need to include success criteria that are measurable. "We need an AI chatbot for customer support" is not a requirement — it is a wish. "We need an AI-powered chat interface that resolves at least 60% of customer queries without human handoff, with a fallback to a human agent for unresolved queries, and an average response time under 3 seconds" is a functional requirement with measurable success criteria. Our AI services team helps clients define AI project requirements with specific accuracy, latency, and reliability targets that vendors can actually scope against.
Prioritize requirements explicitly. Use a simple MoSCoW classification: Must Have (project is not viable without this), Should Have (important but not launch-blocking), Could Have (nice-to-have if budget allows), Won't Have (explicitly out of scope for this phase). This classification gives vendors a basis for proposing phased delivery that fits your budget while meeting core requirements.
Should You Include Your Budget in an Indian IT RFP? The Answer Is Always Yes
The resistance to budget disclosure in Indian RFPs comes from a negotiating instinct: "if they know my budget, they will charge exactly that." This instinct is wrong in both its premise and its consequences.
Vendors price to the budget whether you disclose it or not. An experienced vendor reads scope and either estimates the cost to deliver it properly (which may exceed your budget) or guesses your budget range from contextual signals — your company size, the project scope, the platforms you use — and prices to that range. The absence of a stated budget does not prevent vendors from inferring one; it just makes their inference less accurate.
What actually happens when you omit budget: vendors with high overhead and premium pricing submit proposals at ₹15-20 lakh for your ₹5 lakh project. Vendors trying to win at any cost submit proposals at ₹2 lakh that promise full delivery but depend on scope cuts you will not discover until mid-project. You spend 3 weeks in clarification calls trying to understand why proposals differ by 10x. None of this serves your interests.
Budget disclosure produces comparable proposals. When five vendors know the project has a ₹4-6 lakh budget, each one makes explicit choices about what to include in scope, what to defer to phase 2, and what technical approach fits the budget. The proposals are different in approach but comparable in price range — which means you are actually evaluating vendor quality, not variance in budget assumptions.
One practical note: state a budget range rather than a precise number. "₹3.5-5 lakh" is more useful than "₹4 lakh exactly" because it signals flexibility for the right approach without anchoring to a single number. The upper bound tells vendors what you can stretch to for the right solution; the lower bound filters out vendors whose minimum viable solution exceeds your capacity.
Scoring and Evaluating Vendor Proposals: A Framework for Indian Business Owners
Receiving proposals is not the end of the process — evaluating them objectively is where most Indian business owners struggle. Without a framework, evaluations default to price as the primary selection criterion, which consistently produces outcomes that cost more in the long run than selecting a more qualified, slightly more expensive vendor.
A practical scoring framework for Indian IT RFPs, using a 100-point scale:
Technical approach and understanding (25 points). Did the vendor demonstrate genuine understanding of your problem, or did they submit a generic proposal? A strong response references your specific requirements, identifies likely technical challenges, and explains their proposed architecture in plain language. Vendors who copy-paste generic capability descriptions without engaging your specific requirements score poorly here.
Relevant experience (25 points). Similar projects with verifiable references. For a healthcare appointment booking system, a vendor who built a similar system for a clinic network in Bengaluru scores higher than a vendor with generic "web application development" portfolio items. Actually call the references — this is standard practice in Indian B2B procurement and vendors expect it.
Team composition (20 points). Named team members with relevant experience levels. Red flags: no named individuals (agencies that staff with whoever is available); very junior lead developers on a complex project; project manager based overseas for a project requiring frequent local communication. For IT consulting and development projects, understanding who specifically will work on your project matters more than the agency's general reputation.
Pricing and value (20 points). Not cheapest, but best value for the budget. Evaluate the payment schedule — milestone-based payments are more client-protective than large upfront payments. Check what post-launch support is included. Understand what assumptions could cause scope creep and associated change orders. A proposal at ₹5 lakh with clearly defined scope and a 90-day warranty often delivers better value than a ₹3.5 lakh proposal with vague boundaries and no post-launch support.
Communication and process (10 points). How the vendor handled the RFP process itself is a preview of how they will handle project execution. Did they respond on time? Did they ask clarifying questions that demonstrate they actually read the RFP? Did the proposal arrive with professional formatting and accurate grammar? Vendors who cannot manage a simple proposal process reliably will not manage your project reliably.
For projects above ₹5 lakh, conduct shortlist presentations before final selection. A 45-minute video call where the vendor walks through their proposed approach, demonstrates relevant past work, and introduces the project team reveals far more than any written proposal. The quality of questions a vendor asks during this call — about your users, your workflows, your constraints — is one of the strongest predictors of project success.
Frequently Asked Questions
How many vendors should I send an IT RFP to in India?
Three to five vendors is the optimal number. Fewer than three limits meaningful comparison; more than five makes evaluation unmanageable and signals to serious agencies that you are running a price discovery exercise rather than a committed procurement. For projects above ₹5 lakh, consider a two-stage process — shortlist based on credentials first, then issue the detailed RFP to three finalists.
Should an Indian business include the budget in the RFP?
Always include it. Vendors calibrate proposals to your budget whether you state it or not — omitting it just means they guess, producing responses ranging from ₹50,000 to ₹20 lakh for identical requirements. Budget transparency saves 2-3 weeks of back-and-forth clarification and produces comparable proposals you can actually evaluate side by side.
What is the biggest mistake Indian businesses make when writing IT RFPs?
Specifying the solution instead of the problem. Writing "we need a PHP WordPress site with 5 specific plugins" when you should write "we need customers to book appointments online and pay in advance" lets vendors recommend the best technical approach for your budget. Prescriptive specs get you exactly what you asked for — which is often not what you actually need.