Fieldcode Manual

Tip: You can use filters for better results

Last updated:October 4, 2024

How to configure dispatch groups

Copy the URL link to this section to share

Dispatch groups are used to define workforce areas for engineers, where the service can be provided. They are helpful in better organizing the work on the field. In the dispatch groups tab, you can assemble a team of engineers for a specific geographic area. The purpose is to focus the workforce on one area because having a dedicated group for your location is essential in the dispatch organizing process. You also have the option to customize the optimization behavior per dispatch group in this menu.

  • You need at least one created and active dispatch group to use the optimizer with success
  • If there is no active dispatch group set, the Ticket Pool in the Work Place (Dispatch tab) won’t display tickets and won’t display any engineers in the Timeline
  • It is necessary to have at least one engineer assigned, otherwise, group creation will not work
  • It is necessary to have at least one area generally defined, otherwise, group creation will not work
  • Please avoid creating groups with more than 30 engineers as it can negatively impact overall performance, rather try to create more groups in this case
  • An engineer can be used for multiple dispatch groups, Admin panel therefore also offers the possibility to assign one engineer for multiple dispatch groups
You will see engineer home bases with different colors inside the zone when defining or editing dispatch group zones. Red: Engineers home base is far from the defined zone (calculated outgoing from the border of the selected zone). Yellow: Engineer is some what close to the defined group zone (calculated outgoing from the border of the selected zone). Green: Engineer is inside the defined group zone (calculated outgoing from the center of the selected zone).

If you change dispatch group settings, this message may appear. This message indicates that this is a change that also affects tied tickets. As there may be a large number of tickets involved, this change may take some time. To avoid problems during regular business operations, such fundamental changes should be made outside of normal operations if possible. However, edits won’t break anything, they just may impact current performance as these changes occur.

How to create & edit dispatch groups

Copy the URL link to this section to share
  1. Inside the Admin panel go to  Dispatch → Groups
  2. Click on the plus button to open the New group form.
  3. Fill in the Basic, Area Definition, Filters, Engineers, Dispatch, and Optimization tabs.

1. Basic tab

Copy the URL link to this section to share
Business/Enterprise Feature

Some specific options inside the Basic tab are only available for customers with a Business or Enterprise plan. If you are subscribed for Enterprise by default both the "Activate fully automated dispatching" and the "Activate just-in-time publishing" are activated by default. These two additional options are not visible to non-subscribers.

Learn more about how to upgrade your plan
How the group timezone differs from the tickets' timezone

The group timezone you set doesn't change the tickets' timezone. It just displays the group's timezone on the Timeline so tickets can be scheduled by the dispatcher accordingly to the group's timezone.

  1. Toggle the Active toggle to the right to mark the user as active (that means the group is displayed inside Fieldcode Work Place).
  2. (Optional) – Turn your dispatch group into a test dispatch group by flipping the Test dispatch group toggle to the right.
    Test dispatch groups do not share data with the Analytics component and therefore have no impact on your reporting, analytics, or forecasting.
  3. Insert the name of your new or existing group.
  4. (Optional) – Insert a description of your new or existing group for better recognition.
  5. Select the timezone your new or existing group operates within.
  6. (Optional) –  Select a master group from the dropdown.
    Learn how to create master groups here.
  7. (Enterprise only) – Activate or deactivate fully automated dispatching
  8. (Enterprise only) – Activate or deactivate just-in-time publishing
  9. Click Save.
Dispatch Group Basic tab

2. Area definition tab

Copy the URL link to this section to share

The next step is to define the operational zone of your new dispatch group.
You have the option to define the area either manually or automatically.

You will see engineer houses with different colors inside the zone when defining or editing dispatch group zones.

Red: The engineer's home base is far from the defined zone (calculated outgoing from the border of the selected zone).
Yellow: The engineer is approximately close to the defined group zone (calculated outgoing from the border of the selected zone).
Green: The engineer is inside the defined group zone (calculated outgoing from the center of the selected zone).

How to define the area manually

Copy the URL link to this section to share
  1. Select the country and city where your group operates to make the map zoom to the area you want to select manually.
  2. Delete the preselected area by clicking on the top-right trash button inside the map to deselect the automatically inserted area.
  3. Confirm the deletion of the automatically inserted area by clicking the YES, DELETE button when prompted.
  4. Click inside the map to start selecting an area manually and to make a point appear.
  5. Connect the points.
  6. Close the area by clicking on the start point again from the last point.
  7. Confirm the area by clicking Save.
Workaround for crossing the the International Date Line (IDL)

If you draw an area crossing the International Date Line (IDL) you might run into troubles when creating the area. If you face this rare problem, please feel free to contact Fieldcode Support, so they can quickly help you work around this problem.

Manually drawing an operational area

Tips for manual area definition

You can delete individual points by clicking on a point and clicking on the trash button or go back to the last step at any time by clicking the revert button in the top-right corner of the map. Check out Example 1 (GIF).

You can delete individual points by clicking on a point and clicking on the trash button or go back to the last step at any time by clicking the revert button in the top-right corner of the map. Check out Example 1 (GIF).

You can easily add another point to the area by clicking the point in the middle of two points and dragging it to your desired spot. This will automatically add another point. Check out Example 2 (GIF).

Example 1

Deleting individual points + reverting to last step

Example 2

Defining the operational area more precise with the use of additional points

How to define the area automatically

Copy the URL link to this section to share
  1. Select the country where your group operates within.
  2. (Optional) – Select the state where your group operates within.
  3. Select the city where your group operates within.
  4. Click on the orange SHOW LOCATION button.
  5. (Optional) – Click on one area if you are prompted to select between areas.
    Important: Your group can only operate within one area.
  6. Confirm the area by clicking SAVE.
Defining the operational area automatically

3. (Optional) - Filters tab

Copy the URL link to this section to share

Fill in the filters tab to the specify tickets that are displayed for this specific dispatch group.
You can add filters (eg. status, project, country, etc.) or even grouped filters to further customize which tickets are displayed for the dispatch group.

Filter terms explained:

Filters: Allows fine-tuning criteria for dispatch groups with the use of comparison and logical operators. Click on the plus button to add a filter.
Condition: Defines a condition for your filter criteria.
Operator: Compares the condition with the comparison (IS EQUAL TO, IS NOT EQUAL TO, IS LIKE, IS NOT LIKE, IN).
Comparison Value: Defines with which value the condition is compared.
Connector: Allows you to combine a monitored field with another monitored field (AND, OR)

  1. Click on the Plus button to add a new filter or group filter.

Filters:

  1. Select a condition from the first condition dropdown.
  2. Select an operator from the first operator dropdown.
  3. Enter a Comparison Value from the Comparison Value dropdown.
  4. (Optional) – Add additional filters by clicking on the plus button in the first row and connect them with either AND or OR connectors.
Two active filters connected with the AND connector.

Group Filters:

  1. Select a condition from the first condition dropdown.
  2. Select an operator from the first operator dropdown.
  3. Enter a Comparison Value from the Comparison Value dropdown.
  4. Add additional filters by clicking on the plus button in the first row and connect them with either AND or OR connectors.
  5. Check the checkboxes inside the filters which you want to connect to a group. 
  6. Click on the Group button. A line left next to the filters indicates you which filters are connected to a group. Inside groups you can also create subgroups by checking filters inside a group and connecting them to a group by clicking on the group button.
Selecting filters which should be connected to a group
Grouping the filters. The x inside the line lets you ungroup a group.

Filter UX explained:

  • You can add more filters with the Plus button.

  • The group button lets you group filters together.
    You have to check the filters, that you want to connect to a group for the button to be displayed.

  • You can select conditions from the condition drop-down.
    You can learn what conditions are in the Filter Terms Explained section.

  • You can select operators from the condition drop-down.
    You can learn what operators are in the Filter Terms Explained section.

  • You can enter Comparison Values in the Comparison Value field.
    You can learn what Comparison Values are in the Filter Terms Explained section.

  • You can add more filters with the Plus button.

  • You can delete individual filters with the Delete button.

  • You can decide which relation a filter should have with another filter.
    It can either be an AND or an OR relation.

  • The Ungroup button lets you ungroup connected filters.
    The filters will remain inside the list without a group after ungrouping.

  • This row displays the date that has been entered in the system before any changes were made.

  • Dates marked in gray are not available for booking. This can be due to Custom Customer Portal configurations or these days are bank holidays or weekends.

  • Dates marked with a yellow triangle indicate limited engineer availability. Your ticket could might get moved by dispatchers to another spot if you select this date.

  • Dates marked with green triangles indicate the earliest and latest part availability dates. If a ticket needs special replacement parts in order to be resolved, the date should ideally be selected between the earliest and latest part availability date.

  • Your new date (and checked) selection is displayed with a border around the date.

  • This row displays bookable time slots.

  • You need to check this checkbox for confirming your appointment booking.

(Optional) - Filter examples

Copy the URL link to this section to share
Example: Dispatch group for Germany

You want to have one dispatch group for complete Germany, but you can't draw complete Germany with the draw-points-button inside the map, so you have decided to draw a wider area, where Germany is within. You can add a Country filter for Germany in this case, so only Germany is defined for your dispatch group, so you give the system more precise input. The IS EQUAL comparison is case-sensitive.
Your filter would be: affectedCountry is equal to Germany

Example: Company-specific dispatch group

You want to display tickets in a dispatch group company-specific, let's say for example the BetterClimate Corp. Instead of giving it the IS EQUAL operator you could also give it the IS LIKE operator. The IS LIKE operator considers values that aren't necessarily case-sensitive. This means a ticket that would contain the name betterclimate would also be taken into consideration because it contains something from the original value.
Your filter would be: affectedCompany is like BetterClimate Corp

4. Engineers tab

Copy the URL link to this section to share

The next step in the group configuration is to assign some engineers for your dispatch group. You will see all available resources in a list view with a kilometer sign next to their name on the left side.

The number of kilometers displays how far a technician is from the defined zone. This should simplify the selection of matching technicians for you.

RED: The engineer is far away from the defined zone (calculated outgoing from the border of the selected zone).
YELLOW: The engineer is approximately close to the defined group zone (calculated outgoing from the border of the selected zone).
GREEN: The engineer is inside the defined group zone (calculated outgoing from the center of the selected zone).

Assigning matching engineers to a Dispatch group
  1. Click on the engineer you want to assign to your group to transfer the engineer over to Selected engineers.
  2. Repeat step 1 for every other engineer you want to assign to your group.
  3. (Optional) You have the possibility to quickly move all resources from one side to another. 
    Click on ADD ALL on the left side or REMOVE ALL on the right side to do so.
  4. Click Save.

5. Dispatchers tab

Copy the URL link to this section to share

The next step in the group configuration is to assign some dispatchers for your dispatch group. You will see all available dispatchers in a list view on the left side. 

Assigning dispatchers for a Dispatch group
  1. Click on the user you want to assign to your group to transfer the dispatcher over to Selected Dispatchers.
  2. Repeat step 1 for every other dispatcher you want to assign to your group.
  3. (Optional) – You have the possibility to quickly move all resources from one side to another. 
    Click on ADD ALL on the left side or REMOVE ALL on the right side to do so.
  4. Click Save.

6. (Optional) - Optimization tab

Copy the URL link to this section to share

The optimization behavior can be customized per dispatch group. You can create custom profiles and use the profiles differently depending on the usage scenario. 
You can fully customize the route optimization preferences, time window parameters for tickets, PUDO appointment scheduling behavior, Skills requirement consideration, and/or apply the optimization only on individual tickets (filters) and many other options.

  • You can define which parameters should be considered at all during the optimization.
  • You can define how important/less important certain parameters are to achieve your specific optimization goal.
    The importance scale varies from 0 to 10.
    0=Less important; 10=More important
  • You can use filters to determine whether only certain types of appointments should be optimized or, for example, only certain projects or, for example, only tickets that are on the Timeline.
  • You can create several different custom optimizer profiles per group.
    This is useful, for example, if there are different usage scenarios per group and you, therefore, want to be able to quickly change the profile.
  • Please note that you can always have just one custom optimizer profile activated per group.

This high level of flexibility makes the Fieldcode Optimizer experience as unique and personal as your company.

Recommended Optimizer Settings

Copy the URL link to this section to share
Please note the optimization basics before using the recommended settings:
  •  One optimization can run for one dispatch group at a time.
  • We recommend no more than 15-20 engineers per group and no more than 200-300 tickets in the optimization scope.
  • With larger groups, you will notice exponentially longer calculation times for great results, as the number of possible combinations of matching engineers and tickets multiplies.
  • Fewer constraints give the optimizer more freedom and faster results (e.g. locking tickets or engineers unnecessarily, adding the earliest and latest date or hour, or distance constraints add complexity and limit valid scheduling options). Therefore, we recommend that you set up the application with only the absolutely necessary restrictions.
  • You can define the ticket scope not only in the Optimization settings of the Admin Panel, but also by setting the value of the Optimizable field on the tickets: Tickets that are unique in some way can be excluded from optimization by setting them to "Optimizable: No". For example, certain ticket subcategories or tickets from remote cities can be configured as out-of-scope for optimization, so that they are excluded from the optimizer's scope from the start, thus reducing the number of possible combinations. Please contact customer support if you need assistance setting up exclusion rules.
Please note the optimization profile basics before using the recommended settings:
  •  You can configure optimization settings for each dispatch group separately in Admin Panel / Dispatch Groups / Optimization. If you don't configure anything, optimization will still work with the default system settings.
  • A dispatch group can have multiple profiles, but only one active profile. The active profile defines which settings will be used when optimization is run for the group. If you'd like to try and compare how the optimizer performs with different settings, you can create (even clone) different profiles and switch between them by using the Active toggle. This way, if one setup works for you, but you'd like to check the performance of another setup, you can do so relatively risk-free.
Recommended Optimizer Settings

Route optimization preferences:

The route preferences slider sets up a relative importance of route alternatives.

Reduce driving distance slider: Move the Reduce driving distance or time slider to a higher value if the smallest drive is more important compared to the rest.
Reduce driving time slider: Move the Reduce driving distance or time slider to a higher value if the smallest drive is more important compared to the rest.
Schedule tickets as early as possible slider: Move the slider to a higher value if your main goal is to get the tickets dispatched at the earliest time even though it might result in longer routes.
Reduce idle time for engineer between tasks: Move the slider to the value of 10 if it's the upmost important goal for the business.

Time window parameters for tickets:

Service-level agreements checkbox: We recommend you turn this setting On if you have configured the SLA Profile for your tickets. If you for example have tickets with 2BD with business hours configured from 08:00 to 16:00, the Optimizer will only schedule tickets within those business hours, even if your engineers would work 24x7. You should turn the checkbox Off if you haven't configured SLA Profiles or the customer business hours are irrelevant to you, and you only care about the engineer's working hours.
Latest service delivery time (LSDT) checkbox: Turn On if you want to allow the Optimizer to schedule tickets only before LSDT expiration. Turn Off if you want to allow the Optimizer to ignore the LSDT and schedule tickets, even after LSDT expiration.
Earliest service delivery time (ESDT) checkbox: Turn On if you want to allow the Optimizer to schedule tickets only when the ESDT begins. Turn Off if you want to allow the Optimizer to schedule tickets, even before the ESDT begins.
Fixed interval appointment checkbox: We recommend you turn this setting On in general. If you turn this setting On the scheduling of tickets outside of the fixed service windows is forbidden, which is in general the behavior one should aim for. Turn Off if you want the Optimizer to ignore fixed service windows.
Proposed interval appointment checkbox: We recommend you turn this Setting Off in general. If you turn this setting Off the Optimizer ignores the proposed service windows which is in general the behavior one should aim for. It is also useful to turn this setting Off if your business doesn't utilize proposed service windows at all. Turn On if you want to allow the Optimizer to only schedule within the proposed service window.

PUDO Appointment scheduling:

Enable toggle: You can enable PUDO appointment scheduling if you’d like to schedule PUDO appointments with the Optimizer. If your group doesn’t work with cases with spare parts, we recommend turning the PUDO appointment scheduling Off.
Estimated time of arrival (ETA) checkbox: We generally recommend that you enable this setting to ensure that the Optimizer cannot schedule tickets and PUDOs before the part's actual ETA. If the Part ETA value is irrelevant to your scheduling processes you can turn this setting Off.
Opening hours checkbox: We generally recommend that you turn this setting Off, if you don't maintain PUDO opening hours and if they are irrelevant to your schedule processes. You can turn it On, however, if you are maintaining PUDO opening hours in the Admin Panel, and if you don't want that PUDO appointments can be scheduled by the Optimizer outside of those hours.
Use part storage time from project settings checkbox: We generally recommend that you turn this setting On. You can enable this setting if tickets or PUDO appointments shouldn't be scheduled by the Optimizer after the part storage end time. You can turn this setting Off if the part storage time is irrelevant to your schedule processes.

Skill requirements consideration:

Enable toggle: You can enable this toggle if you want the optimizer to check skill requirements on tickets and try to find matching tickets. We recommend turning the skill requirements consideration toggle to On.
Mandatory engineer skill cannot be violated checkbox: We generally recommend turning this On if mandatory skills must be matched. The Optimizer can only generate solutions where mandatory skills are matched. You can turn this checkbox Off if engineers with mandatory skills are preferred, but in case an unmatching engineer is found with e.g. a more optimal route, this engineer can be assigned as well. It can result in a lower optimization result score but can be, nonetheless, a valid solution.
Mandatory engineer skill slider: We recommend adjusting this slider according to individual business requirements. Moving the slider higher gives mandatory skill matching more weight in the optimization result score. Only move the slider to 10 if you want the optimizer to throw solution errors when criteria are not met.
Optional engineer skill slider: We recommend adjusting this slider according to individual business requirements. Moving the slider higher gives optional skill matching more weight in the optimization result score. Only move the slider to 10 if you want the optimizer to throw solution errors when criteria are not met.

Dispatching preferences:
Optimization picker: We generally recommend you pick the first option which is called "Does not set any service window (neither fixed or proposed). When the optimizer places a ticket on the Timeline, it doesn't set a fixed or proposed service window. This means that even though the ticket is on the Timeline, it cannot be published to the engineer's FMA until the Fixed/Proposed window is set in the Scheduling Assistant manually. If you pick the second option called "Sets a proposed service window (if one does not exist)" the following will happen. If the optimizer places a ticket on the Timeline without an existing service window, the optimizer sets a proposed service window with the optimization interval. You can publish the ticket without a dispatcher using the Scheduling assistant. (This can be useful if you want to publish tickets without fixing them with your customer).
Incorporate engineer efficiency factor into appointment duration toggle: We recommend turning this option On depending on how much you want to benefit from the configurable engineer efficiency factor. You can turn this option On if you want to take engineer efficiency numbers into account and let the Optimizer automatically set the appointment duration according to the average efficiency of your engineers. You can turn this option Off If all your engineers have the default efficiency or it's irrelevant for your scheduling processes.
Enhanced optimization toggle: We generally recommend you turn this option Off if you generally trust the optimizer to give you the best possible result in its runtime. If you turn this option On the Optimizer takes all your preferences into account and dispatches tickets to the Timeline according to the best possible solution score. However, if your rules and preferences are too strict, some tickets may be left in the Ticket Pool. Turn On the enhanced optimization if a "Full Engineer Timeline" is ultimately more important to you than the rest of the rules, and you'd like to run an extra check and possibly add some extra tickets to your Timeline with the most basic requirements (like a bulk Scheduling Assistant).

Driving preferences:
Maximum distance in kilometers input field: You have the option specify how much an engineer can drive within one day (including the first and last drive of the day and to PUDO and customer appointments). Be careful, if you set it to a lower number, it can reduce the potential routes that engineers can take. However, if you have a maximum mileage policy, feel free to adjust it accordingly. (Note: We have a 200 km soft range limit in the background, which means that the optimizer will give preference to scheduling tickets within 200 km, but will allow you to schedule further).
Maximum distance between stops on engineer's route input field: You have the option to freely define the maximum distance between each route segment. Again, if it's configured too restrictive (low number), it can backfire and result in a low number of scheduled tickets.
Driving before working hours allowed toggle: You can turn this option On if your engineers’ driving is not limited to their working hours. PUDO appointments or tickets won’t be scheduled outside of their hours, but drivetime can. You can enter the maximum amount of drive allowed (which of course shall be less than the difference between the start and end of two working days working hours). You can turn this option Off if driving is also considered to be an engineer's working time, then even driving times are not scheduled during non-working hours.

Miscellaneous:
Ticket score toggle with importance slider: We generally recommend you to turn On the ticket score toggle and adjust the importance slider freely to business requirements. You can turn this option On if you want the optimizer to consider the ticket score. Move the importance slider to 10 only if you want the Optimizer to display a solution error if a ticket with a lower score is placed on the Timeline against a ticket with a higher score (If you do this, it can, however, significantly reduce the number of solutions). You can turn this option Off if you don't define ticket scores in the Admin Panel at all or if ticket scores are irrelevant to your scheduling process.
Fixed tickets stay on the Timeline toggle with importance slider: We generally recommend you turn On the "Fixed tickets stay on the Timeline" toggle and adjust the importance slider freely to business requirements. You can turn this option On if it's important that fixed tickets already on the Timeline stay there and no other tickets can be moved to the Timeline at the expense of removing them. Move the importance slider to 10 if it's critical to the business that fixed tickets stay on the Timeline and violating this rule would result in the display of solution errors. You can turn this option Off if fixed tickets on the timeline have no special importance in scheduling compared to other tickets. The Optimizer will still schedule tickets within the fixed service window if configured to do so, but will not give them additional priority.
Scheduling offset toggle with minutes input field: The offset defines what is the earliest time the Optimizer can schedule anything, so we ensure there is time for dispatchers to maintain communication with the engineer/customer, publish tickets, etc. before the engineer needs to start working on a case. We generally recommend leaving it turned On with the default settings, even if you don't schedule for the same day, as it won't have any negative impact. 

Filters:
The filters applied here will be the pre-set filters for each optimization run. Therefore please only configure filters if you want to exclude tickets/engineers from the optimization scope in general.
Filtered by service window filter: You can enable the filter if you want to put only those tickets on the Timeline that have a fixed service window already. Use case example: You need the end user to book an appointment on the customer portal or the ticket is created with a fixed service window or the dispatcher has already called the customer. Therefore, no appointments can be added to the Timeline without first fixing it with the customer.
Excluded projects filter: You can exclude certain projects from the optimization scope. Use case example: You are managing a project where cases should be handled manually.
Filter by engineers in scope filter: Partner engineers are excluded from optimization anyway, so feel free to exclude them right away. If you have some other special engineers who will receive tickets only by some manual action, exclude them as well by de-selecting them in the dropdown.

Optimizer Settings Explained

Copy the URL link to this section to share
  1. Inside the Optimization tab click on the plus button to add a new custom profile. Alternatively, you can edit an existing custom profile by clicking on the item.
  2. Enter a name for your new or existing custom profile.
  3. You can then edit all the different settings.
    The individual settings are explained further below.
  4. (Optional) – You are able to reset a profile to default optimization parameters by clicking on the black Reset to default button inside a profile.
  5. Click Save after configuring all the parameters to your requirements.
Creating a new custom optimization profile. You can also see the RESET TO DEFAULT button which will revert back to default parameters.
Use case scenario: V-KOM telecommunications company

The international telecommunications company V-KOM is responsible for internet coverage in several countries and cities. For service requests, it uses Fieldcode as the primary ticketing system. In the following sections we will use this scenario to explain the impacts of using a custom optimization profile.

Route optimization preferences

You can configure your route optimization preferences by their importance to your business. These preferences are non-exclusive, you can give any combination of importance to different factors. You can influence which route options and resource allocations will be preferred and result in a better optimization score.
Let’s have a closer look at which setting does what exactly.

Adjusting sliders inside the Route optimization preferences
  • Reduce driving distance slider
    Assign higher importance to this parameter if reducing driving distance (in meters) plays crucial role for you.
    You can reduce maximum amount of CO2 emission with this parameter if you give it high importance.
Use case

V-KOM really cares about getting as CO2 friendly as possible. They therefore want to put a high weight on the Reduce driving distance, V-KOM chooses 10.

  • Reduce driving time slider
    Use this setting if you are paying your workforce for their spent time per day.
    We will optimize the schedule to reduce driving times per engineer.
    The CO2 footprint might rise with this parameter if you give it high importance.
Use case

V-KOM pays their engineers a fixed salary per month, therefore they prefer a lower CO2 footprint as they can freely utilize their engineers. V-KOM chooses 3.

  • Schedule tickets as early as possible

    Use this setting with higher importance if delivering as many tickets as early as possible is important to you. Delivering as many tickets as possible as early as possible may result in longer driving distances.

Use case

V-KOM has different locations, and every location is treated differently from a business perspective. For their small engineering team in Kassel (DE), they choose that they want to deliver as many tickets as early as possible because they have pilot project going on there, and service requests must be handled with top priority. V-KOM, therefore, chooses the value 10.

  • Reduce idle time for engineers between tasks slider
    Use this setting with higher importance if you want to shorten the wait in-between task assignments time by reducing idle times.
    Having reduced idle times for your engineers may lead to more tickets getting done per day, but also higher engineer frustration potential.
Use case

V-KOM generally attaches great importance to customer satisfaction, but also to employee satisfaction. Therefore, the company considers it important to comply with idle times to not put too much stress on engineers. V-KOM, therefore, chooses 3 as weight.

Time window parameters for tickets

When dispatchers schedule tickets, it is important that they fit them on the desired time window which is satisfactory both for contractual requirements.
Our system can use several parameters to either precisely or loosely define the time window where a ticket has to be assigned by the optimizer. 
Let’s have a closer look at which setting does what exactly.

Adjusting the time window parameters that should be taken into consideration
  • Service-level agreements (SLA) checkbox
    Tickets can have an SLA Profile set up which defines business days and business hours when service delivery can happen. If this setting is enabled, the optimizer will check the business hours relevant to the ticket and will not schedule it outside of these hours. If there is no SLA definition on the ticket, the optimizer can schedule it 24×7 when an available engineer is found.
How can I fully benefit from SLA profiles?

If you want to learn how to fully benefit from SLA Profiles, please check out the following topic: SLA Profile Walkthrough

Use case

V-KOM competes with many other large Internet providers. They, therefore, use strict SLA agreements to maintain quality standards. V-KOM has therefore stored an SLA profile in the Fieldcode Admin Panel that the optimizer can now also use to schedule tickets on time. This checkbox is activated by V-KOM.

  • Latest service delivery time (LSDT) checkbox
    If enabled, the optimizer will not schedule appointments that start later than LSDT. If disabled, the optimizer will ignore the LSDT value even if provided.
Use case

V-KOM competes with many other large Internet providers. Therefore, LSDT is also a decisive criterion for tickets. This checkbox is activated by V-KOM.

  • Earliest service delivery time (ESDT) checkbox
    If enabled, the optimizer will not schedule appointments that start earlier than ESDT. If disabled, the optimizer will ignore the ESDT value even if provided.
Use case

V-KOM competes with many other large Internet providers. By complying with ESDT, V-KOM is able to differentiate itself from many competitors. Therefore, they let the optimizer include this criterion as well. This checkbox is activated by V-KOM.

  • Fixed interval appointment checkbox
    If enabled, the optimizer will not schedule appointment outside of the Fixed appointment time frame. In case the Timeline is overplanned or too many tickets have a Fixed appointment time frame for not enough resources, some tickets will stay or be sent back to the Ticket Pool. If disabled, the optimizer ignores the Fixed time frame and can put tickets to different places. We do not recommend doing so as it can result in some data inconsistencies.
Use case

V-KOM wants to benefit fully from the advantages of the optimizer. Strict adherence to fixed deadlines for scheduling tickets should therefore be strictly observed by the optimizer. This checkbox is activated by V-KOM.

  • Proposed interval appointment checkbox
    If enabled, the optimizer will not schedule appointments outside of the Proposed appointment time frame. In case the Timeline is overplanned or too many tickets have a Proposed appointment time frame for not enough resources, some tickets will stay or be sent back to the Ticket Pool. If disabled, the optimizer ignores the Proposed time frame and can put tickets to different places.
Use case

V-KOM wants to benefit fully from the advantages of the optimizer. Strict adherence to proposed deadlines for scheduling tickets shall therefore be strictly observed by the optimizer. This checkbox is activated by V-KOM.

PUDO appointment scheduling

In this section, you can configure how optimizer considers PUDO appointment scheduling. If this parameter is turned on, optimizer will check all part requirements on the tickets and in case parts are delivered to PUDO locations, it schedules the PUDO appointments prior to customer appointments. We recommend turning this parameter on, otherwise PUDO appointments might not be created or not in the optimal way for your onsite engineers day.
Let’s have a closer look at which setting does what exactly.

Adjusting the PUDO appointment scheduling preferences
  • PUDO appointment scheduling toggle
    If this parameter is turned on, the optimizer will check all part requirements on the tickets and in case parts are delivered to PUDO locations, it schedules the PUDO appointments prior to customer appointments.
Use case

V-KOM has several small locations distributed in each city from which needed spare parts for repairs are obtained. Therefore, it naturally makes sense that these PUDO locations should be considered by the optimizer in the planning before technicians leave for troubleshooting. This checkbox is activated by V-KOM.

  • Estimated time of arrival (ETA) checkbox
    If enabled, the optimizer will check the ETA time for parts and not schedule a PUDO appointment before ETA. If disabled, the optimizer takes as all necessary parts are already delivered.
Use case

V-KOM is known for its amazing service skills. Many people do not know that a lot of work is needed in the background to maintain this high level of service competence. This also includes the efficiency in logistics when procuring spare parts. So, in order not to waste resources because spare parts are not yet at the PUDO site, the optimizer should schedule PUDO appointments only when the spare parts are actually available for pick up. This checkbox is therefore activated by V-KOM.

  • Opening hours checkbox
    PUDOs can have opening hours maintained in the Admin Panel. If this parameter is enabled optimizer will check the opening hours on the PUDO and not schedule tickets outside of opening hours. If there are no opening hours defined or this setting is disabled, it is considered that the PUDO is open 24×7.
Use case

V-KOM PUDOs do not have opening hours. Speed is everything when it comes to fixing internet problems. Opening hours are therefore only a hindrance in this respect and since V-KOM manages its PUDO sites itself, they rely on a 24x7 model for their PUDO sites. Therefore V-KOM deactivates this checkbox.

  • Use part storage time from project settings
    Parts are stored at PUDOs for a limited time only. In Project settings, part storage interval can be configured and by enabling this option, the optimizer will consider the part storage interval and only schedule PUDO appointments between part ETA and storage time end (if both are provided).
Use case

V-KOM logistic partners usually keep spare parts available for its technicians for a maximum of seven days before they are sent back. Since V-KOM has already configured a spare parts storage time inside Admin Panel -> Projects , V-KOM decides to activate this checkbox and use this already configured setting.

  • Earliest time before ticket info field
    Our system default is that PUDO appointments are scheduled the same day (or max. 8 hours before).
  • Latest time before ticket info field
    Our  system default is that PUDO appointments are scheduled the same day (or max. 8 hours before).

Skill requirement consideration

If admins don’t want to see engineers assigned to tickets they don’t qualify for based on their skills, admins should enable the Skills consideration for optimizer. If disabled, optimizer will not check if engineers have the matching skills, only other availabilities, ticket requirements.
Let’s have a closer look at which setting does what exactly.

Adjusting the skill requirements consideration preferences
  • Skill requirements toggle
    If admins don’t want to see engineers assigned to tickets they don’t qualify for based on their skills, admins should enable the Skills consideration for the optimizer. If disabled, the optimizer will not check if engineers have the matching skills, only other availabilities, and ticket requirements.
Use case

V-KOM technicians are often confronted with very different problems. From a complete system failure in one region to the most diverse customer appointments, everything is represented. Therefore, V-KOM technicians have different areas of expertise. Since V-KOM has added many skills to the system and always wants to provide the highest level of expertise to the customer, V-KOM activates this checkbox, so the optimizer always tries to pick the best matching engineers.

  • Mandatory engineer skill cannot be violated checkbox
    If you enable this, the optimizer will never assign tickets to engineers not matching the mandatory skill requirements. It can mean that you have fewer tickets assigned, but no engineer with lacking skill will be assigned to a task they are unqualified for. If disabled, engineers having the matching skill are still preferred by the optimizer, but if we have more tickets than engineers, some tickets might be assigned to not matching engineers.
Use case

There are various problems that can only be solved if the right technician is utilized. For example, if an Internet cable is damaged by construction work, the particular skill "welding with special tools" is required. Therefore, only technicians with this special skill should be used for this kind of operation. The optimizer should consider this requirement. Therefore this checkbox is activated by V-KOM.

  • Mandatory engineer skill importance slider
    You can adjust the weight for the optional skill-matching here. Adjusting the slider changes the importance of the mandatory skill-matching for the optimizer. If you maximize the value here, it could mean that mandatory skill matching is even more important for you than route optimization. 
    Moving the slider to the highest value (10) means that mandatory skills are so important that the optimizer returns with solution errors if the criteria are not met.
Use case

V-KOM really cares that mandatory skills are considered as important inside the optimizer, so V-KOM chooses the highest value: 10.
The highest value (10) means mandatory skills are so important, that the optimizer returns with solution errors, if the criteria is not met.

  • Optional engineer skill importance slider
    You can adjust the weight for the mandatory skill-matching here. Adjusting the slider changes the importance of skill-matching for the optimizer. If you maximize the value here, it could mean that optional skill matching is even more important for you than route optimization.
    Moving the slider to the highest value (10) means that optional skills are so important that the optimizer returns with solution errors if the criteria are not met.
Use case

When considering optional skills, the optimizer should be given maximum planning freedom, so V-KOM chooses the value 0 here.
If they had chosen the highest value (10), it would mean that optional skills are so important that the optimizer would return with solution errors if the criteria were not met.

Dispatch preferences

  • Does not set any service window (neither fixed or proposed) checkbox
    With the first available option, the optimizer will not set any service window (neither fixed nor proposed). If tickets have already a service window, it is kept. For other tickets, as a result, a dispatched time and engineer will be set for the appointment. To be able to publish the latter, dispatchers need to open the Scheduling assistant and set up the service window
Use case

V-KOM wants as much automatization as possible, the optimizer should therefore decide by itself to set service windows when optimizing. Therefore the second checkbox makes more sense for V-KOM, where a proposed service window should be set automatically. V-KOM doesn't check this box.

  • Sets a proposed service window (if one does not exist) checkbox
    With the second option, the optimizer sets a proposed service window for those tickets that did not have a proposed or fixed service window prior to optimization. The proposed service window in this case is the optimization interval.
Use case

V-KOM wants as much automatization as possible, the optimizer should therefore decide by itself to set service windows when optimizing. Therefore the second checkbox makes more sense for V-KOM, where a proposed service window should be set automatically. V-KOM activates this box.

  • Enhanced optimization toggle
    If enabled, on optimization takeover, a background process will check non-dispatched tickets in optimization scope and try to place them on the Timeline in case there is free capacity on any engineer still left. The process goes through tickets like Scheduling assistant would do, but in an automated way prioritizing tickets with service window and higher score first. It might place tickets which optimizer wouldn’t do as it can be higher driving times and costs. Enable this option if it’s important to you to fill all gaps on the engineer’s Timeline even if it’s not optimal. 
Use case

V-KOM wants as much automatization as possible, the optimized should therefore decide by itself to fill up gaps in the engineer's time table (if capacity is left). V-KOM activates this checkbox.

Driving preferences

Travel is a crucial part of field service delivery. In this section, you can set up controls for engineers’ routes.
  • Maximum distance in kilometers input field
    By default, optimization excludes all tickets or tickets with PUDO locations further than 300 km away from any engineer. Experience shows that no engineer will be found who can drive so much during a workday, so we exclude such tickets for better performance. In case you’d like to define a different radius, you can set a different number of kilometers here.
Use case

V-KOM's engineering group in Kassel is spread over a very large area within the city. Nevertheless, V-KOM attaches importance to the fact that technicians are always suitably distributed in groups, therefore V-KOM differentiates between city groups and suburban groups. This fine grouping makes it possible to set the maximum distance for the optimizer relatively low because technicians further away are in other groups anyway and use a separate, tailored optimization profile. Tickets should therefore only be taken into account by the optimizer if they are located a maximum of 50 kilometers outside the defined operational area. V-KOM, therefore, enters the value 50 km here.

  • Maximum distance between stops on engineer’s route (in kilometers)
    By adding a maximum distance between stops, you can limit the distance that the optimizer will use to schedule tickets between each stop.
Use case

V-KOM wants to keep driving distances between stops not overly long in general, V-KOM therefore sets 100 km as maximum distance between stops. 

  • Driving before working hours allowed toggle
    Some business profiles expect their engineers to drive to the first appointment before their working hours start or drive home after working hours at the end of the day. You can control how the optimizer shall treat working hours in regard to driving. If Driving before/after working hours is disabled, engineer driving time will be calculated within working hours. If enabled, you can configure what’s the maximum amount of time an engineer can drive before or after hours. They could be different and set according to your business preferences.
Use case

V-KOM's company policy is that driving time counts as working time. V-KOM therefore deactivates this checkbox.

  • Driving after working hours allowed toggle
    Some business profiles expect their engineers to drive to the first appointment before their working hours start or drive home after working hours at the end of the day. You can control how the optimizer shall treat working hours in regard to driving. If Driving before/after working hours is disabled, engineer driving time will be calculated within working hours. If enabled, you can configure what’s the maximum amount of time an engineer can drive before or after hours. They could be different and set according to your business preferences.
Use case

V-KOM's company policy is that driving time counts as working time. V-KOM therefore deactivates this checkbox.

Miscellaneous

This section allows admins to configure miscellaneous settings for the Optimizer.
Let’s have a closer look at which setting does what exactly.

  • Ticket score toggle with importance slider
    If enabled, the optimizer will check the ticket score and higher ticket scores will get higher priority to get assigned to engineers.
    With the scale on the right, you can adjust the importance the ticket score plays in optimization.
    Moving the slider to the highest value (10) means that ticket scores are so important that the optimizer returns with solution errors if the criteria are not met.
Use case

V-KOM prioritizes tickets by importance so that serious problems with severe impacts are solved faster than normal problems. V-KOM has previously configured this in the ticket scoring menu. Now the optimizer should also take this into consideration, therefore V-KOM activates this checkbox and sets the value 10. Since V-KOM picked the value 10, the optimizer will even return solution errors, if the criteria couldn't be met.

  • Fixed tickets stay on Timeline toggle with importance slider
    If a ticket has a fixed time frame, we treat that there is already a customer agreement on the service delivery time frame which shouldn’t be violated. With this parameter, fixed tickets will be preferred to stay on the Timeline or be placed on the Timeline against those that don’t have any time frame set yet. Here you can also adjust the importance of this parameter if you want to ensure that as least tickets as possible are moved from Timeline. If you do so, it can result in longer driving and overall fewer tickets delivered, but customer agreements will not be harmed as a positive side note. 
    Moving the slider to the highest value (10) means that fixed tickets should stay on Timeline is so important that the optimizer returns with solution errors if this criteria is not met.
Use case

V-KOM strives to maintain maximum customer satisfaction on the one hand, but on the other hand, is also responsible for solving general problems quickly. This is a difficult balancing act. In order to maintain a healthy balance, V-KOM chooses to activate this option with a value of 5.

  • Scheduling offset toggle with time field
    This setting ensures that the optimizer doesn’t schedule anything in the past. Our default offset is 30 minutes which means that nothing will be scheduled earlier than 30 minutes from now. You can adjust the times here and set a different offset if your business has different requirements.
Use case

V-KOM is committed to the fact that as many tickets as possible are scheduled directly by the optimizer without any additional time offset.
Therefore V-KOM deactivates this setting.

Filters

In case admins would like to apply some specific filtering on optimization runs, they can do it from the Filters section.
Note: By default, all tickets get optimized!
Let’s have a closer look at which setting filters what exactly.

Filtering what appointment types and projects should be optimized - also with the option to optimize the Timeline only
  • Filtered by service window dropdown
    Only fixed appointments are optimized    : Optimizer will only take those tickets in the Ticket Pool which have a Fixed time frame and tickets already on the Timeline for optimization interval and optimize them. Tickets not having a Fixed time frame will be excluded from optimization.
    Only proposed appointments are optimized: Optimizer will only take those tickets in the Ticket Pool that have a Proposed time frame and tickets already on the Timeline for optimization interval and optimize them. Tickets not having a Proposed time frame will be excluded from optimization.
    Only Fixed and Proposed Appointments are optimized: The optimizer will only take those tickets in the Ticket Pool which have a Fixed or Proposed time frame and tickets already on the Timeline for optimization interval and optimize them. Tickets not having a Fixed or Proposed time frame will be excluded from optimization.
Use case

V-KOM intends to benefit fully from the optimizer. Therefore, all appointments should really be optimized, V-KOM believes that the manual rework should subsequently be done by the dispatchers. V-KOM, therefore, selects the All option.

  • Excluded projects dropdown
    In case certain projects are supposed to be scheduled only manually and not in an optimized way, they could be excluded from optimization.
    Tickets under these projects will be ignored by the optimizer even if they are in the same dispatch group as other tickets in scope.
Use case

V-KOM would like to find out within the analytics whether optimized groups perform better than non-optimized groups. For a specific project, optimization is therefore excluded. This project with the name "Non-optimized" is therefore selected in the dropdown.

  • Engineers in scope dropdown
    In case only certain engineers should be in optimization scope you can select those individually.
    If you select all, all engineers will in optimization scope.
    If you select nothing, all engineers will be in optimization scope.
Use case

V-KOM wants to pilot the optimizer first with a few engineers before fully relying on it. Miller and Smith are the engineers in scope for this custom test-profile. V-KOM therefore only selects "Miller" and "Smith" in the Engineers in scope dropdown. All other engineers should not be considered when optimizing.

Did you know?

The engineers in scope settings inside the Dispatch groups menu is a global setting.
You can always also decide which engineers should be in scope when you are actively using the Optimizer inside the Place.

  • Optimize Timeline only checkbox
    In case Optimize Timeline Only is selected, the default parameter for the Optimizer will be to optimize the Timeline only.
    Dispatchers can change this behavior on-the-fly when starting the optimization.
Use case

V-KOM wants as much automatization as possible. Therefore, V-KOM therefore renounces the option that only tickets on the Timeline should be optimized. However, dispatchers still have the option to change this behavior when they start an optimization run.

Was this topic helpful?
5 out of 5 stars

1 rating

5 Stars 100%
4 Stars 0%
3 Stars 0%
2 Stars 0%
1 Stars 0%
5
How can we further improve this topic?
Please provide the reason for your vote. This will help us improve this topic.
Tags:
Navigation