Abstract Person with Employees and Clients
Yes. When some classes have things in common but common things different having a abstract base class is a good way to go.

Having a common base class gives you a number of advantages:


Reuse between the classes. Your Find and GetAll methods don't have to be rewritten for each type of person. So you avoid having to test this N times, and you avoid accidental (and subtle) differences in implementation (=> bugs!). (N = the number of classes extending from Person)
A consistent interface. Other code using a Person doesn't (necessarily) need to know what kind of Person it's working with. For example you could write a script to get all people and update them without having to worry about the differences between clients/employees.


But you need to make sure of a few things:


The implementations in your base class must work for all children, now and in the future. So if you want to add an Employer class you don't want to have to change the base class methods. If you do so you have to test your other class implementations to make sure they still work. That being said, minor modifications often aren't too much of a big deal.
If your classes have a small amount in common but large differences you could end up only partially being able to rely on a consistent interface. So you lose the flexibility of just operating on Person objects. If your language supports it traits might be a better way to go here. Also if you find yourself in this situation your classes might be getting too big. Try breaking them down. (Nobody likes a god object!)


But broadly speaking; Yes, go for it!