I've been through numerous discussions about reuse during my career. It always starts with "Wouldn't it be nice if we written this wonderful code once and then everybody in the organisation will use it until the kingdom come?" .
We will create this service layer team that will write enterprise level services and other teams will consume them.
That is great in theory, but in the context of a large organisation these dreams crash against the wall of reality.
Let's assume you have a version of a service that retrieves customer policy/account data from a data store and you want everyone to retrieve it using it. You, obviously, want to pack as much of a business logic into this service, because…reuse, right?
You spend some time collecting all the use cases about all the information you could possibly need to be returned and then write this wonderful service, hacking away all permutations and edge cases that cater for all potential consumers.
You even persuade 10 various consumers to use it. And then the fun begins. Consumer #3 wants a slight modification to the service output due to new regulatory requirements. What does it mean?
More often that not, it means that in addition to the Consumer #3, all other consumers need to perform impact assessment on how does the proposed change impact them and, even if it is not impacting them, they will have to participate in regression testing activity which needs to coincide with the release for Consumer #3.

• What does it do for their respective team schedules?
• Do they all have developers or BAs available to perform the tasks?
• What is the process and cost of creating new environments?
• What if one out of the consumers' tests fail?
• Etc.

Or, if you've implemented a service versioning strategy, you release a new version and make Consumer #3 its first customer while giving remaining consumers some time to switch over to the new version at some point later…But these other teams usually don't have any budget to switch over to a new version of a service, so they would want the business user who initiates the change to pay for it all, hence, you are back to a simultaneous release. And the bigger the change is, the higher chance of it to go pear-shaped.
Host projects tend to have limited budgets and therefore they have no desire in paying for anything that isn't directly related to the project's outcome, hence, they will insist to have a special case service built just for them.
So a couple of years down the track you are very likely to find yourself with multiple versions of the very same service, built for various consumers at different times, each with minor variations.
Thus, despite the noble goals of building one super-service that does it all for everyone, the organisation will end up with a collection of custom-built, consumer specific services that are centrally managed by a shared team that has very little knowledge about why exactly each of the versions is built the way it was.
What is the solution?
Often, it is better for services to return full raw responses and let consumers deal with the data interpretation in a way they see fit - chances are you will write less code, the code will be much cleaner and the business logic will be owned by the team that actually uses it.
Or, as Martin Fowler put it, use >> reuse.