A field guide for solution architects and bid teams responding to Microsoft Power Platform tenders
Most Power Platform bids are not lost on technology. They are lost on process: a missed mandatory criterion, a vague “compliant” that hid heavy custom code, a licensing number the client could not reconcile, or a response that ignored the evaluator’s own numbering.
After years of delivery, I am learning how to bid how to bid for Power Platform projects across the region, I have found that the teams that win consistently treat a response as a structured, repeatable product, not a one-off document. This post walks through that structure end to end, with wording you can adapt.
RFI vs RFP: know what you are answering
These two documents look similar but reward different behaviour.
| RFI (Request for Information) | RFP (Request for Proposal) | |
|---|---|---|
| Client intent | Learn the market, build a shortlist | Select a vendor and solution |
| What to submit | Capabilities, references, approach | Committed solution, plan, team and price |
| Pricing | Indicative ranges at most | Firm, itemised, with validity period |
| Length | Short and focused | Detailed and mapped to every requirement |
| Goal | Get invited to the RFP | Score highest on the evaluation matrix |
If it is an RFI, resist the urge to over-deliver. A tight, confident response with strong references gets you shortlisted. An RFP is different: everything must trace back to a numbered client requirement.
The 8-step process
Step 1: Make a go/no-go decision on day one
Before writing a word, check:
- Fit: Do the requirements genuinely suit Power Platform, or is the client really asking for a packaged ERP or a custom-coded platform?
- Licensing position: What Microsoft 365, Dynamics 365 or Power Platform entitlements does the client already hold?
- Mandatory criteria: Local presence, trade licence, minimum turnover, specific certifications, in-country data hosting. Failing one mandatory item can disqualify you regardless of quality.
- Competition and incumbency: Is the result already wired for someone else?
- Deadline realism: Can you produce a quality response, including estimates and review, in the time available?
A disciplined “no” saves your team’s energy for bids you can win.
Step 2: Shred the RFP into a compliance matrix
Extract every “shall”, “must” and “should” into a spreadsheet. This becomes your control document for the whole bid.
| ID | Requirement | Response | Section reference |
|---|---|---|---|
| FR-012 | Workflow approvals with escalation | Compliant (configuration) | 4.2 |
| NFR-004 | Arabic RTL interface | Partial (see assumptions) | 4.5 |
| INT-003 | Integration with legacy ERP via SOAP | Custom | 4.4 |
Use four honest response values: Compliant (out of the box or configuration), Partial, Custom (needs code or extension), and Not supported. Evaluators and, later, delivery teams will thank you for the honesty.
Step 3: Send clarification questions before the cut-off
This is the most underused step. Good questions reduce risk, reveal the client’s priorities, and show the evaluator you understand the problem. Cover user counts by persona, existing licences, integration endpoints and API availability, data volumes for migration, hosting and security standards, evaluation weightings, and any fixed go-live dates.
Here is a template:
Subject: Clarification Requests – [RFP Reference No.]
Dear [Procurement Contact],
Ahead of the clarification deadline, we would appreciate your guidance on the following:
- What is the expected number of users by persona (internal, external, administrators), and the anticipated growth?
- Which existing Microsoft licences (Microsoft 365, Dynamics 365, Power Platform) should we take into account?
- Which systems must be integrated, and are API specifications available?
- What are the data sources and approximate volumes for migration?
- Which hosting, data residency and security standards apply?
- Can you share the weighting between technical and commercial evaluation criteria?
- Is the proposed timeline fixed, and are there hard go-live dates?
Kind regards, [Name, Title, Company]
Step 4: Design the solution, not just the answer
Map each requirement group to the right Power Platform capability:
- Dataverse as the secure, governed data layer
- Model-driven or Canvas apps for internal users
- Power Pages for external portals
- Power Automate for workflow and integration orchestration
- Power BI for analytics
- Copilot Studio and AI Builder where AI genuinely adds value
- Azure services (Functions, Logic Apps, API Management) and the on-premises data gateway for integration
Draw a clean, one-page architecture diagram early. It anchors the written response and the estimate.
Step 5: Estimate with assumptions as your shield
Build effort by phase and role, then price licensing separately from services. Your assumptions section is your main protection, so write it deliberately: number of integrations, number of apps, migration volumes, client availability for workshops and UAT, and the languages supported.
Step 6: Write the response
The structure below works well for RFPs. For RFIs, keep sections 1 to 4, a condensed 5, and section 11.
Step 7: Review like an evaluator
Run three passes: a compliance pass against the matrix, a commercial pass to check that pricing, licensing and assumptions agree with each other, and a red-team pass where someone reads it as a sceptical evaluator with the scoring sheet in hand.
Step 8: Submit with margin
Follow the exact portal, file naming, page limits, envelope separation (technical and commercial), signatures and validity requirements. Submit at least 24 hours early. Portals fail, and late is late.
The response structure, with sample wording
1. Cover letter
Dear [Evaluation Committee],
[Company] is pleased to submit our response to [RFP Title / Reference No.]. We understand that [Client] aims to [business objective, in the client’s words].
We propose a solution built on Microsoft Power Platform that delivers [outcome 1], [outcome 2] and [outcome 3], supported by a delivery approach proven on [similar engagements]. This proposal remains valid for [90] days from the submission date.
Sincerely, [Name, Title, Contact details]
2. Executive summary (one page)
Your challenge: [Two or three lines restating their pain points.] Our solution: [What we will build, in business terms.] Why us: [Microsoft partnership, certified team, regional references, accelerators.] Outcomes: [Measurable benefits, for example approval cycle time reduced by X%, manual effort reduced by Y hours per month.] Timeline and investment: [Go-live in X weeks; pricing summary in Section 9.]
3. Understanding of requirements
We understand that [Client] requires [capability 1], [capability 2] and [capability 3]. We have noted the following constraints: [data residency, integration with SAP or Oracle, Arabic and English support, single sign-on]. Our assumptions are listed in Section 10.
4. Proposed solution
Use one repeatable pattern for every requirement group so evaluators can score quickly:
Requirement [ID]: [summary] Our approach: [Component, for example a model-driven app on Dataverse with business process flows.] How it meets the need: [Two or three lines.] Compliance: [Out of the box / Configuration / Custom extension]
Then cover these areas explicitly:
- Architecture: data, app, automation, integration and AI layers.
- Security: Microsoft Entra ID, security roles, business units, field-level security, DLP policies, auditing.
- Data residency and compliance: the Power Platform environment region (for example UAE North), plus applicable regulation such as the UAE personal data protection law, the KSA equivalent, and sector or government information-security frameworks. Confirm the exact requirements the client cites rather than assuming.
- Localization: Arabic right-to-left layouts, bilingual UI and content, regional date and number formats.
- ALM and governance: Dev, Test, UAT and Production environments; solutions as the unit of deployment; Azure DevOps or GitHub pipelines; Managed Environments; a Centre of Excellence approach.
5. Delivery methodology
We deliver through an agile approach across Discovery, Design, Build sprints, UAT, Go-live and Hypercare, with sprint reviews every [two] weeks and a monthly steering committee. Quality is enforced through [solution checker, automated testing, peer code review and pipeline quality gates].
6. Team and Governance
Present a role table (Solution Architect, Functional Consultants, Developers, Tester, Project Manager) with experience and relevant certifications such as AB-100, PL-600, PL-400 and PL-200. Put full CVs in the appendix.
7. Timeline
Phase-by-phase plan with milestones, client dependencies and a Gantt view.
8. Licensing and the Microsoft ecosystem
Licensing is recommended on a [per-app / per-user / pay-as-you-go] basis, derived from [number of users, number of apps, Dataverse capacity and Copilot Studio usage]. The client’s existing Microsoft 365 and Dynamics entitlements have been considered. Licensing is quoted separately from services and is subject to Microsoft’s pricing at the time of purchase.
9. Commercial proposal
Fixed price or time and materials per phase, a rate card, payment milestones, optional items (support, training), and clearly stated currency, VAT treatment and validity period.
10. Assumptions, risks and exclusions
Assumptions: The client provides timely access to environments and subject-matter experts; up to [N] integrations; data migration limited to [N] records. Risks and mitigations: Data quality risk is mitigated by profiling in Discovery; scope creep is mitigated by a formal change-control process. Exclusions: [Anything not in scope.]
11. References and case studies
Two or three relevant ones in a fixed format: client and industry, challenge, solution, results. Offer contactable referees where permitted.
12. Appendices
Compliance matrix, CVs, certificates, architecture diagrams, sample artefacts and company profile.
Tips that raise your evaluation score
- Mirror the client’s numbering and language. Evaluators score against their own checklist, so make it effortless to find each answer.
- Be honest about customization. Marking something “Compliant” when it needs heavy custom code is the most common source of disputes after award.
- Quantify outcomes. Tie every feature to a business result, not a product capability.
- Maintain a content library. Keep approved boilerplate for security, methodology and team bios, and customise only the first third of each response.
- Treat licensing as a first-class topic. It is the number clients challenge most. State your assumptions explicitly.
- Offer a short proof of concept or demo for shortlisted bidders.
Common mistakes to avoid
- Skipping the clarification window
- Copy-pasting a previous proposal with another client’s name still inside it
- Pricing licences and services in one opaque lump sum
- Ignoring data residency and Arabic language needs until late
- Burying the executive summary behind company history
- Submitting in the last hour
Final thought
A winning Power Platform response is clear, traceable and honest. If an evaluator can find every answer in seconds, trust your assumptions, and picture the solution running in their organisation, you have already done most of the work.
If you are preparing a bid and want a second pair of eyes on your compliance matrix or licensing assumptions, feel free to reach out.