Services act on business entities, but are not business entities.
So customers, orders and products would be data contracts, not service contracts.
It's the actions you perform on those data contracts that form your service contract, and the actions you expose on an entity may or not be all the things that entity can do.
If, as I think you might be asking, each entity has common functionality (CRUD operations for example) then yes, you should have a separate service contact for a CRUD service on each entity (CustomerCRUDService, OrderCRUDService etc.) because web services don't support overloads on method signatures.
(From the comments)
There are a couple of ways.
1) Composite service contracts: For example I have a service that implements WSTransfer - this actually is comprised of two service contracts, IWSTransferResource and IWSTransferFactory. In turn I have an IWSTransfer service contract that just implements those separate contracts - public interface IWSTransfer : IWSTransferResource, IWSTransferFactory
2) But you don't even have to get that complicated, an implementation in WCF can implement multiple service contracts - MyServiceImpl : IMyContract1, IMyContract2. However each contract needs a separate endpoint, because endpoints are for service contracts, not implementation classes.