Good design choice, different types of customers, from webservice

Question

Hi, I have thoughts about good design pattern, when doing this:
You have a webservice where customers coming into your system. The customers are private ones, business ones, and big business types.
These 3 customer types has different needs, and must have different values like companyname, social security number, etc etc.
The customer also has some shared types, like customerid, created, updated, etc.
So what you want to do is to have an interface or an abstract class containing common methods for the customer, then you will create subclasses for the different types.
I was thinking about creating a factory class and pass in the customer object retreived from the webservice, and in the factory process method create objects on the different subclasses based on what kind of object you get in (private, business, etc).
So, webservice gets a private customer object, you serialize it and then you pass it into your factory class. And back you get a customer object.
Now you want to do business logic on the object, storing it to a database, etc.
So you might still have to create different scenarios based on if its customer type.
The basic idea is that you want to get the object from webservice, pass it to a factory and get back a customer object which you want to do things with.
What do you think, what is a good design solution to the problem described?

Answer 1

To be clear "pattern" has a specific meaning. Your description is a design not a pattern.
Is the small business one never going to become a big business one?
Is a big business one never going to become a small business one?
If the answer to either is yes, then you have one entity with different attributes, not two.
I have no idea why serialization would matter in this. And your description doesn't explain that either. If you are talking about communication between different boxes then you need a communication layer (and it doesn't appear you are at the level yet where you need to decide the specifics of how that is handled.)
It is unclear why you would want a factory. But if you just want the experience then you could probably use it.
Your description isn't nearly complete enough to define how the overall system should behave which is what you seem to be also describing. You need to seperate what the system will do for how it will do it (the design.)