新的购买功能在Q3 2020 10.1:名称& added value

你好社区,

I'm探索10.1的新功能(我知道我'不早:)),特别是全新"purchases" module.

我的第一个想法是"哇糖现在朝着一个完整的ERP和现在管理  小贩 purchases". 

调查文档,我意识到我们're talking about  顾客  购买, in other words, orders. 

这对我产生了新的问题: 

  1. 为什么要打电话给这一点"purchases"当这个术语主要用于供应商购买时?"Orders"更容易想到。用法语它'甚至更令人不安"Achats"显然是处理供应商/采购的团队的名称。我从客户那里了解'透视他们确实是 购买 ,但这个工具被销售人员使用,良好,卖:)
  2. 目前我未能看到购买的附加值与RLI。 AFAIK记录与母亲的机会没有联系 没有地位(订购,交货,交付,退休......)。这仅适用于定期订单,例如每月自动续约吗?另一个用例我'm not seeing? 
  3. 自动创建购买是伟大的 我的亨希是,大多数客户都不会使用它们,所以"generate purchase"默认应该是否则。容易改变,但大多数项目(或无用的数据存储和处理时间)将花费成本。 

这些是我的想法,奠定了公开讨论:)

小心,

达米恩

父母
  • 你好 ,

    感谢您提出有洞察力的问题和提示讨论。这是一个很好的问题。完全披露,我'不在产品组中,但这是我的看法:

    1. I'M确定您已经知道这一点 - 但是您可以自由地将任何模块重命名为您喜欢的任何模块: //support.phone2play.com/Knowledge_Base/Studio_and_Module_Builder/Editing_a_Modules_Labels/#:~:text=Navigate%20to%20the%20Developer%20Tools,for%20the%20module(s).

      考虑为什么不称之为IT订单开始的原因 - 可能是避免与已经有订单数据的自定义模块的系统数量的视觉冲突。

      另一个原因可能是故意避免与订单数据混淆 - 因为订单通常有您的字段've 参考,例如,一个状态。

    2. RLI并不总是代表购买 - 因为每个opp都可以产生它们。只有购买模块可以被视为客户所购买的内容的准确(在CRM的上下文中)。

      创建客户购买的报告应该很容易 - 它不应该针对opp状态的过滤器,这是目前与RLI的报告。

    3. 为避免自动生成,可以 turn off the "Generate Purchase"所有产品的产品目录中的字段。所有RLI都会继承该字段并将其用于自动生成。这绝对是推荐用于设置ERP集成的场景,或者在您所说的情况下,在您不在的情况下't want to use it.

    您的问题中更基本的暗流是这样的:为什么我们甚至制作这个模块?许多CRM实现具有ERP集成并带来销售 数据已经,所以已经可以通过类别分析客户花费 已经。为什么要添加一些大多数人重视它的人已经拥有?

    购买模块的表是什么 为未来的所有此类集成创建一致的架构 -  这意味着如果我们想运行糖发现它以识别异常,或 我们的新AI收购 要进行预测,数据已经处于可识别的格式。时间感知系统的一个大值点之一是您可以获得从该数据的洞察力的速度。一致的,可识别的架构使得很容易,因为我们知道数据的位置,如何'LL外观并能够相应地配置我们的模型。

    I'm绝对开放讨论这一点,了解其他人也看到了这一点!

    问候,

    亚当

  • 你好亚当,

    感谢您的详细答案。这有助于很多:)

    让'S继续讨论一点点: 

    1.命名:  

    是的,我可以重命名&根据我们的客户添加字段'需要。我觉得命名和数据结构我们'没有完全清除盒子。我们清楚地看到糖是在旅途中"all-purpose CRM 框架 " to "交钥匙但可定制的cx 软件 "。我一个人欢迎销售和服务的变化(但不管是企业,而不是),但是需要在某处设置:应该如何交钥匙?如果它's "very turnkey"然后,大部分工作都应该根据最佳实践和平台的愿景来完成。 

    最后,这个词如何"orders"更困惑于系统的其他部分"purchases"? 

    2. RLI VS购买: 

    如果对象不会带来其他信息,那么它's useless. I'd宁愿过滤RLI状态,而不是查询另一个对象。 RLI *应准确,或销售预测。

    It's a topic we'RE经常与我们的客户讨论,例如合同。您是否应该将合同信息与机会或单独的物体进行?通常,我们在不同的用户/角色需要对象时使用合同,或者可以为同一合同有几个相同的opp或几个opps的若干合同。 

    在购买的情况下,如果同样的opp会有几次购买,则并不完全清楚。

    我也仍然不'理解为什么购买和PLI与原来的互联网无关?有没有人'甚至是PO的参考? 

    3.自动生成

    谢谢你的尖端,我'll看着这个。 

    达米恩 Pochon.

    CRM.&数字顾问@ ITS4U集团

回复
  • 你好亚当,

    感谢您的详细答案。这有助于很多:)

    让'S继续讨论一点点: 

    1.命名:  

    是的,我可以重命名&根据我们的客户添加字段'需要。我觉得命名和数据结构我们'没有完全清除盒子。我们清楚地看到糖是在旅途中"all-purpose CRM 框架 " to "交钥匙但可定制的cx 软件 "。我一个人欢迎销售和服务的变化(但不管是企业,而不是),但是需要在某处设置:应该如何交钥匙?如果它's "very turnkey"然后,大部分工作都应该根据最佳实践和平台的愿景来完成。 

    最后,这个词如何"orders"更困惑于系统的其他部分"purchases"? 

    2. RLI VS购买: 

    如果对象不会带来其他信息,那么它's useless. I'd宁愿过滤RLI状态,而不是查询另一个对象。 RLI *应准确,或销售预测。

    It's a topic we'RE经常与我们的客户讨论,例如合同。您是否应该将合同信息与机会或单独的物体进行?通常,我们在不同的用户/角色需要对象时使用合同,或者可以为同一合同有几个相同的opp或几个opps的若干合同。 

    在购买的情况下,如果同样的opp会有几次购买,则并不完全清楚。

    我也仍然不'理解为什么购买和PLI与原来的互联网无关?有没有人'甚至是PO的参考? 

    3.自动生成

    谢谢你的尖端,我'll看着这个。 

    达米恩 Pochon.

    CRM.&数字顾问@ ITS4U集团

孩子们
  • 你好 道歉在这里错过了你的回复 - 唯一注意到它的文森特也在下面回复。

    1 - 您是正确的,在以规范性好的/最佳实践之间存在余额,并且足够灵活地支持各种商业模式。在进一步反思后,我避开了一个月的客户谈话't found 人们要找到令人困惑的措辞(大多数人我'拜访了对订单属于ERP或履行系统的想法,我现在想,我现在想,我'我要继续在这方面听。

    2 - 这里是一个单独的对象的优势在于,对于拥有ERP集成来带来实际销售的客户,有一个特定的地方将数据放置,了解您的知识'重新触摸用于预测/报价的模块......即,在不同模块的目的周围清除业务划分。

    您是否应该将合同信息与机会或单独的物体进行?

    合同是一个有趣的话题,可以探索 - 真正的帖子 - 我'已经看到了这种概念的许多不同实现,包括你的变体've mentioned. I'看到法律/支持/金融经常对这一数据感兴趣,因此根据需要,糖中的正确位置是可变的,并且没有一致 "总是正确的答案" answer.

    在购买的情况下,如果同样的opp会有几次购买,则并不完全清楚。

    单一机会肯定会导致多种购买记录。 Let'S表示您为10 CRM许可证和支持SLA销售了一个机会。对于许多公司来说,两者都将被视为每年重复的服务,如果产品目录是相应配置的,当您关闭OPP时, 相关帐户也将获得2倍购买记录和2X PLI。

    如果从它自动生成记录,我就无法与为什么没有设置与opp的关系......但我不'T Think Po数字属于它 - 再次我认为是ERP /会计包应该拥有的东西。 

    问候,

    亚当