Lecture 04. From a Lead to Formalized Pre-Sales

Chronology: 15 September 2026 · fourth session. Primary source: the complete transcript. Starting point: a contact obtained via a referral, event or content. Objective: move the lead toward a technical follow-up and the first formal pre-sales deliverables.

1. An event is the beginning, not the end, of the funnel

This session continues the conference topic, now treating it as a managed business-development system rather than mere networking.

The underlying sequence:

visibility / event
      ↓
first contact
      ↓
lead
      ↓
initial meeting
      ↓
identified pain point
      ↓
technical follow-up
      ↓
formal information exchange

A successful trip is measured not by the number of business cards handed out, but by contacts that lead to a specific next action.

2. A speaker is part of a campaign, not an isolated person on stage

The lecture makes an important point: a speaking slot works only when combined with preparation before the event and action afterwards.

Before the event

• Choose a topic for its relevance to the business objective;
• prepare the speaker;
• publish announcements;
• identify target companies and people;
• prepare supporting staff and case materials.

During the event

• The speaker attracts attention and establishes authority;
• the team works across the venue, makes contacts and listens for pain points;
• contacts and their context are recorded immediately.

After the event

• Conduct prompt follow-up;
• propose a specific next conversation;
• classify contacts, leads and opportunities internally.

3. Initial meeting: a customer assesses actual people, not only the company

Before the first substantial discussion, the team must do its homework: understand the prospective customer's profile, products, publicly documented technical areas and the roles of meeting participants.

In the lecture, the provider's presentation is divided into three broad parts:

1. Who we are: scale, geography, industries and delivery capability.
2. Why we can be trusted: case studies, processes, and relevant standards or certifications.
3. What similar work we have done: a small selection of case studies tailored to this particular audience.

A crucial rule is not to dump the entire portfolio on the customer. The chosen case studies must fit their context.

4. From presentation to discovery

The presentation only opens the door. The actual value appears when the provider begins asking concrete questions and demonstrates domain competence.

company story
   ↓
relevant cases
   ↓
technical questions
   ↓
pain point
   ↓
"we should talk about this separately"

The lecture metaphorically describes this as “putting a bandage exactly where it hurts”: the aim is not to solve the entire problem in the first meeting, but to demonstrate that you recognize the pain and possess the relevant skills.

5. Technical follow-up

Bring people who can speak knowledgeably about the specific technical domain to the next meeting. Continuity of faces is important: key participants from the initial encounter should not disappear entirely, forcing trust to be built from scratch.

The follow-up objectives in this course are to:

• clarify the customer's pain;
• demonstrate technical depth;
• understand the boundaries;
• avoid designing an entire product for free;
• move to a structured exchange of information.

6. RFI — Request for Information

An RFI is a request used by a prospective customer to evaluate a provider's capabilities. Its format may be as simple as a spreadsheet containing questions and columns for answers and evidence.

Common question groups include:

• company profile;
• relevant domains;
• engineering roles and capacity;
• tools;
• languages and technology stack;
• quality, safety and security processes;
• experience with standards and frameworks;
• laboratories, equipment and manufacturing capability;
• references or case descriptions approved for disclosure.

In major procurement processes several vendors often receive the same RFI, so the answers should be comparable, evidence-based and free of marketing fog.

7. RFQ — Request for Quotation

An RFQ requests more than a description of capability: it seeks an estimate of cost, scope and delivery time. This is more complex in embedded systems than merely counting engineer-hours, since it may involve:

• engineering effort;
• components;
• PCB and mechanical fabrication;
• assembly;
• test equipment;
• prototypes and redesign cycles;
• external laboratories;
• shipping and customs;
• samples and activities related to certification.

If an RFQ arrives before the technical problem has been defined adequately, estimation may be coarse or highly dependent on assumptions. That uncertainty must be made explicit.

8. RFC in this course

The lecture uses RFC to mean Request for Clarification—a structured request to clarify the proposed solution or problem statement.

Editorial clarification 01 — acronym policy

RFC does not have a single universal meaning in B2B procurement. In software engineering it often means Request for Comments, and individual companies may use other meanings. The course documents must therefore spell it out at first mention: RFC (Request for Clarification — terminology used in this course).

9. The proposal integrates earlier knowledge

A proposal should not appear out of thin air. It consolidates information already obtained from meetings, RFI, RFQ, RFC and the provider's own analysis.

meetings ─┐
RFI ──────┤
RFQ ──────┼──→ Proposal
RFC ──────┤
research ─┘

An initial proposal outline at this stage contains:

• executive / solution summary;
• understanding of the problem;
• assumptions and open questions;
• high-level architecture or approach;
• engineering workstreams;
• verification and validation intentions;
• team and resources;
• schedule and estimate;
• risks and dependencies;
• commercial model.

A fuller treatment of standards, commercial models and risk allocation follows in the next session.

10. Version control for pre-sales documents

The lecture recommends managing a proposal like any other controlled engineering artifact. A practical structure is:

0.1 → 0.2 → 0.3  internal drafts
          ↓
        1.0      external release
          ↓ client feedback
        1.1 → 1.2 internal work
          ↓
        2.0      next external release

The version number alone is not what matters. It must be clear:

• when the version was issued;
• who authored or owns it;
• what its revision history is;
• what changed following customer feedback;
• which exact version forms the basis for an estimate or decision.

11. Do not give away all the engineering before signing a contract

Pre-sales engineering has limits. The more finished design details a provider discloses, the more unpaid engineering it may surrender before any commercial decision.

An internal review should therefore ask:

• is the evidence sufficient to demonstrate capability?
• has the proposal turned into a free detailed design?
• are assumptions visible?
• is the estimate traceable?
• can the promises realistically be delivered?

12. Review questions

1. How does a lead differ from an accidental contact?
2. What is the purpose of an initial meeting?
3. Why must case studies be tailored to the customer?
4. How does an RFI differ from an RFQ?
5. Why does an embedded-project estimate include more than engineer-hours?
6. Why should RFC be expanded explicitly in each specific process?
7. What does a proposal consolidate from the preceding stages?
8. Why do pre-sales documents need version control?
9. Where is the boundary between demonstrating competence and providing engineering work for free?

13. Deliverable comparison table

14. Transition to 16 September 2026

The next step is turning the proposal into a mature engineering and commercial document: which standards and reference documents apply, how certification and conformity constraints affect the work, how to choose between Time & Materials and Fixed Price, and who actually bears each risk.