For WooCommerce services and bookings, choose Custom Product Type when the store needs a reusable service model, Product Add-Ons when standard products only need customer inputs, and both when the service structure and reservation form are separate requirements.
The correct choice depends on the business workflow, not the presence of a calendar alone. Start with one representative service and separate what the store defines from what the customer supplies.
Choose by the main problem
| Problem | WPSAAD direction |
|---|---|
| Services need dedicated tabs, fields, and presentation | Custom Product Type |
| Standard products need dates, notes, files, or choices | Product Add-Ons |
| Specialized services also need reservation input | Use both |
Map the complete service journey
Before choosing an extension, document the service from catalog creation to customer input:
- What stable information defines every service?
- Which values should editors maintain in a dedicated tab?
- Which facts must customers see before purchase?
- What information must the customer provide?
- Does the customer choose a preferred date or another booking value?
- Which scheduling rules must the business validate separately?
This workflow prevents a buyer-input plugin from carrying the whole product architecture and prevents the product type from being treated as a complete scheduling engine.
What Custom Product Type owns
Custom Product Type for WooCommerce can define Service and Services labels, a Service Details admin tab, verified backend fields, frontend positions, layouts, Custom Taxonomy, Display In Shop, and a service badge.
Use it for duration, delivery method, preparation, response time, included follow-up, and scope.
Business result
Editors create services from one repeatable model, product pages use consistent specifications, and the service family can have its own layout, taxonomy, badge, shop visibility, and collection page.
What Product Add-Ons owns
Product Add-Ons, Custom Fields & Booking for WooCommerce focuses on buyer input such as text, dropdowns, checkboxes, file uploads, and booking-oriented choices.
Use it for the customer’s project brief, supporting file, preferred date, and purchase-specific selections.
Business result
The product page collects only the information needed for this purchase. Stable service facts remain readable, while customer values stay in the interaction designed for buyer input.
Consultation example
| Value | Owner |
|---|---|
| Duration and delivery | Custom Product Type |
| Included follow-up | Custom Product Type |
| Customer website URL | Product Add-Ons |
| Preferred consultation date | Booking input |
| Uploaded project brief | Product Add-Ons |
Three valid plugin configurations
1. Custom Product Type only
Choose this when the main problem is service catalog structure. Scheduling may be unnecessary, handled outside WooCommerce, or covered by a simple customer option that does not define the whole workflow.
2. Product Add-Ons only
Choose this when Simple or Variable products already represent the service accurately and the only missing layer is customer text, selections, uploads, or a booking-oriented input.
3. Both plugins
Choose both when a real service family needs dedicated admin data and storefront presentation, while each purchase also requires customer or reservation information.
Implementation order
- Define the service promise and stable data.
- Create the Service type and Service Details tab.
- Display essential facts near the purchase action.
- Add only required customer and booking inputs.
- Test one complete service on mobile and desktop.
Build a Service Details example
| Field | Type | Public position |
|---|---|---|
| Duration | Text | Before Add to Cart |
| Delivery Method | Select | Before Add to Cart |
| Included Follow-up | Checkbox | After Add to Cart |
| Preparation Requirements | Textarea | Single Product Summary |
| Internal Staff Note | Textarea | Private |
Enable Show In Front only for the sales-relevant fields. The add-on layer can then collect the website URL, project goals, preferred date, and supporting file.
A calendar interface does not prove advanced availability, capacity, resource, buffer, or conflict behavior. Validate the scheduling rules required by the business separately.
Run a representative-service test
- Another editor can create a second service using the model.
- The service facts appear before the customer inputs.
- The booking form asks only necessary questions.
- Optional empty values do not weaken the page.
- The page works on desktop and mobile.
- The chosen scheduling behavior matches business requirements.
Commercial decision checklist
| If this is the dominant requirement | Start with |
|---|---|
| Reusable service identity and data | Custom Product Type |
| Customer personalization and files | Product Add-Ons |
| Customer booking input | Product Add-Ons booking controls |
| Service model plus buyer input | Both |
Use the bookings comparison and the implementation guide for the complete decision.
Review both WPSAAD product pages against the representative consultation before choosing the smallest combination that completes the workflow.
Record the final ownership decision for every field so future services follow the same architecture instead of recreating the booking form differently.
Frequently asked questions
Can I use Custom Product Type alone for services?
Yes when the main need is service structure and presentation or when scheduling is handled elsewhere.
When is Product Add-Ons enough?
Use it when the standard WooCommerce product model fits and only buyer input is missing.
When should both plugins be used?
Use both when stable service architecture and customer reservation input are independent requirements.
