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.

  • 1
    It think that you are looking at the relationship wrong. A is strictly an operator. C is strictly a visitor. B happens to be both an operator and a visitor. The fact that B has two roles does not change the fact that C is strictly a visitor. Therefore, I don't see the point of giving C a unique identifier.
    – Pemdas
    Commented Jan 19, 2011 at 2:23
  • @Pemdas - The problem is the other way around. C is strictly a visitor, but a visitor isn't always strictly C. Also, not every product we develop has an operator and a visitor. Those are specific to one of many products that involve customers and the lengthy "customer of a customer" actor. My question involves how I can generalize C as a "customer of a customer" without being in danger of shortening it to just "customer" and creating confusion.
    – jmort253
    Commented Jan 19, 2011 at 2:36
  • 2
    Wouldnt a customer of a customer be declared "Customer** C"? :-) Commented Jan 19, 2011 at 7:44
  • @GrandmasterB - Then my stakeholders might get confused and think I'm referring to B or C when in fact I only mean one of them.
    – jmort253
    Commented Jan 20, 2011 at 4:54
  • We use "ClientsCustomer" for pointing out the Customer's customer....
    – user81578
    Commented Feb 15, 2013 at 14:47

7 Answers 7

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"

  • @Steven - If I were to ask you "What does the customer see when a message is received?", who am I referring to when I say "customer"? Am I referring to my customer, the ecommerce sales rep receiving a question, or am I referring to her customer, the guy stuck in the checkout process receiving instructions on how to properly enter a credit card number so he can buy his new vans? Thanks!
    – jmort253
    Commented Jan 19, 2011 at 4:46
  • @jmort253, simple: never use the word customer. Shopper and merchant. Commented Jan 19, 2011 at 8:10
  • @Peter - Suppose I want to generalize these levels and apply them to other products. Maybe I have an Admin Employee, Admin Client, and an end-user as A, B, and C. Is there a common convention for "customer of a customer" that doesn't have to be specific to just my product but could also apply to products you are building where you are offering products to your customers to help them with their customers. I feel like this problem should be pretty common in business to business markets.
    – jmort253
    Commented Jan 20, 2011 at 4:57
  • @jmort253: let go of the term "customer"; it has no intrinsic meaning in your use-case. In your examples above, use "client" (one who uses your services), "recipient" (one who receives a question), or "purchaser" (one who buys something) Commented Jan 20, 2011 at 6:11
  • 1
    @jmort253, 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. Commented Jan 20, 2011 at 6:53

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?

  • Great question. We develop Chat Software for our customers to use to interact with their customers/potential customers, but we also take those same chats on behalf of those same... well... customers. See the confusion? I like your suggestion and have tried to push that naming convention before. I'll consider trying it again.
    – jmort253
    Commented Jan 19, 2011 at 2:39
  • If your customer's customers are your potential customers, shouldn't them be named as potential customers or customers already?
    – mauris
    Commented Jan 19, 2011 at 3:11
  • The / between customers and potential customers was meant to represent an AND/OR. "We develop software for our customers to use to interact with their customers AND/OR their potential customers." The customers or potential customers of our customer aren't necessarily our customers or potential customers. Wow, I guess I didn't realize how confusing this really is. Just typing it out to clarify feels complicated. The people our operators interact with could be customers, potential customers, OR not customers or not potential customers, if they are our customer's customer
    – jmort253
    Commented Jan 19, 2011 at 4:35
  • trying to get this down on logic expression =\
    – mauris
    Commented Jan 19, 2011 at 5:14

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.

  • I think that's the problem. My engineers and I have to consider two different roles when discussing the project. Are we discussing from the role of us or the role of them. Although, our role is also User as we eat our own dogfood. I am starting to think I am overthinking this!
    – jmort253
    Commented Jan 19, 2011 at 5:11

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

  • Thanks for your response! This is a great suggestion. I'll have to think about whether or not it could apply to all of our products. My customer and customer's customer example people would have to be able to be actors in all of our systems for that to work. In other words, Bob would have to be a customer of our widget building tool and also be a customer of our foo product and bar product, if that makes sense.
    – jmort253
    Commented Jan 19, 2011 at 6:00
  • @jmort, that's probably not how you should use persona's. Unless Bob really is the same person who'd buy both the widget building tool and foo and bar they should be defined as separate persona's.. that's the point of them, you build different personas for specific scenarios/application/systems and tailor the solution for them. Persona names are not just synonyms for "the user"
    – Homde
    Commented Jan 19, 2011 at 6:04
  • I favor this approach, we had a tough time explaining what we do to investors and our immediate customers. We made up Jamie and Dave as founders of a fictitious company and use Jamie and Dave in our stories, video scribes, uses cases etc. Much easier that customer's customer's end users etc. Commented Sep 15, 2013 at 19:38

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.


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.


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.

  • For awhile, I was using athletes and movie stars in my specifications to try and make them easier to read. I had Brett Favre, Sachin Tendulkar, and Aishwarya Rai, just to name a few.
    – jmort253
    Commented Jan 29, 2011 at 18:46

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.