Fieldcode Manual

Category filters can help you narrow down search results

Last updated:

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 Fieldcode 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
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.

Enterprise-only options
  • If you are subscribed for Enterprise by default both the "Activate fully automated dispatching" and the "Activate just-in-time publishing" are active
  • Options are not displayed for non-subscribers.
Learn more
  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 specify tickets that are displayed for this specific dispatch group.
You can add filters (eg. status, project, country, etc.) to further customize which tickets are displayed for the dispatch group.
The trash symbol right next to a filter lets you delete a filter.
Click Save after you have configured your filters.

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)

Specifying tickets for the Dispatch group

(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.

  • Basically, you can define, for example, which parameters should be considered at all during the optimization.
  • You can also 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
  • Finally, you can even 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.
  • All those above-mentioned settings are realized with the creation of a custom optimization profile.
  • 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.
  • You can always have just one custom optimizer profile activated per group.

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

  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.
Optimizer profile settings and Fieldcode Work Place

When changing optimizer settings in the Admin Panel, Work Place must be manually reloaded for the settings to be applied (Reload button or CTRL+F5).

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.
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 input field
    You can configure what is the earliest and latest time to schedule a PUDO appointment before customer appointment. You will have a chance to enter the SAME DAY, PREVIOUS DAY, and CUSTOM TIME INTERVAL. Until then, our system default is that PUDO appointments are scheduled the same day (or max. 8 hours before).
Use case

V-KOM PUDOs should be visited by technicians one day before the actual service date.
Therefore, "Previous day" is selected in the first dropdown.

  • Latest time before ticket input field
    You can configure what is the earliest and latest time to schedule a PUDO appointment before customer appointment. You will have a chance to enter the SAME DAY, PREVIOUS DAY, and CUSTOM TIME INTERVAL. Until then, our system default is that PUDO appointments are scheduled the same day (or max. 8 hours before).
Use case

V-KOM PUDOs should be visited by technicians on the same day of the service appointment at the latest.
Therefore, "Same day" is selected in the second dropdown.

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.
Use case

V-KOM really cares that mandatory skills are considered as important inside the optimizer, so V-KOM chooses the highest value: 10.

  • 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.

Dispatching preferences

Use case

When considering optional skills, the optimizer should be given maximum planning freedom, so V-KOM chooses the value 0 here.

  • 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.
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.

  • 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 which 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.
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?
0 out of 5 stars
5 Stars 0%
4 Stars 0%
3 Stars 0%
2 Stars 0%
1 Stars 0%
How can we further improve this topic?
Please submit the reason for your vote so that we can improve this topic.
Tags:
Navigation