Mark, This is an interesting question. You will find as many opinions on this. I don’t believe there is a ‘right’ answer. This is a great example of where a rigid heirarchial object design can really cause problems after a system is built.
For example, lets say you went with the “Customer” and “Staff” classes. You deploy your system and everything is happy. A few weeks later, someone points out that they are both ‘on staff’ and a ‘customer’ and they are not getting customer emails. In this case, you have a lot of code changes to make (re-design, not re-factor).
I believe it would be overly complex and difficult to maintain if you attempt to have a set of derived classes that implement all the permutations and combination of people and their roles. This is especially true given that the above example is very simple – in most real applications, things will be more complex.
For your example here, I would go with “Take another completely different approach”. I would implement the Person class and include in it a collection of “roles”. Each person could have one or more roles such as “Customer”, “Staff”, and “Vendor”.
This will make it easier to add roles as new requirements are discovered. For example, you may simply have a base “Role” class, and derive new roles from them.