Most ERP RFPs written by Singapore manufacturers do not work. They are either copied from a template found online (which describes a generic business, not yours) or written by a consultant who has never operated a manufacturing floor. The result: vendors respond with marketing materials, every feature box is checked, and the evaluation produces no useful differentiation.
A good RFP describes three things clearly: what is broken, how it works today, and what success looks like. Everything else is detail that can be covered in vendor demos and discovery sessions.
What to Include
1. Company context (1 page). What you manufacture, how many staff, how many sites, annual revenue band, key customers (by type, not name), and the operational model (make-to-order, make-to-stock, engineer-to-order, or mixed). This gives the vendor enough context to determine fit without requiring a site visit.
2. Current state (2 pages). What systems you run today (accounting, inventory, quoting, production — even if "production system" is a whiteboard and a spreadsheet). What works and should not change. What is broken and must improve. Be specific: "quotes take 2 days because pricing is in one person's head" is useful. "We need a quoting module" is not.
3. The problems to solve (1-2 pages). Not features. Problems. "We cannot answer 'did we make money on that job?' until 3 weeks after delivery." "Supplier POs are lost in email and we miss delivery dates 15% of the time." "Our recall trace takes 4 hours because batch records are in binders." Each problem statement should include: what happens today, what it costs (time, money, risk), and what good looks like.
4. Success criteria (1 page). How you will measure whether the new system works. Specific, measurable outcomes: "quote turnaround under 4 hours", "job cost variance under 5%", "recall trace under 15 minutes", "month-end close within 3 working days". These become the acceptance criteria for the project.
5. Constraints (half page). Budget range (even a band helps — "S$15,000-S$30,000" or "under S$100,000"). Timeline ("must be live by Q4 2026"). Technical constraints ("must integrate with Xero", "must run in a browser", "must support mobile on the factory floor"). Non-negotiables ("we will not replace our accounting system").
6. Response format (half page). Tell vendors exactly what you want back: proposed approach (how they would solve each problem), implementation timeline, cost breakdown (not a single number — break it into licence/build, implementation, training, ongoing), references from similar SG manufacturers, and what is not included.
What to Leave Out
Feature checklists. A 150-line feature matrix does not tell you which vendor will solve your problem. Every vendor checks every box. The checklist creates a false sense of comparison while hiding the actual differences in approach, depth, and fit.
Vendor-specific questions. "Does your system support multi-level BOM?" is a question with one answer (yes). "How does your system handle a BOM revision when the customer changes specifications mid-production?" is a question that reveals actual capability.
Technical architecture requirements. Unless you have a genuine technical constraint (on-premise only, specific database, specific cloud provider), do not prescribe the architecture. Let the vendor propose what they know works.
Boilerplate legal terms. Save the legal review for the shortlisted vendor. Including 10 pages of terms in the RFP discourages smaller vendors (who often provide better fit for SMBs) from responding.
Evaluating Responses
The evaluation should answer three questions per vendor:
1. Do they understand the problem? Read the proposed approach section. Does it reference your specific problems, or is it a generic description of their product? A vendor who understood the problem will describe how their system handles your pricing logic, your supplier coordination model, or your quality documentation requirement — not how their system works in general.
2. Is the cost realistic? Compare the cost breakdown to the scope. If a vendor quotes S$20,000 for a system that another vendor quotes S$200,000, one of them has misunderstood the scope. Neither number is inherently wrong — but the gap needs explaining.
3. Can they prove it? References from similar SG manufacturers are the strongest signal. A vendor who has built a quoting system for a precision engineering company can show you the result. A vendor who has only built for distributors is guessing about your manufacturing workflow.
The Discovery Alternative
For many Singapore manufacturers, the RFP process is overkill. If you already know you want a custom system (or a specific off-the-shelf product), skip the RFP and go straight to a paid discovery.
A paid discovery (typically S$1,500-S$3,000) produces the same output as an RFP response — a detailed scope, a cost estimate, and a timeline — but it is based on direct observation of your operation rather than a written description of it. The vendor (or custom developer) spends a week understanding your workflow before proposing a solution.
Start Canyon offers both paths: if you want to run a formal RFP process, our vendor selection support (S$3,000-S$8,000) produces an independent requirements document, scorecard, and recommendation. If you want to go direct, the paid discovery produces a build plan and fixed quote in one week.