Enterprise Bid SOP for RFP/RFT/RFI/ITT
Bid Process - Short Version
Bid Process - Formal Process
Please refer to the above SOP for Enterprise Bid Management:
what are the key roles, responsibilities and accountabilities in a virtual bid team;
•
who should do what in what format by when for a bid submission
•
Bid Risk management
Enterprise bid is a high cost and low winning rate practice. So we have to qualify the
opportunity before investing in major efforts across BUs and FUs to submit a bid.
We would also have to verify whether we do have the real customer relationship before proceed
with the bid, because it often needs a lot of internal context and internal information to truly
customise the solution proposal and commercial proposal to what the customer really wants.
Bid automation - roadmap
(Also, a possibly strategic proposal is to leverage LLM/AI to dramatically reduce the cost of
HVLC(High Volumes Low Chance) bids, and speed it up to near real time. One solution is to
uplift the SHRBot pilot, or asking ISG to create a similar tool in Bid Portal, so
AE/Presales/Productologist/bid manager can "simply" upload the RFP/RFT etc documents, and
generate feasibility analysis, custom feature list, solution proposal draft and commercial proposal
drafts for the review/revising of bid team. We have been manually piloting this approaches over
the past 6 months. Question - should this initiative be aligned with Enterprise Surface and/or
Studio 4.0? This initiative is for so called HVLC (High Volume Low Chance) sales demands. )
Sensei in Bid Management Process
Sensei's Role in Bid Management
Sensei normally plays a "technical bid architect" role within the virtual bid team, being the
solution owner, responsible ( as a technical coordinator and facilitator ) for completing any
technical-related docs and forms per submission package request and conducting PoCs and
Demo with the customers and stakeholders.
Below is a detailed list of all Bid roles during the bid process for bid submissions:
BD & Sales Lead
Owner of customer relationship;
•
Managing Org/Account/Customer relationships
•
Account owner;
•
Define the account strategy
•
Account Responsible.
•
draft out customer stakeholder map;
•
clarify customer's real intention, objective, expectations, and real concerns.
•
Keep gauging the chance of winning with the bid team.
•
Identify the winning paths and approaches to towards a PO, via defined & achievable
•
roadmaps such as LOI and MOUs.
Evaluate the values and roles or 3rd party partners.
•
Understand our competitors
•
Bid Manager:
Owner of deliverables & bid planning per deadlines
•
Lead and Coordinate with entire team and ensure we align with the given opportunity
•
Accountable for bid plan, follow-ups, proposal structure, RFP forms
•
Owner of Bid templates.
•
Final reviewer and ensure compliance is met
•
Leading and Managing internal Slack bid channels
•
Managing Google bid folders and working versions.
•
Productologist:
Owner of commercial proposal including BC
•
Organising UI/UX Demos
•
Requirement scoping, including user roles, use cases and user stories/journeys elaborations.
•
Responsible for preparing technical questions in the scoping phase, and
•
Identify a list of project assumptions, gaps, risks, unknowns and concerns assisted by Sensei
•
Sensei
Owner of technical proposals; Support PoC, Demo and Q&As.
•
Owner of E2E solution proposals and all technical related proposals
•
Join in client and/or partner calls for technical Q&A, e2e architecture alignment, and
•
solution/service/consulting proposals.
Accountable for reviewing the technical content and ensuring the technical solution aligns
•
with the requirement.
Technical coordinator and facilitator for Builder internal Product teams, Platform teams and
•
Service (including BCare) teams.
Be the Engineering owner, filling in any technical solution gaps.
•
Able to engage client technical architects for all PoC requirement.
•
Support demos (But Sensei doesn't do UI/UX mockups or art designs for AR/VR/XR/MR
•
request - these are not in Sensei's technical scope)
Other Roles:
Please refer to the Bid Process SOP
•
Inputs into Sensei
Mandatory Account questions
The client: Is this VIP/CIP account? Is it Solo, SMB or Enterprise?
•
Budget Expectation - Is this Minor/Medium/Major opportunity? (Minor: Below $50K ;
•
Medium: Btw $50K- $100K; Significant $100K-200K; Major : >$200K)
Is this a Qualified opportunity? (Decision to bid already made by Senior Management for
•
strategic purpose)
Where is it hosted?
•
What are the deadlines/timelines for the bid to be submitted.
•
Mandatory Technical Questions:
what is the client buying? (Components, App, solution, or service?)
•
A high level summary of the requirement (customer problem statement; pain points)
•
Industry Information: which sector?
•
What are the platforms and tech stack to be built?
•
where is it hosted? (On-premise, Cloud, Hybrid etc)
•
Any SLAs? (Non-functional and service requirements if any)
•
external services to integrate with?
•
Compliances & regulatory?
•
Non-Mandatory fields
What are the exact deliverables of the RFP? (submission set)
•
Does Sensei Wiki already have the reusable artefact/deliverable templates?
•
Software: Demo, Mockup, UIUX designs needed
•
Doc formats: Word, Excel, Powerpoint, etc
•
Design artefacts: Architecture diagram, solution proposals, functional, non-functional
•
requirement including SLA, compliance and service requirements etc.
Builder cards.
•
Is the productologist required during qualification? If yes, what is the exact request?
•
Who are the competitors?
•
Do we have a real customer/account/organization relationship? Or do we go through a
•
partner?
What is the customer procuring? (optional)
•
What are we selling ? (optional) e.g App, components, integrated solution, hosted services
•
and/or business consulting, revamping Legacy Applications, building ERP software's?
Customer Stakeholder Map
•
Additional Information (if any)
•
Outcomes from Sensei
Sensei in RFP process should try to complete at least Level-0 architecture in the Technical Solution
Proposal per the defined Sensei CF Process:
Private (https://app.clickup.com/10553282/docs/a21y2-63288/a21y2-1183875)
Level-0 Architecture - deliverables
1. Stage: Sales & Bids
2. Purposes:
a. Scoping: Identify the scope of our solution proposal:
a. what's in Builder's scope;
b. what's in the client (customer's scope)
c. what's in our 3rd party partners
b. Integrations:
a. what are the external services (those outside client domain) that our
solution needed to interact with?
b. what are the internal services (inside the client remit) that our solution
would need to interact with?
3. Google bid folders:
a. Dubai GCC region (owner: @Priya Sahani ) https://drive.google.com/drive/folders/15FtB
3zmEcD0tqTfbfW8D8EE3AwLfR-KA
b. Other regions:
4. Solution Template - Outlines (in PPT or Doc or any format)
i. 5x functional views (Mandatory)
a. Context architecture (A sample image below: Purpose - to identify
all external services and internal services that our solution needs to
interact with )
b. Components architecture (sample below: Purpose : to explain the
internal structure of our solutions per enterprise design patterns and
Builder feature patterns )
c. Business process architecture. (Refer to e.g. Mermaid Diagrams -
Purpose : to elaborate UI/UX workflows of our solution; and to align
with our BC's journeys and feature flows. Note: you don't have to
expose BB blocks but you SHOULD at least expose all features, similar to
Component Architecture )
d. Data Models (SQL or NOSQL schema per customer demand; LLMs for
automation. Purpose : to define the high level data schemas and
logical data models for our who solutions. Make sure key data scoping
and data requirements are being captured and solutonised .)
e. Deployment & Hosting architecture (Private (https://app.clickup.com/1
0553282/docs/a21y2-63288/a21y2-925055) Purpose : Explain how to
host our solutions exactly, and in what hosting environments, per what
service release process, how many environments and what are the key
service release process )
ii. Non-functional Views (Mandatory)
a. All regulatory compliance requirements
b. Specific solutions and answers to any Non-functional Requirements and
Service Requirements, e.g.
i. Security
ii. Privacy (including compliance, auditing and access controls)
iii. Performance & Scalability
iv. HA and DR per BC (Business Continuity)
v. Backup, archive and restorations per BC
vi. Auditing & Logging
vii. Service Management and SLA reporting.
viii Supportability etc
.
iii. Record all technical assumptions, unknowns, risks, gaps and concerns in L0
stage as early as possible. For more details, refer to Private (https://app.clickup.co
m/10553282/docs/a21y2-63288/a21y2-1183875)
