Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

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.

share|improve this question
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 Jan 19 '11 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 Jan 19 '11 at 2:36
1  
Wouldnt a customer of a customer be declared "Customer** C"? :-) –  GrandmasterB Jan 19 '11 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 Jan 20 '11 at 4:54
    
We use "ClientsCustomer" for pointing out the Customer's customer.... –  user81578 Feb 15 '13 at 14:47
add comment

7 Answers

up vote 4 down vote accepted
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"

share|improve this answer
    
@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 Jan 19 '11 at 4:46
    
@jmort253, simple: never use the word customer. Shopper and merchant. –  Peter Taylor Jan 19 '11 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 Jan 20 '11 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) –  Steven A. Lowe Jan 20 '11 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. –  Peter Taylor Jan 20 '11 at 6:53
show 4 more comments

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?

share|improve this answer
    
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 Jan 19 '11 at 2:39
    
If your customer's customers are your potential customers, shouldn't them be named as potential customers or customers already? –  mauris Jan 19 '11 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 Jan 19 '11 at 4:35
    
trying to get this down on logic expression =\ –  mauris Jan 19 '11 at 5:14
add comment

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.

share|improve this answer
    
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 Jan 19 '11 at 5:11
add comment

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

share|improve this answer
    
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 Jan 19 '11 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" –  konrad Jan 19 '11 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. –  Dickey Singh Sep 15 '13 at 19:38
add comment

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.

share|improve this answer
add comment

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.

share|improve this answer
add comment

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.

share|improve this answer
    
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 Jan 29 '11 at 18:46
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

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