企业之交易，非止十项，或有二百，甚或更多。同此CPQ报价单，小者载之立现，二秒可成；大者则需三十至四十五秒方显。销售之员避而不改，盖因每易必引重算，致浏览器滞涩。报价遂分作数小单（盖系统难承其巨），而后须手自核之。

隘塞非常"CPQ慢也。"大抵有五处，而所治者存价理，非弃之也.

隘塞一：价规广度之评

价规之制，依报价计算而评。每规具广则（如“适用于所有报价行”），则遍历诸行。二百行三十价规，一算即六千之评。

其诊之方：计价规于组织。数无范围滤或范围过广之滤者。高规数与广范围之合，乃为显证。

其方：收束价规之域。每规当适其所需之最寡引线。调某品族之折者，当滤于其族，非遍行于众线。域滤之费微；无之则每算皆耗。

萨波他观诸构，独收束域，可减重算时六十，未易商理。

瓶颈二：产品规则之运行非所必需

产品规则验引线之组合（约束如“产品甲需产品乙”或“产品丙与产品丁不相容”），每变必发，评骘全引线之集

产品规则界定不周，每变皆遍及诸行，致显见迟滞于二百行之规。其症同于价规：数多、域广、每算之费高.

其解：若迁徙在域，则于RLM将验证式产品规则化为此CML约束；或于CPQ经典，则每规狭其审域。此法与价规之收束同式。

瓶颈三：定制报价计算插件（QCP）

CPQ经典版支持Apex语言编写的报价计算插件，于计算时运行。QCP可添加标准定价引擎原生未处理的定制逻辑。

有三式致QCP于规模之慢：

• 插件于报价行迭代多遍，而一遍足矣。重构为单遍即可。
• 插件于循环之中行SOQL之询。于循环之前，尽使诸询成批。
• 插件于并行安全时，序次处理诸行。当可行时，用Apex异步之式。

QCP乃最常见之深性能瓶颈。由深知CPQ之行与Apex之优者而审之，常得三至五倍之进。

瓶頸之四：每變更皆同步計算

CPQ 古典模式每條報價行變更即重算。二百行中，當代表編輯單一折扣時，即需全體重算。

CPQ 支持异步计算：将重算推迟至代表明确触发。其权衡在于代表在变更间会见到陈旧数据，然对于大额报价，此优于每键击皆悬停30秒。

配置之法：于CPQ配置设置中，启用"仅于计算动作时计算报价"之选项。训示代表，于批量变更后而非每项变更后点击计算。此变，于操作上有意义，然于报价宏大至需之者，可容。

凡中制引文（五十至百行），宜同步计算。转换之阈，视乎具体组织规则之繁简，然百至百五十行为常断点.

瓶颈五：智审查询于巨引文

核价之时，审准之程亦随之。智审（RLM）与进审（CPQ Classic）俱以全价状验诸规。线百行，准核之则繁复，故审迟，增其滞之感。

其诊之术：当别计审之时，离算之时。若提交需卅秒，而算需二秒，则滞者非价，乃准之理也。

其修也：审允之则例所及。允准之标准，宜运于总估之态（总额、折扣之率），非逐行循之。逐行允准之则，鲜为适构，几无必要。

于智审之RLM，新设并行导引之能亦助之：独立允准之支可并运，非次第相承。

一调试之序

调查迟缓报价之命：

1. 先度之。启浏览器调试器，计时重算。察时之所去（计算时之CPU，存时之网络，应后之渲染）。
2. 检视价规计数与范围。若计数众而范围广，则速胜。
3. 检视产规范围。同此诊之。
4. 若QCP之码存焉，当细察之。此乃深究之务，宜多筹时日。
5. 试以异步之法算一例之报价。若诸君允之，则变更之配置甚微。
6. 当别计审批之评估。若此乃主导之因，则须应对之。

凡迟引之议，多解于二三之阶，范围渐收，兼以异步算最大之引。QCP之重改，乃备不逮二三至五之阶者。

架构之决，可防此弊

持引速之式，随其量增：

• 每一价规、产规，皆须严限其域。当以"适此产品族"为常，非"普适诸线"。
• 标准之规不效，方用QCP。大抵QCP之码，多可易以价规，而域更优。
• 新立之组织，若预有巨量引单之需，宜以异步计算为常。同步固善，然非其时则不可。
• 报价层级之核准标准。逐行核准乃反常之范式。
• 模块化产品束。二百行报价实为二十束，较二百单行更易管理。

引述之效，乃桑塔普 Salesforce 团队频受审计之主因。其修之可循，其得甚巨。三十秒之引述化为一秒之速，则销售之用系统者异矣。

---

于 Salesforce CPQ 或 RLM 调试引述之效乎？桑塔普 Salesforce 团队持 Revenue Cloud Consultant 之资，主生产审计之任。相接——>

睹吾辈之平台全务，所覆之栈悉在焉。