在规范文档，用例或场景中，您如何称呼客户的客户？

我和我的团队开发了客户可以用来与客户互动的软件。此外，我们还吃自己的狗粮，并自己使用该软件与客户互动。

因此，有时可能很难解释用例和场景，因为我们的员工可以是操作员，我们的客户可以是操作员，而我们的客户的客户可以是访客。

但是，我们的客户也可以是与我们的运营商员工互动的访客，我们的客户的顾客可以是与我们的客户或员工互动的访客。

这是一个模型，其中：

A is an employee
B is a customer
C is our customers' customer

X  interacts with  Y
Operator --> Visitor
      A  -->  B
      A  -->  C
      B  -->  C

因为有时我们的客户可以扮演不同的角色，所以有时有必要引用特定的角色，即操作员或访客，而不是雇员和客户。

一直说“客户的顾客”也是一个大嘴巴。

我想知道其他开发商店在编写用例和场景时如何处理这些语义细节。

• 是否有任何一个单词的通用术语可适用于涉及三级参与者的任何产品？
• 除了使用特定角色（运营商和访客）以外，还可以使用哪些词来识别客户的客户？

这个词必须足够短以便在组织内采用。如果音节长于一对音节，则它的缩写形式必须与其他演员区分开。

解释用例和场景

这就是关键：使用域的术语，即角色的名称。谁可以扮演角色并不重要。确保角色定义明确（针对每种情况）。

我完全有可能访问自己的网站并购买自己的产品。这很愚蠢，但是有可能[但是我已经完成了测试电子商务软件的工作！]。这其实是我的供应商，节目主持人，作家，网站管理员，文案，编程，客户端，客户，来访者，购买者，客人，老板和员工都在同一时间不会改变用例的术语：“客户通过网络表单从所有者那里购买产品”

为了明确起见，请先将您的客户称为客户，然后再将您客户的客户称为客户。这将使其更加清楚，不是吗？

我建议您重命名这些条款，并根据他们的喜好为每位客户定制软件包（一点点）。一些客户可能希望致电其客户客户或用户。

关系也有点有趣。您的员工如何与客户的客户互动？

因此，当将角色视为相对实体a相对于实体b扮演角色时，问题变得更加简单。您的客户认为自己是用户，而他们的客户就是他们的客户。唯一关心您作为客户的客户的人就是您。您在系统中具有两个角色，分别是管理员和用户。

我看到了这样的解释：您有一些雇员通过您的聊天软件与最终客户进行交互（我们将此角色称为代理）。为了澄清起见，代理商是否将自己代表您的用户的雇员？

我认为角色仍然是代理，用户，客户。将您的用户称为客户只会使事情变得混乱。（如你看到的）。

我的处境更糟……我不得不在三个间接层上工作。有一个Company实体，在某些情况下是我们应用程序的直接用户。他们拥有一些帐户，他们从我们的产品中出售了各种套餐，并且跟踪了这些帐户的客户。

也许有点切线，但是...

我自己喜欢交互设计，在这里您永远不会使用抽象的“角色”或“用户”，而是使用“角色”。基本上，您用名称，描述和照片组成一个角色，然后在设计过程中使用它

“鲍勃在中年时是一名银行经理，他有一些计算机经验，但并不特别喜欢它们。”

然后，在您的项目中，您可以使用其真实姓名“不，鲍勃不想要那个”，“如果鲍勃这样做，则需要以某种方式通知爱丽丝”。角色在执行场景时特别有用。

我强烈建议囚犯进行庇护和“面对”

我被要求发表此评论作为答案，所以：

我目前正在从事的项目有客户的客户。该项目的术语是将我客户的客户称为“订户”，而他们的客户称为“消费者”。使用亚马逊的市场隐喻，他们可以成为摊主和购物者。

运营商和访客似乎定义得很好。不确定操作员成为访客或访客成为访客时是否有所不同。那时，每个人都是访客。

取决于软件的用途是使用众所周知的虚拟角色，例如Dumbledore总是对Harry有所了解（向他传授他以前不知道的东西和/或回答他的问题）。使用适合您开发人员文化的字符。然后，您可以在以下用例中引用它们：当A坐在邓布利多的椅子上或当B在玩哈利时。

如果您认为这会使您的规范变得非正式且缺乏专业知识，则应阅读Joel的这篇文章，并查看他的示例功能规范。