Skip to main content
primd
Operations / Robotics

From RFQ inbox to quote, without losing the thread

What a robotics integrator actually needs between the first spec sheet and a number someone will defend in a meeting.

A four-step sequence from inbound RFQ to approved quote, with a human approval gate before the price is sent.

An integrator’s quoting process rarely fails at the pricing. It fails at the part nobody writes down: someone reads a PDF, remembers a similar job from eighteen months ago, checks whether that gripper is still available, and asks an engineer a question in a chat thread that never gets attached to anything.

Two weeks later the customer asks why the number changed, and the answer lives in four places.

The thread is the asset

The useful unit of work here is not the quote. It is the thread: the spec sheet, the assumptions someone made about it, the questions that came back, and the version of the answer that was actually sent.

Automating “generate a quote” without capturing the thread produces a faster version of the same problem. You get a number sooner and still cannot say how it was reached.

So the first thing to build is not a model call. It is a place where an inbound RFQ becomes a record with a stable identity, and every subsequent artifact attaches to that identity: the extracted requirements, the questions, the component decisions, the sent document.

What the machine should do first

Extraction, not judgment.

Given a spec sheet, an agent can reliably pull payload, reach, cycle time, duty cycle, environment, mounting constraints, and the certifications the customer named. That work is tedious, high-volume, and checkable, and checking a table is much faster than assembling one.

What it should not do first is choose the cell layout or commit to a lead time. Those depend on knowledge that lives in your engineers’ heads and in supplier conversations that are not in any document. An agent that guesses there produces a plausible answer with no trace, which is worse than no answer.

Make the gate the interface

Put the human approval where the cost of being wrong is highest: before a number reaches the customer.

The gate should present three things and nothing else. What the system extracted. What it assumed. What it would send. A reviewer who has to open the source PDF to check the gate is not being helped by it.

When the gate is designed properly, two useful things follow. The reviewer’s corrections become training data for the extraction step, because you now know which fields get changed and how often. And the trace of what was assumed is already written down when the customer asks in a month.

The failure mode nobody plans for

The thread survives the first quote and dies on the revision.

A customer comes back with a changed requirement, someone opens the original record, and the fastest path is to start a new one. It is faster because the tooling made it faster, and after a quarter the archive is full of quotes with no lineage, each one a snapshot of a conversation that no longer exists.

The fix is unglamorous: a revision has to be cheaper to create than a duplicate. If it is not, people will duplicate, and no policy will stop them.

What to measure

Not time saved. Time saved is the last thing to measure, because it is the easiest to fake and the hardest to attribute.

Measure how often the reviewer changes an extracted field, and which one. Measure how many RFQs reach a sent quote without a question going out. Measure how long a thread sits waiting on an engineer.

Those three numbers tell you where the next piece of automation belongs. Time saved tells you whether the last one worked, which you will find out anyway.

Operations / Robotics

從詢價信箱到報價,過程不斷線

系統整合商在收到第一份規格書、到報出一個有人願意在會議上辯護的數字之間,真正需要的是什麼。

從收到詢價到核准報價的四步驟流程圖,價格寄出前有一道人工核准關卡。

系統整合商的報價流程,很少壞在算價格。它壞在沒人寫下來的那一段:有人讀了一份 PDF,想起十八個月前類似的案子,去確認那款夾爪是不是還買得到,然後在一個永遠不會 被歸檔的聊天串裡問了工程師一個問題。

兩週後客戶問為什麼數字變了,答案散在四個地方。

真正的資產是那條「線」

這裡有意義的工作單位不是報價單,而是那條線:規格書、有人對它做的假設、回來的問 題,以及實際寄出去的那個版本的答案。

不先把這條線接起來就去自動化「產生報價」,只會得到同一個問題的加速版。你更快拿到 一個數字,但仍然說不出它是怎麼來的。

所以第一件要做的不是呼叫模型,而是讓一封進來的詢價變成一筆有穩定識別碼的紀錄,之 後所有產物——抽出來的需求、問過的問題、選件決策、寄出的文件——都掛在這個識別碼 上。

機器該先做的事

抽取,不是判斷。

給一份規格書,代理人可以穩定地抽出負載、臂展、節拍時間、工作週期、環境條件、安裝 限制,以及客戶指名的認證。這件事繁瑣、量大、而且可查核——人三十秒可以確認一張 表,六十秒可以改完。

它不該一開始就決定產線佈局或承諾交期。那些取決於工程師腦袋裡、以及不在任何文件裡 的供應商對話。代理人在那裡用猜的,會產出一個看起來合理但沒有軌跡的答案,那比沒有 答案更糟。

把關卡當成介面來設計

把人工核准放在犯錯代價最高的位置:數字送到客戶手上之前。

這道關卡應該只呈現三件事——系統抽出了什麼、它假設了什麼、它打算寄出什麼。如果審 核的人還得打開原始 PDF 才能檢查,這道關卡就沒有在幫他。

關卡設計對了,會順帶得到兩件事。審核者的修正變成抽取步驟的訓練資料,因為你現在知 道哪些欄位常被改、改多少。而「我們當時假設了什麼」的軌跡,在客戶一個月後來問之 前,就已經寫好了。

該量什麼

不是省下的時間。省下的時間是最後才該量的,因為它最容易灌水,也最難歸因。

量審核者修改抽取欄位的頻率,以及改的是哪一個。量有多少詢價案是一個問題都不必問就 完成報價的。量一條線卡在工程師身上多久。

這三個數字會告訴你下一段自動化該做在哪裡。省下的時間只會告訴你上一段做得如何—— 那件事你本來就會知道。

Operations / Robotics

从询价邮箱到报价,过程不断线

系统集成商在收到第一份规格书、到报出一个有人愿意在会议上辩护的数字之间,真正需要的是什么。

从收到询价到批准报价的四步骤流程图,价格发出前有一道人工审批关卡。

系统集成商的报价流程,很少坏在算价格。它坏在没人写下来的那一段:有人读了一份 PDF,想起十八个月前类似的项目,去确认那款夹爪是不是还买得到,然后在一个永远不会 被归档的聊天串里问了工程师一个问题。

两周后客户问为什么数字变了,答案散在四个地方。

真正的资产是那条「线」

这里有意义的工作单位不是报价单,而是那条线:规格书、有人对它做的假设、回来的问 题,以及实际发出去的那个版本的答案。

不先把这条线接起来就去自动化「生成报价」,只会得到同一个问题的加速版。你更快拿到 一个数字,但仍然说不出它是怎么来的。

所以第一件要做的不是调用模型,而是让一封进来的询价变成一笔有稳定标识的记录,之后 所有产物——抽取出的需求、问过的问题、选型决策、发出的文件——都挂在这个标识上。

机器该先做的事

抽取,不是判断。

给一份规格书,代理可以稳定地抽出负载、臂展、节拍时间、工作周期、环境条件、安装限 制,以及客户指名的认证。这件事繁琐、量大、而且可核查——人三十秒可以确认一张表, 六十秒可以改完。

它不该一开始就决定产线布局或承诺交期。那些取决于工程师脑袋里、以及不在任何文件里 的供应商对话。代理在那里用猜的,会产出一个看起来合理但没有轨迹的答案,那比没有答 案更糟。

把关卡当成界面来设计

把人工审批放在犯错代价最高的位置:数字送到客户手上之前。

这道关卡应该只呈现三件事——系统抽出了什么、它假设了什么、它打算发出什么。如果审 核的人还得打开原始 PDF 才能检查,这道关卡就没有在帮他。

关卡设计对了,会顺带得到两件事。审核者的修正变成抽取步骤的训练数据,因为你现在知 道哪些字段常被改、改多少。而「我们当时假设了什么」的轨迹,在客户一个月后来问之 前,就已经写好了。

该量什么

不是省下的时间。省下的时间是最后才该量的,因为它最容易注水,也最难归因。

量审核者修改抽取字段的频率,以及改的是哪一个。量有多少询价是一个问题都不必问就完 成报价的。量一条线卡在工程师身上多久。

这三个数字会告诉你下一段自动化该做在哪里。省下的时间只会告诉你上一段做得如何—— 那件事你本来就会知道。

Operations / Robotics

Dari kotak masuk RFQ ke penawaran, tanpa kehilangan alurnya

Apa yang sebenarnya dibutuhkan integrator robotika antara lembar spesifikasi pertama dan angka yang berani dipertahankan seseorang dalam rapat.

Diagram empat langkah dari RFQ masuk sampai penawaran disetujui, dengan gerbang persetujuan manusia sebelum harga dikirim.

Proses penawaran seorang integrator jarang gagal di perhitungan harganya. Ia gagal di bagian yang tidak pernah ditulis siapa pun: seseorang membaca sebuah PDF, teringat proyek serupa delapan belas bulan lalu, memeriksa apakah gripper itu masih tersedia, lalu bertanya kepada seorang engineer di utas percakapan yang tidak pernah dilampirkan ke mana-mana.

Dua minggu kemudian pelanggan bertanya mengapa angkanya berubah, dan jawabannya tersebar di empat tempat.

Utasnya adalah asetnya

Satuan kerja yang berguna di sini bukan penawarannya, melainkan utasnya: lembar spesifikasi, asumsi yang dibuat seseorang atasnya, pertanyaan yang kembali, dan versi jawaban yang benar-benar dikirim.

Mengotomatiskan “buat penawaran” tanpa menangkap utasnya hanya menghasilkan versi lebih cepat dari masalah yang sama. Angkanya datang lebih awal dan Anda tetap tidak bisa menjelaskan bagaimana angka itu diperoleh.

Jadi yang pertama dibangun bukan panggilan model, melainkan tempat di mana RFQ masuk menjadi sebuah catatan dengan identitas yang stabil, dan setiap artefak berikutnya menempel pada identitas itu.

Yang harus dikerjakan mesin lebih dulu

Ekstraksi, bukan penilaian.

Dari sebuah lembar spesifikasi, agen dapat menarik dengan andal beban, jangkauan, waktu siklus, siklus kerja, kondisi lingkungan, batasan pemasangan, dan sertifikasi yang disebut pelanggan. Pekerjaan itu membosankan, bervolume tinggi, dan bisa diperiksa — manusia mengonfirmasi sebuah tabel dalam tiga puluh detik.

Yang tidak boleh dilakukannya lebih dulu adalah memilih tata letak sel atau menjanjikan waktu pengiriman. Hal itu bergantung pada pengetahuan yang ada di kepala para engineer dan pada percakapan dengan pemasok yang tidak tercatat di dokumen mana pun.

Jadikan gerbangnya sebagai antarmuka

Letakkan persetujuan manusia di tempat biaya kesalahannya paling tinggi: sebelum sebuah angka sampai ke pelanggan.

Gerbang itu harus menampilkan tiga hal saja — apa yang diekstraksi sistem, apa yang diasumsikannya, dan apa yang akan dikirimnya. Peninjau yang masih harus membuka PDF aslinya tidak sedang dibantu oleh gerbang itu.

Apa yang diukur

Bukan waktu yang dihemat. Waktu yang dihemat paling mudah dipoles dan paling sulit diatribusikan.

Ukur seberapa sering peninjau mengubah sebuah field hasil ekstraksi, dan field yang mana. Ukur berapa banyak RFQ yang sampai ke penawaran terkirim tanpa satu pun pertanyaan keluar. Ukur berapa lama sebuah utas menunggu seorang engineer.

Ketiga angka itu memberi tahu Anda di mana potongan otomasi berikutnya seharusnya berada.

Satu catatan yang berguna. Kalau memang ada.