---
title: "MANCOOT 與兩好三壞：工程師轉業務十一年學到的成交心法"
url: https://stanleylin.tw/mancoot-sales-framework/
author: 林毓晟（Stanley Lin，史大）
published: 2026-08-08
updated: 2026-08-09
categories: 職涯與自我成長、銷售與溝通
description: "工程師轉 B2B 業務，先別急著講規格。用 MANCOOT、兩好三壞與三次拜訪問題，盤出需求、決策路徑與成交時機。"
---

# MANCOOT 與兩好三壞：工程師轉業務十一年學到的成交心法

2015 年，我第一次當業務。主管要我做三十分鐘 role play，客戶一直打斷我，我卻連對方的決策者是誰都沒有問到。

主管安排黑臉白臉的角色演練，模擬一個很難應付的客戶，要我做三十分鐘簡報。真正被檢查的不是產品講得多完整，而是被質疑時還問不問得出成交資訊。

今天再和當年的主管吃飯，我才發現：後來做簡報、講課與企業 AI 導入，底層仍是同一件事。

我想把工程師找參數的習慣，翻譯成 B2B 業務的決策地圖。

## MANCOOT 是什麼？業務要掌握哪七項資訊？

MANCOOT 是 B2B 成交資訊盤點框架，包含預算、決策者、需求、競爭者、組織圖、個人利益與時程，用來找出案子還缺哪塊證據。

- **M — Money**：預算從哪裡來，是否已編列。
- **A — Authority**：誰能核准，誰能否決。
- **N — Need**：不處理會造成什麼營運問題。
- **C — Competition**：競爭的不只同業，也可能是不改變。
- **O — Organization**：使用、影響、採購與決策角色怎麼連。
- **O — Other personal win**：參與者個人希望降低什麼風險。
- **T — Time**：為何是這個時間，延後會發生什麼。

很多人以為業務資訊越多越容易成交，其實剛好相反。沒有整理成決策關係時，滿手會議紀錄仍然不知道下一步該找誰。

如果你是業務主管（或要預測營收的老闆），團隊說客戶很有興趣時，七格裡有幾格真的有證據？

## 「兩好三壞」怎麼判斷一個案子值不值得追？

兩好是對客戶好、對公司好；三壞是 Why buy、Why you、Why now。五個問題都成立，成交才兼顧價值、能力與時機。

對客戶好，是解決真問題；對公司好，是毛利、交付能力與風險合理。只對一邊好，成交之後通常會用客訴或虧損補課。

Why buy 問為什麼要改；Why you 問為什麼選你；Why now 問為什麼現在決定。三句不是話術，而是客戶內部提案必須回答的理由。

可以把 MANCOOT 與兩好三壞放在同一頁：前者找資訊，後者做決策。每次拜訪後更新證據，不確定就標未知，不要把感覺寫成事實。

這和[用兩好三壞找到 B2B 目標客群](/品牌定位：打造獨特市場優勢與吸引目標客群的關/)的邏輯相同：讓客戶更清楚地做選擇，而不是把壓力當成交技巧。

## A、B、C 級客戶應該怎麼安排拜訪？

分級不是替客戶貼身價標籤，而是依機會價值、關係缺口與決策時程分配準備成本。每次接觸都必須帶來新的決策資訊。

我早期被要求 A 級客戶每月拜訪兩次、B 級每季一次、C 級半年一次。真正困難的是每一次都不能重複講同一套產品簡報。

市場趨勢、競品動向、導入風險、成本分析與內部組織變化，都可以成為新價值。最後你會被迫理解工程、採購、廠長、IT、品保與財務看同一案子的不同角度。

老闆算資源時，要看每個機會投入的準備、拜訪、試做與內部協調工時。大案子不一定值得追，資訊長期空白的案子可能只是昂貴的希望。

## 工程師轉業務，怎麼把技術變成成交能力？

工程背景的優勢是能追因果與限制；風險是急著講規格。把每個功能翻成時間、成本、風險或營收，技術才會進入客戶的決策。

「跨域翻譯」不是把術語說得更簡單，而是把產品能力對應到不同角色願意承擔的商業結果。

例如工程在意能否整合，採購在意總成本，財務在意回收依據，使用者在意是否增加負擔。簡報不該只有一個版本的規格順序。

可參考 Salesforce 對 [顧問式銷售](https://www.salesforce.com/resources/articles/consultative-selling/)的說明：重點是理解客戶問題並共同形成解法，而不是急著推產品。

也可以接著看[通才如何做品牌定位](/generalist-brand-positioning-ai-era/)。做十年業務和把第一年重複十次的差別，就是你有沒有把每次未知變成下一次可用的判斷。

## 第一次拜訪，MANCOOT 應該先問哪三題？

先問現況卡在哪、誰會受影響、什麼時間點不處理就會更痛。不要急著問預算，先確認客戶是否真的有一個值得被處理的商業問題。

我後來才懂，工程師出身最容易犯的錯，是聽到問題就急著開始解。業務的工作不是搶著給答案，而是幫客戶把尚未說完整的決策條件攤開。

第二次再補決策圖：誰使用、誰反對、誰付錢、誰承擔導入風險。第三次才談競爭與時程。這不是拖延成交，而是避免把一個人說的需求誤當成整家公司的需求。

客戶若連「不處理會怎樣」都說不清楚，你最有價值的下一步不是報價，而是幫他把問題定義好。