09｜设备租赁报价上篇：一句“两天多少钱”背后，缺了哪些条件？

对客户来说，这已经是一条足够清楚的询价。对租赁公司来说，它只确定了一个模糊方向。院子里要挖土还是破除混凝土？设备能否进场？“师傅”是操作员还是运输司机？两天是哪两天，每天工作多久？设备中间是否留场？

如果系统急于给出一个价格，它会把没有确认的条件悄悄变成默认值。数字越明确，客户越容易把它理解为公司已经承诺。设备租赁因此是观察 FDE 工作的一个好入口：模型处理语言的能力，需要与规则、当前资源和人工责任一起发挥作用。

本案例使用一家具备设备、操作员与运输资源的虚拟租赁公司。交易、价目和档期均为模拟设定，用于学习业务分析与系统设计，不代表 AI随心创的客户项目或实施成果。

这家虚拟企业出租小型履带挖掘机及配套附件，也可以安排操作员和运输。过去主要服务长期合作的大客户，现在希望覆盖园林养护、厂区维修和临时施工等零散需求。

单笔金额小，不代表处理简单。接待仍要确认用途、地点、日期和设备条件，再向设备管理员、人员和车组核实，最后根据规则报价。客户改了要求，还要重新查一遍。调度收到不完整记录时，会把任务退回补问。

因此，业务机会不是单纯“让 AI 报价更快”，而是降低一笔询价从接收到可交接结果的处理成本，同时控制错误承诺。若系统只替接待写了一段话，却没有减少调度重新查问的工作，整条链的效率可能没有改善。

调查应跟踪同一个起点和终点：从收到客户原话开始，到形成调度可以继续处理的结果结束。只把终点改成“回复已发送”，很容易得到漂亮但无法代表业务变化的速度指标。

询价澄清应服务于设备选择、计价与履约，而不是机械填完一张大表。哪些缺项会改变方案，就先问哪些。

“清理种植土”与“破除混凝土”影响设备和附件，也影响专业核实；“入口 1.6 米”可以作为客户提供的现场信息，但净高、转弯和作业空间仍可能需要确认；“带师傅”通常指操作员，运输则是另一项安排。

日期与时长必须明确。两天可能是两个正常白班，也可能包含夜间或超时。设备留在现场两天，只需要一次送达和一次回收；若每天运回，就涉及不同运输次数和时段。燃油、附件和押金也要独立说明。

系统应分别保存客户原话、已确认字段、待核实条件和专业判断。模型推测的“可能是普通土方”不能自动写成客户已确认事实；客户描述的通道宽度，也不能直接变成设备负责人已确认可进场。

这种区分让后续岗位知道信息可靠到哪一步。否则需求卡虽然填满了，调度仍然要重新验证每一项。

第一类是当前规则，例如设备、操作员、附件和运输的计价方式。第二类是实时或近期核验的资源条件，例如具体设备是否完成检查，人员在完整日期区间内是否可用。第三类是历史经验，例如客户过去用过什么设备，是否有特殊安排或优惠。

三类依据承担不同作用。当前规则决定普通费用，资源条件决定候选方案能否履行，历史经验帮助理解背景。历史成交价不能因为与当前询价相似，就自动覆盖现行价目；设备类型适用，也不能证明某台具体机器有档期。

本例将设备类型与具体设备分开建模。类型描述尺寸、能力与日租规则，具体设备则有检查、维修、暂留和占用状态。人员、附件和运输也有各自条件。一个可执行组合需要这些条件在同一个时间区间内共同成立。

这也是为什么“库存里有一台”不是可用性证明。设备可能尚未完成回场检查，也可能需要配套附件，而附件当天在另一个现场。系统应呈现候选与限制，等待有权人员核验。

在本例主情境中，客户需要普通土方作业，使用两天，每天不超过八小时，现场距堆场十公里，设备可以留场，客户提供燃油，公司提供操作员和运输，不使用破碎附件。

本例当前价目规则为：设备 600 元/天，操作员 200 元/天；单程运输费取 100 元与“10 元×道路公里数”中的较大值；可退押金 2,000 元。下面只按这些示例条件复算费用。

按本模拟设定，服务费与押金合计为 3,800 元，但不能把 3,800 元称为服务收入，也不能据此判断已收款。押金的性质不同，支付与结算还涉及另一组业务记录。

这笔计算应该由规则程序完成，模型负责解释条件。如果客户改成每天运回，运输变为四程，服务费随之调整为 2,000 元。即使单价没有变化，服务安排已经变化，原报价与资源核验也需要重新处理。

计算正确只是其中一项结果。系统还要说明这份报价基于哪个需求版本、哪版价目、什么查询时点以及哪些条件。没有这些信息，数字无法可靠地进入后续沟通。

客户有时会说：“上次只收这个价格，这次也按上次来。”历史报价可以帮助找到原服务条件和优惠依据，却不能自动成为当前承诺。

另一个模拟情境中，旧价为 890 元，当前规则复算为 1,000 元，其中设备费 600 元。普通优惠上限是设备费的 5%，即 30 元，并不作用于全单服务费。系统因此需要分别展示历史依据、当前复算、价差与权限范围。

如果主管按示例条件批准 30 元设备费优惠，新服务费为 970 元，押金仍单列。批准记录应绑定对应报价与条件。若客户要求直接回到 890 元，不能把“客户希望如此”写成“主管已经同意”。

这个情境揭示了检索与决策的差别。找到历史记录，只完成了证据收集；判断是否适用、是否允许例外，以及由谁批准，还需要业务规则和责任。

本例将一期限定在道路距离二十公里内、白天每天不超过八小时、条件能够明确的普通土方询价，覆盖澄清、查询、计价、版本、客户接受与待调度交接。

特殊工况、复杂进场、超范围运输与超权限价格交给相应负责人；支付、真实派车和完整结算也不在一期自动处理范围内。这个边界既控制工程规模，也限制系统能够作出的承诺。

范围外任务仍可获得有效处理。系统可以整理原话、已知条件、触发例外的依据、接手人和下一动作。客户缺少地址时，带条件的估算与明确补问也有业务价值。有效结果不应被简化为“必须给出肯定价格”。

但附条件估算需要明确条件，不能把缺失道路距离默认为零，也不能把未确定日期当成当前有空。未知必须保持为未知，后续补齐后再计算和查询。

本例用连续四周四十笔询价构造了模拟基线：人工处理时间中位数 42 分钟，端到端总历时中位数 2.6 小时，调度退回补问 12/40，有效处理 26/40，错误承诺后更正 4/40。

这些数字用于演示指标设计，不是行业基准。几个比例也是独立指标，同一任务可能既被退回，又在修正后有效处理，因此不能把各类数量相加当作总任务数。

后续验证应沿用相同起终点和口径。接待变快但调度返工增加，可能只是转移劳动；有效处理提高但出现错误资源承诺，也不足以扩大使用。应同时观察人工投入、交接质量、有效结果和关键错误。

可以把最初询价作为练习，只允许接待先问三个问题。合理顺序应优先覆盖那些会改变设备选择、资源查询和费用的条件，例如作业内容、明确日期，以及地点与进场情况。选择理由比固定问句更重要：客户已经说清某项条件，就不应为了填表再次询问。

收到回答后，把信息分为客户已提供、专业待核实和业务待查询三栏。用途与日期可以来自客户，设备是否适合现场可能需要专业判断，具体档期则需要查询资源。尝试用这三栏写一条接待说明，检查是否混入了系统自行推测的事实。

然后让另一位同事扮演调度，只看整理后的需求与依据，不读原聊天。如果他仍必须重问关键条件，就把缺项记录下来。这项练习可以在开发前完成，帮助团队判断需要改进的是提问、资料查询还是交接结构。

这篇案例上半部分形成的成果，是一份可以指导系统建设的业务定义：普通询价有哪些字段，规则与资源怎样支持判断，哪些情况需要人工，什么结果可以交给调度。下一篇将把这些条件放进软件状态与版本机制，检查系统在改期、冲突和审批中是否仍然可信。

面对类似的询价整理、规则解释或跨岗位交接问题，可以了解 AI随心创的AI 场景诊断与工作流设计服务。先梳理当前流程、输入资料和人工确认点，再判断适合使用哪些 AI 能力以及如何开展小范围验证。