Skip to content
I'm Shuo
Go back

Presales / Solution Architect Notes (1): What Does Presales Actually Do? Is Writing Bidding Proposals Hard?

This post is an AI translation of the Chinese original. If there are any discrepancies, the Chinese version takes precedence.

I want to start a new series about my day-to-day life as a presales solution architect, and also share what AI has changed for me in this role, plus a few practical AI tips.

Background: What Presales Actually Does

A bit of context first. I work as a solution architect, which in our company basically means presales. Most of the time, I work with sales to move opportunities forward. Once sales gets an RFP (Request for Proposal), my side needs to prepare a full set of materials: written bidding documents, PPT bidding decks, work breakdowns, delivery cost estimates, and then I usually travel to the client site to present the proposal myself.

The Real Pain Point: PPT Proposal Decks

In the full workflow, the most painful part is usually not “I do not know how to write the text proposal.” It is converting that text proposal into a PPT deck for bidding. The challenge is not lack of content. The challenge is meeting all three at once: clear logic, not text-heavy, and visually good while still easy to present. As an engineering person, visual design is honestly my biggest weakness.

In most cases, clients do not have the patience to read long text documents closely. Their understanding of your solution comes mainly from what you show and explain during the presentation, then they ask questions based on that. So the quality of the PPT proposal directly affects communication efficiency and trust.

Reality: Why This Is Harder in Smaller Companies

Another practical difficulty for presales solution architects: In smaller companies, presales is usually not split by very narrow vertical domains. Instead, you are assigned to a broad capability area, like software development. It sounds clear on paper, but in practice you get all kinds of opportunities: robotics embedded software, cloud virtualization, connected vehicle software, factory scheduling systems, deep learning model R&D, and so on. They are all somewhat related to your domain, but their business context, goals, and evaluation criteria are very different.

So here is the core issue: people have cognitive limits. Even with years of experience, you cannot deeply understand every adjacent industry. What do you do when a project is from a domain you barely know?

Before LLMs: How I Used to Gather Information

Before large models, I mainly relied on three information sources.

First, internal company knowledge. We are a global company, so our intranet has many historical project artifacts. I usually start by searching for topics close to the current bid: forum threads, shared docs from colleagues in different regions, and past project proposals.

Second, public search. Since most of our clients are in China, I intentionally do cross-language searches. For example, I use Google with filetype:pdf and switch languages by industry. For automotive topics, I often search in German and Japanese. This gives me materials from contexts that differ from Chinese-language sources, which is useful for cross-reference.

Third, academic papers. Unknown industry requirements are often either cutting-edge or based on common technical patterns. Reviewing survey papers helps me quickly build a high-level understanding of the industry and business domain: how problems are defined and how solutions are decomposed.

That said, this workflow is not very friendly to junior presales colleagues. Most public materials are still generic knowledge. Turning that into precise responses for a specific client scenario is hard. In the end, you still need your own technical judgment to draw analogies, diverge, converge, and keep digging before you can really start proposal writing.

At the core, this is very similar to writing a research paper: Information collection -> understanding -> analysis -> independent thinking -> (optional experiments) -> writing.

In the AI Era: My Three-Step Workflow

In the AI era, proposal work for presales has become much easier. The biggest drop in difficulty is in information collection and initial understanding. My current approach is roughly this:

  1. Research unfamiliar domains first Use a strong model’s Deep Research capability to generate an industry brief aligned with the bidding goal, then use it to close initial knowledge gaps and prepare the next steps.

  2. Organize and filter information Choose the strongest model you can reasonably afford. Do not ask for a full solution immediately. First, ask foundational questions: “What is XXX?” “How does YYY work?” If a new concept appears, such as ZZZZ, keep probing: “Can ZZZZ be understood as something similar to AAAA in my familiar domain?” This loop maps a new domain onto your existing experience and helps you build fast, shallow-but-usable understanding.

  3. Generate a solution and do cross-model review After the first two steps, you can often reach the equivalent of a 1-3 year practitioner in that domain. Then ask the model to generate a first solution against the RFP, and keep challenging it: “This design is not reasonable because…” “This scenario is missing…” Once the first version is ready, switch to another model for review (for example, GPT to Claude) and run another round of critical discussion. Usually 3-5 cycles are enough, depending on how unfamiliar the domain and scenario are.

Boundary: AI Helps a Lot, But It Is Not Fully Automatic

One thing must be clear: If you expect AI to directly produce a perfect bidding proposal, that is basically unrealistic. To get close to that, the operator needs to be very strong already. You need deep domain expertise first; AI mostly helps with speed and gap-filling. For someone like me, who has to fight across multiple industries, this workflow is already good enough. In many cases, reaching a 60-70 quality level with materials that are presentable and deliverable is already highly valuable.

And we all know this: Bidding outcomes are never determined by technical方案 alone. Commercial relationships, client trust, and organizational coordination all matter. In many presentations, the goal is not to be spectacular. The goal is to avoid failing, stay coherent, handle questions, and build credibility.

That Is It for This One

I will stop here for part one. In the next posts of this series, I will keep talking about presales bidding work: the real workflow of this role, and specific AI practices I use in different scenarios.


This post is licensed under CC BY-NC-SA 4.0. Please credit the author and include a link back when sharing.

Share this post:

Next Post
Switching from Ubuntu Desktop to Linux Mint: Common Setup Notes