What schema do I use for our services and subservices?

Question

I'm thinking through the structured data for our new website, and I've grinded to a halt.

In our new website, we'll have six services we offer, amongst which are Webdevelopment and Online Marketing. All of these have several subservices, for instance Webdevelopment>Front-end, Webdevelopment>Back-end, or Online Marketing>Remarketing.

I figured that, seeing as what we call services aren't really called services, entities like Webdevelopment and Webdevelopment>Front-end should be Creative Works. They're not Services as the schema might imply (delivery service, glass repair service), nor do they have set prices so they can't be Products.

My colleague disagrees, he insists that they're services because it's what we use to make the final product (like a website or a flyer).

Would it make more sense for Webdevelopment>Front-end>Product01 to be structured (with Schema.org) as CreativeWork>CreativeWork>CreativeWork, or as Service>Service>CreativeWork? Or should I structure it differently alltogether?

EDIT: Maybe this info will help: we're going to have one page on our website per 'service', and every 'subservice' gets another page, and the project pages too, ofcourse. Which means that if I use CreativeWorks for services, subservices, and projects, I can jump back and forth through the service hierarchy using exampleOfWork, hasPart, and their inverses.

Answer 1

Using a CreativeWork type does not seem to be appropriate. The result of your work is a CreativeWork, but not your work (i.e., the process to create it) itself. So you can use it for finished projects (e.g., in a portfolio), but not for the services you offer.

The Service type seems to be appropriate. I don’t think that there is a relevant semantic difference between a delivery service and web development. In both cases you provide a service for others, offering your expertise and time.

Another type that could be used is Offer. It has some overlap with Service ("An offer to […] to provide a service"), and you have to use Offer if you want to sell (i.e., with a price) your service, but you don’t have to provide a price.

If using Service, and you decide that you want to provide prices at some point, you can use the offers property to provide an Offer for the Service.

By the way, for a list of all your services, you could also use hasOfferCatalog → OfferCatalog (where each item can be a Service). This also allows you to convey the hierarchy of related services (by using nested OfferCatalog items). But this doesn’t work so well if you use several pages instead of one page.