Roles and Resource Matching
Define what a Task needs without tying it permanently to one specific Resource
A Task needs real Resources in order for work to happen.
That Resource might be a person, a room, a workstation, a piece of equipment, or anything else whose availability matters to the Service.
But a Task does not always need one specific Resource.
Often, it simply needs a Resource capable of doing a particular job or filling a particular function.
SkedSERVICE represents that requirement with a Role.
A Role tells the scheduling engine what kind of Resource can satisfy a Task’s requirement.
A Role is not the Resource
This distinction is fundamental to the way SkedSERVICE schedules work.
A Resource is the actual thing that can be assigned.
For example:
- Maria
- Alex
- Styling Chair 1
- Styling Chair 2
- Treatment Room A
- Wash Station 1
A Role describes what kind of requirement that Resource can satisfy.
For example:
- Stylist
- Styling Chair
- Treatment Room
- Wash Station
The Task defines the Role it needs.
SkedSERVICE then looks for an actual Resource that can satisfy that Role and is available at the required time.
In simple terms:
| Concept | Example |
|---|---|
| Task | Apply Color |
| Role required by the Task | Stylist |
| Suitable Resources | Maria, Alex |
| Resource actually used | One suitable available Stylist |
The Role is the matching rule.
The Resource is what actually performs or supports the work.
Define the requirement, not the individual
Imagine a salon with two stylists:
- Maria
- Alex
Both are suitable for performing a color application.
If the Task were permanently configured to require Maria, then every appointment using that Task would depend on Maria’s availability.
That would unnecessarily exclude Alex.
Instead, the Task can require the Stylist Role.
SkedSERVICE can then look at the available Resources that satisfy that Role when evaluating the appointment.
The configuration describes:
“This Task needs a Stylist.”
rather than:
“This Task must use Maria.”
That distinction allows the scheduling model to represent interchangeable capacity.
Roles can describe more than people
The word “Role” may sound like it applies only to employees, but in SkedSERVICE it is more general.
Roles can describe the kinds of Resources that a Task needs.
For example:
| Task | Role needed | Possible Resources |
|---|---|---|
| Apply Color | Stylist | Maria, Alex |
| Rinse | Wash Station | Wash Station 1, Wash Station 2 |
| Massage | Treatment Room | Room A, Room B |
| Dry Hair | Styling Chair | Chair 1, Chair 2 |
The scheduling engine does not care whether the Resource is a person, room, station, or piece of equipment.
What matters is:
- the Task defines what kind of Resource it needs;
- suitable Resources exist for that Role;
- one of those Resources is available when the Task needs it.
A Task can require more than one kind of Resource
Many Tasks cannot happen with only one Resource.
A salon Task might need:
- a Stylist;
- and a Styling Chair.
A massage Task might need:
- a Massage Therapist;
- and a Treatment Room.
A grooming Task might need:
- a Groomer;
- and a Bathing Station.
Each requirement describes a different kind of Resource the Task depends on.
For example:
| Task | Required Roles |
|---|---|
| Color application | Stylist, Styling Chair |
| Rinse | Stylist, Wash Station |
| Massage session | Massage Therapist, Treatment Room |
| Dog wash | Groomer, Bathing Station |
For the Task to be schedulable, SkedSERVICE needs to be able to satisfy all of its Resource requirements at the appropriate time.
The Resource pool gives the scheduler choices
Suppose a salon has the following Resources:
| Resource | Role |
|---|---|
| Maria | Stylist |
| Alex | Stylist |
| Styling Chair 1 | Styling Chair |
| Styling Chair 2 | Styling Chair |
| Wash Station 1 | Wash Station |
And a color application Task requires:
- Stylist;
- Styling Chair.
SkedSERVICE can evaluate the available Resource pool rather than depending on one predetermined pairing.
For example:
| Resource requirement | Suitable available Resource |
|---|---|
| Stylist | Alex |
| Styling Chair | Styling Chair 1 |
Another appointment at another time might use Maria and Styling Chair 2.
The Service definition stays the same.
The actual Resources used can depend on what is available.
Roles make reusable Tasks possible
A Task describes a kind of work.
If that Task were permanently tied to specific people, rooms, or equipment, it would become difficult to reuse.
For example, a Task called Color application should not have to be recreated once for Maria and again for Alex simply because either stylist can perform it.
Instead:
Color application
requires:
Stylist
The same Task can then participate in Services without being built around one particular employee.
This keeps the Service definition focused on what the work requires, while the scheduling engine determines which suitable Resource can satisfy that requirement.
Roles help availability reflect real capacity
Suppose a Task needs a Stylist at 10:00.
Maria is already busy.
Alex is available.
If the Task requires the Stylist Role rather than Maria specifically, the requirement can still be satisfied.
Conceptually:
| Check | Result |
|---|---|
| Task requires | Stylist |
| Maria available | No |
| Alex available | Yes |
| Suitable Resource available | Yes |
The Task does not become unavailable merely because one particular Stylist is occupied.
What matters is whether the required Role can be filled by a suitable Resource at that time.
This allows SkedSERVICE to evaluate the capacity that actually exists in the business.
Roles and Resources solve different problems
Roles answer:
“What kind of Resource does this Task need?”
Resources answer:
“What actual person, room, station, or piece of equipment can satisfy that need?”
Keeping those concepts separate gives the scheduler more information and more flexibility.
Without Roles, a Task would have to depend directly on particular Resources.
Without Resources, a Role would describe a requirement without anything real available to satisfy it.
Together, they allow SkedSERVICE to move from:
the work that needs to happen
to:
the actual available capacity that can make it happen.
The customer never has to manage this
Roles and Resource matching are part of the business’s scheduling configuration.
The customer does not need to select Tasks, Roles, employees, rooms, or equipment.
From the customer’s perspective, the experience remains simple:
- choose a Service;
- choose an available time;
- book.
Behind that available time, SkedSERVICE can evaluate the Resource requirements defined by the Service’s Tasks and determine whether suitable Resources are available.
Why use Roles?
Avoid unnecessary dependence on one Resource
A Task can describe the capability it needs instead of depending permanently on one particular person, room, or piece of equipment.
Use interchangeable capacity
When several Resources can satisfy the same Role, SkedSERVICE can work with the suitable capacity that is actually available.
Reuse Tasks across Services
A Task can represent the work itself instead of being recreated for every individual Resource that might perform it.
Represent people and physical Resources consistently
Staff, rooms, stations, and equipment can participate in the same scheduling model.
Make availability more accurate
SkedSERVICE can determine whether the Resource requirements of each Task can actually be satisfied at the time the work needs to happen.
A simple way to think about it
The relationship can be summarized like this:
| Level | Question |
|---|---|
| Service | What is the customer booking? |
| Task | What work has to happen? |
| Role | What kind of Resource does that work need? |
| Resource | What actual available person, room, station, or equipment can satisfy it? |
That structure is what allows SkedSERVICE to describe a Service in terms of how the work operates while still giving the scheduling engine choices about which available Resources can make it happen.