Welcome to the Fieldcode Manual

Type a term in the box to instantly list helpful topics. Category filters help to 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).

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, and Engineers 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.
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.

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 01: 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 02: You want to display tickets that belong to a specific company, let’s say for example 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.

(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.
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: 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, so they choose 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. They choose a 3.

  • Schedule as many tickets as possible slider
    Use this setting with higher importance if delivering as many tickets as fast as possible is important to you.
    Delivering as many tickets as fast as possible also means longer drive 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 possible because they have pilot project going on there, and service requests must be handled with top priority. 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. They, therefore, choose 3 as weight.

Time window parameter 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. The checkbox therefore remains selected.

  • 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. The checkbox remains selected.

  • 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. The checkbox remains selected.

  • 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. The checkbox remains selected.

  • 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. The checkbox remains selected.

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. The checkbox remains selected.

  • 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. The checkbox remains selected.

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

  • Earliest time before ticket selector (COMING SOON)
    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 selector (COMING SOON)
    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, it 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, so V-KOM activates this checkbox.

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

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

Miscellaneous

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

Adjusting other miscellaneous optimization preferences
  • Maximum distance in kilometers field
    By default, optimization excludes all tickets or tickets with PUDO locations further than 300 km away from any engineer. Our experience shows that we will find no available engineer 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 15 kilometers outside the defined operational area. V-KOM, therefore, enters the value 15 here.

  • 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 sets this value to off.

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
  • Scheduled appointments only 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.

  • 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 everything to be as automatic as possible. Therefore, V-KOM abandons 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 article helpful?
How can we improve this article?
Please submit the reason for your vote so that we can improve the article.
Table of Contents