Lets go back to basics:
Service: work done for somebody else: work done by somebody for somebody else as a job, duty, punishment, or favor.
As the definition implies, is there anywhere in your application where you need code to perform work for any other piece of code?
"Everywhere" you might say, that's what classes do! ... and at a fundamental level you'd be right. There's an interesting parallel that is made in Programming WCF Services between the structure of ordinary code (with metadata, an interface and an implementation) and web services that also have those properties. So essentially all code can be classified as a service. I think that's a pretty interesting and valuable insight into this class of problems.
If a class is really, functionally equivalent to a service... what questions do you ask yourself when you decide to make a new class? Keep in mind the SOLID principles here.
I posit that you will (or should) ask yourself these same questions when deciding whether or not to make a web service, but only at a higher level of abstraction.
For a class, some such questions would be*:
- Is there a set of common functions that the rest of my code needs to consume?
- is there a set of common data that the rest of my code will need to know/have access to?
- Am I coding the same structure over and over in my project(s)?
- Am I coding the same thing/pattern over and over in my project(s)?
Take these kinds of questions to a higher level of abstraction, or a larger logically related set of code, and if you answer "yes", then you have a candidate for a web service.
*not an exhaustive list