Fieldcode Manual

Tip: You can use filters for better results

Some basic knowledge before we explore the applications in depth...

Tickets are the smallest piece of information within Fieldcode applications. Basically, every interaction with an affected customer can be handled inside a ticket. We intentionally offer various possibilities to categorize tickets (categories, sub-categories, or ticket types) and structure all important information within a ticket to give you enough space to use Fieldcode exactly as you need it. Our application is designed to provide you with the best possible insights on the status of a ticket within its life cycle. Therefore you will find multiple ways to search, find, display, and analyze tickets.

We also started adding our new feature container tickets, what they are, what their purpose is, and how to use them is described here.

Above you can see how a ticket in the Ticket Pool list is displayed

Each ticket in your Fieldcode Work Place belongs to one project, whereas you are allowed to create as many projects as required to display and structure your service delivery. Projects can reflect contracts with different customers to split tickets by category or other features. That depends on your preferences and use cases. Nonetheless, splitting tickets by customer gives you the best way to analyze KPIs and keep important Service Level Agreements in focus.

A project generally is the foundation of a defined set of rules customized to meet business requirements. Depending on how deeply you define the project it can be either very specific or very general. Bigger companies, for example, may have very specific requirements for projects (eg. three-strike rules, special reports, etc.), while small companies may have just a very generic set of rules for their projects to get the job on the field done. The first project for example could use different workflows than the second project which includes additional statuses, custom reports, or even some different anonymization settings.

We call the lifecycle of the ticket the workflow. The workflow reflects all possible steps available for a ticket and determines which actions are available. Initially, we provide you with a basic workflow that covers all standard Field Service Management use cases and helps you understand what is going on in every phase of the ticket. 

Step ≠ Status

A step is usually a waypoint to further progress to some status - what you see described below in the picture is the statuses, not the different workflow steps.

Simplified view on our workflow model

Ideally, a ticket in the process should follow the happy path until it is resolved, which is marked green in the scheme above. Exceptional paths, marked in red can occur but should lead back again to the happy path for the ideal procedure and completion of a ticket.

The workflow is not only supposed to indicate the status of the delivery but also helps to manage who should do what and when: The ticket inside the workflow allows for certain actions (see Interactions) or automatically triggers events (See Automated Actions) based on the progress of the workflow.

"We believe that the key to great service quality is the alignment of processes with less room for individual errors but enough space for direct actions"
Annika Goeres
- former Product Manager UX/UI

Workflows are designed to align all users of one process throughout the delivery chain, nevertheless, leaving enough freedom to handle and manage customer inquiries properly and quickly without the impediments of a static system.

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 submit the reason for your vote so that we can improve this topic.
Tags:
Navigation