What do you call a customer's customer in a specification document, use case, or scenario?

Question

My team and I develop software that our customers will use to interact with their customers. Additionally, we also eat our own dogfood and use the software ourselves to interact with our customers.

Therefore, it can sometimes be difficult to explain use cases and scenarios, as our employees can be operators, our customers can be operators, and our customers' customers can be visitors.

However, our customers can also be visitors interacting with our operator employees, our customers' customers can be visitors interacting with our customer or our employee.

Here is a model where:

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

Because sometimes our customers can play different roles, it's sometimes necessary to refer to the specific role, Operator or Visitor, instead of Employee and Customer.

It's also a mouthful to say "customer's customer" all the time.

I was wondering how other development shops handle these semantic details when writing their use cases and scenarios.

• Are there any one-word, generic terms that can apply to any product that involves a third-level actor?
• Other than using the specific roles, Operator and Visitor, what words could be used to identify a customer of a customer?

The word would need to be short enough as to be adopted within an organization. If longer than a couple syllables, it's shortened form must still differentiate it from the other actors.

Answer 1

to explain use cases and scenarios

That's the key: use the terminology of the domain, i.e. the names of the roles. Who can play the roles is not important. Make sure that the roles are well-defined (for each scenario).

It is entirely possible for me to visit my own website and purchase my own products. It's silly, but it's possible [but I've done it to test the e-commerce software!]. That fact that I am the provider, host, author, webmaster, copywriter, programmer, client, customer, visitor, purchaser, guest, owner, and employee all at the same time does not alter the terminology of the use-case: "customer buys product from owner via web form"

Answer 2

To make it clear, call your customer as clients, then your customer's customers as customers. That will make it clearer isn't it?

I recommend you to rename the terms and customize your software package (a little) for each of your customer depending on their preference. Some customers may want to call their customers clients or users.

Also the relation is a little funny. How can your employee interact with customer's customers?

Answer 3

So the question becomes simpler when think of Roles as being relative entity a performs a role in relation to entity b. Your Customer consider's themselves to be a User and their Customer's are Customers to them. The only person who cares about your Customer as a Customer is you. You have two roles in the system as an Administrator and as a User.

I saw the explanation that you have Employees who interact with the End Customers through your chat software (let's call this role Agent). For clarification, does the Agent represent himself as an employee of your User?

I would argue that the role is still Agent, User, Customer. Referring to your User as a customer just confuses things. (As you can see).

I've had it worse...I had to work on three levels of indirection. There was a Company entity which in some cases were direct Users of our application. They had Accounts that they sold various packages from our offerings to and they tracked Customers for those Accounts.

Answer 4

Maybe a bit of a tangent but...

I'm fond of interaction design myself, and there you never use abstract "roles" or "users" but something called "personas". Basically you make a up a character with a name, description and photograph and then you use that in your design process

"Bob is a bank manager in his middle years, he has some computer experience but is not especially fond of them."

Then in your project you can use their real names "No, Bob wouldn't want that" , "If Bob does this then Alice needs to be notified somehow". Personas are especially useful when you're doing scenarios.

I'd highly recommend The inmates are running the asylum and About face

Answer 5

I was asked to post this comment as an answer, so:

The project I'm working on at the moment has customers of customers of my client. The jargon of the project is that the customers of my client are called "subscribers" and their customers are called "consumers". Using Amazon's marketplace metaphor they could instead be stallholders and shoppers.

Answer 6

Operator and Visitor seem pretty well defined. Not sure there is a difference when an operator becomes a Visitor or a Visitor becomes a Visitor. At that point, everyone is a Visitor.

Answer 7

Depending on what the software is meant to do use well known fictitious characters e.g. Dumbledore is always dropping knowledge on Harry (teaching him things he didn't know before and/or answering his questions). Use characters that fit with the culture of your developers. Then you can refer to them in use cases as such: when A is sitting in Dumbledore's chair or when B is playing Harry.

If you think this would make your specifications to informal and lack professionalism, you should read this article by Joel and look at his's sample Functional Specifications.