Delivery Handling (Intermediate)

Flowset Templates

Flowset templates can be used as a starting point for a workflow implementation.  Simply find the template that best matches your process requirements and then clone it.  See Workflow Templates for details of using Flowset Templates.

Process Summary

An efficient "Delivery Handling" process is important for addressing problems customer may experience when placing and receiving orders for goods. Keeping customers informed about their delivery, and offering refunds where appropriate, promotes  a high degree of customer satisfaction.

This template implements the aspects of an intermediate level Delivery Handling  process including :

• A Triage activity to record contextual customer data and to clarify and classify complaints
• A dedicated activity to gather and analyse photographic evidence
• A set of follow on activities designed to handle a specific classification of complaint including :
  • appropriate interactions with an external order processing system
  • offering standard refunds to customers
• A simple escalation activity providing technical support for the order processing system.
• Alternative routes out of Triage and Escalation to reject invalid complaints as details become clearer

Template Design

This template builds on Delivery Handling (Basic)

It is recommended read this article first to understand the more fundamental features of workflows and to appreciate how this intermediate version extends these.

It consists of a number of activities. Each activity represents a set of tasks that need to be performed before moving on to the next activity.  Often these activities will generate standard responses to be sent to the customer based on data values entered earlier in the process. The delivery handling process will be finished when all activities have been completed. 

 

Figure 1

(the red numbers are not part of the workflow diagram and are for annotation purposes only)

Figure 1 shows the top level workflow diagram for the Delivery Handling (Intermediate) template.

The start shape (1) points to the first activity (2).

The activities (in green) show the main steps in the process. These are :

• Triage (2)
• Gather Photographic Evidence (4)

followed by one of the following "handling" activities (7) 

• Wrong Order
• Wrong Items
• Missing Items
• Poor Quality
• Order Not Received

As we will see later, the starting activity, Triage (2), classifies genuine complaints into one of the following complaint types : 

Wrong Order, Wrong Items, Missing Items, Poor Quality Order, Order Not Received

After, Gather Photographic Evidence (4),  the workflow presents a follow-on activity designed to handle each of these complaint types.

At runtime, Outcome Controlled Transitions (6) govern which of the follow on activities (7) is available. Once complete these follow on activities can finish the workflow with their appropriate transition path (12)

Each follow on activity can make use of an Escalate activity (10) if required. Eg Wrong Order can escalate via path (8) and the Escalation team can return control of the ticket to them later via path (9)

There are also alternative ways to complete the workflow using rejection routes (3), (5) and (11) . These are represented by paths to different stop shapes, These paths have transition comments associated with them that explain the reason for the rejection

 

Outcome Controlled Transitions

Moving from an activity to a following activity (or to the end of the workflow) is known as a transition. In a workflow diagram a transition is represented by a line connecting the source activity to the target activity or stop shape. A transition can be controlled by an outcome whose name is shown as a label on the line. The outcome is calculated from the data values entered when completing the source activity. Outcome controlled transitions can only be followed if their outcome has been satisfied by completing the current activity. 

This process uses many outcome controlled transitions to ensure that only the appropriate onward activity is available.

 

Process Persisted Fields

Activities will normally gather information to allow their tasks to be completed.  This information is typically local information known only to the activity being performed.  Once you transition on to the next activity, it will gather it's own information to allow it to compete.  There are times, however, where some information gathered in an activity may be needed in subsequent activities.  For example, the type of complaint can drive which onward activity should be chosen to handle it.

Process Persisted Fields can be accessed from any activity and prevent the need to keep asking the same questions in different activities. They can also be used as Helper Fields The process persisted fields defined in this workflow template are :

Name	Field Type	Description	Helper
Customer Order Number	Reg Exp	Records the customer order number in the correct format and displays it for reference in subsequent activities, usually read-only	No
Complaint Type	Drop Down	Records the classification of the complaint into one of : Wrong Order, Wrong Items, Missing Items, Poor Quality Order, Order Not Received, Complaint Rejected	Yes
Photo Rejected	Checkbox	Used to record the rejection status of the photo as a common variable for conditional logic inside Gather Photographic Evidence	Yes
Has the order been cancelled	Yes / No	Set by the Escalate activity requested from one of the onward complaint type handling activities. Its value allows a different path to be followed when control returns to the handling activity, one that understands it has already been through escalation.	Yes
Refund Type	Drop Down	Set by the "Poor Quality Order" handling activity to determine if a partial or total refund should be offered. Its value allows the correct path (partial or total) to be followed when control is returned from escalation.	Yes

 

Detailed Design

The sections below describe details of the tasks involved in these top level activities.  See Activity Task Modelling for details of how to define task flows for an activity.

Triage (Activity)

This activity examines the customer's profile and categorises their complaint.

Click on the arrow icon   in the top left of the Triage activity shape to open its task flow diagram : 

Figure 2

(the black numbered boxes are not part of the task flow and are for annotation purposes only)

In this task flow diagram : 

• brown rectangular boxes represent tasks which typically define fields to capture user input
• orange diamonds represent decisions that determine the onward path using conditions that can be based on task data entered earlier in the flow
• The blue circular stop shapes indicate the different ways in which the task flow can complete with an associated activity outcome.

The Task Flow

Firstly let us describe the high level logic implemented by the task flow; later we will see how the components of the tasks and decisions are defined using property panels

1. The first task (1) captures an optional order number. A task field uses a Process Persisted Field of type Regular Expression to preserve the value in the correct format so that it can be referenced in subsequent activities
2. Task (2) then asks about the customer's ticket history and any correlating factors
3. If this is a new customer or there are no issues with their history, Decision (3) routes the flow directly to Task (5). Otherwise path (4) requests more contextual detail about the customer before also proceeding to task (5)
4. Task (5) asks if the agent requires more information to classify the type of complaint
5. If not, Decision (6) routes the flow directly to task (8). Otherwise path (7) presents an intermediate activity to request more clarification from the customer. 
6. Task (8) presents another Process Persisted (Dropdown) Field in which to classify and preserve the customer's complaint into one of :
   • • Wrong Order, Wrong Items, Missing Items, Poor Quality Order, Order Not Received, Complaint Rejected
7. Based on this classification the next Decision (9) can route the flow one of three ways :
   • For Order Not Received the agent is simply asked to select the "Handle Order Not Received" transition below; this completes the Triage activity with an activity outcome of "Order Not Received" (10)
   • For all other valid complaint types the agent is asked to select the "Gather Photographic Evidence" transition below; this completes the Triage activity with an activity outcome of "Order Received" (10)
   • But if the complaint was classified as rejected, task (12) asks the agent for further details supporting the rejection. Decision (13) ensures that these have been entered before the agent is asked to select the "Reject Complaint" transition below;  this completes the Triage activity with an activity outcome of "Reject Complaint" (14)

Task (1) : Order Number

Let us examine the first task (1), Order Number, in more detail. Double click on the shape to open its property panel

Clicking the Tasks Fields button in the property panel brings up a modal dialog where the task fields are defined 

1. The guidance field simply advises the agent how to fill out the Customer Order Number below
2. The Customer Order Number is a local task field that is tied to a Process Persisted Field that has been defined earlier against the entire workflow. See Defining Process Persisted Fields

When the agent enters a value for the Customer Order Number and submits the ticket, its value will be persisted so that it can be referenced from subsequent activities

In order to see how this referencing works, here is the original definition of the Process Persisted Field : 

1. The workflow diagram properties panel (1) for defining Process Persisted Fields
2. The first field is called Customer Order Number (3) and is of type Regular Expression (2)
3. The Regular Expression pattern (4) enforces values to conform to the required format

Process Persisted Fields vs Ticket Fields

Another way to persist data values across activities is to use task fields that reference Zendesk Ticket Fields. So how do you decide which to use? A good rule of thumb is as follows :

1. Use a ticket field if it is important to see that data in other parts of Zendesk, eg as a column in a Zendesk View or in Reports
2. Use a Process Persisted Field if the values just need to be preserved to drive the presentation or process logic in subsequent activities. Process Persisted Fields are quicker to define for this purpose  and avoid unnecessary proliferation of your global set of ticket fields

Task (2) : Context Assessment

Returning to the task flow diagram in Figure 2  let us now examine task (2) , Context Assessment, in more detail, paying particular attention to those of its task fields that will be used in the following decision (3)

Double click its activity shape as before and click the Edit button in the right property panel to see its Task Fields : 

1. A rich guidance field advising the agent to check the customer history.
2. A simple Yes/No task field asking if they have a history of making complaints
3. A field with three options to capture whether the history check highlighted any potential issues 

Now let us see how these values are used to drive the following decision

Decision (3)

Double click on the shape to open its property panel

 

Clicking the Decisions button in the property panel brings up a modal dialog where the two decisions are defined, Proceed and Add Detail

Click the Edit Condition button for "Proceed" to see how the condition is defined : 

So here the condition will satisfy if : 

The customer does not have a history of making complaints (1)  

                                        AND

There are no apparent correlating factors (2) 

Consequently the task flow in Figure 2 will take path (5)

Click the Edit Condition button for "Add detail" to see how the condition is defined : 

Here the condition will satisfy if : 

Both fields have been given values (1) & (2)

                            AND

Either the customer has a history of making complaints (3) OR there are correlating factors (4)

Consequently the task flow in Figure 2 will take path (4) to ask for more detail.

Decision Scope and Order

Note that decision conditions can use fields from any preceding task, not just the task immediately preceding the decision diamond.

Decision conditions are evaluated in the order of their definition until the first one is satisfied.

 

Activity Outcomes (3)

You are encouraged to examine the other task and decisions in Figure 2 but towards the end of the task flow you will see paths leading to three possible activity outcomes :

• Order Not Received (10)
• Order Received (11)
• Reject Complaint (14) 

And referring back to the top level workflow diagram in Figure 1 you will see that these control the three possible transitions paths leading out from the Triage activity (6), (4) & (3) respectively

 

Gather Photographic Evidence (Activity)

If Triage determines that an order has been received, the next step is to request photos to support the claim.

Click on the arrow icon   in the top left of the "Gather Photographic Evidence" activity shape to open its task flow diagram : 

The task flow consists of a series of tasks separated by decisions, similar to Triage.

Of particular note is

1. the Outcome Decision (1) 
2. the Reject Photo activity outcome (2) 
3. the four other remaining activity outcomes (3) 

As with a normal decision, double clicking on the outcome decision (1) allows us to edit its decision conditions via the Edit button in its property panel

The resulting dialog shows five decisions for each possible activity outcome.

Here is  the condition for the Reject Photo outcome (2)  : 

And here is the condition for Wrong Order, one of the other outcomes (3)

Note that both use Photo Rejected (P) whose value is determined in this activity (as explained below). But Wrong Order also uses the value of the Process Persisted Field, Complaint Type (P), which was set in the preceding activity Triage. This illustrates the power of Process Persisted Fields to influence decisions in activities further along in the workflow

 

Photo Rejected (P) (1) is a checkbox Process Persisted Field whose value is programmatically established in this activity by one of the tasks preceding the Outcome Decision; either Accepted or Rejected. 

Let us review the task fields for Rejected as an example : 

The Process Persisted Field, Photo Rejected (1) is a hidden task field whose checkbox value will be initialised to "Checked" (3) if the task flow takes a path through this task.

The Accepted task initialises it in exactly the same way, but with a value of "Unchecked" instead.

But the task flow can only pass through only one of Accepted or Rejected depending on earlier decisions; hence the value of Photo Rejected will either be "Checked" or "Unchecked" by the time the Outcome Decision is reached.

 

So in summary the Outcome Decision will either : 

1. Satisfy the Reject Photo outcome when photo rejected is checked
2. Or satisfy the appropriate outcome for onward handling of the complaint when the photo is accepted

 

Wrong Order (Activity)

This activity is one of a number of follow on activities designed to handle a particular category of complaint. Here is its task flow : 

 

It builds on its counterpart in the Delivery Handling (Basic) Template, in four ways :

1. The (persisted) Order Number is displayed for reference at the start of the activity via the Order Details task (1)
2. The task flow has an escalation route for problems with the external Order Processing System (4)
3. The activity is re-entrant and understands if it is being exercised for the first time (2) or control is being passed back from a previous escalation (3)
4. The activity now supports refunds to debit cards (not just credit cards). The payment type is entered in Identify Payment (5) and the following decision uses the value to route either to a Debit Card Refund (6) or Credit Card Refund (7)

The other follow on complaint handling activities :

• Wrong Items
• Missing Items
• Poor Quality Order
• Order Not Received

have all been extended in the same four ways, from their counterparts in the basic template.

 

Escalate (Activity)

The new escalation route out of the above activities is for help resolving any problems with the external order processing system.

Often an escalation route of this kind would benefit from reassigning the ticket to a new Zendesk group whose member agents may have greater privileges to progress the ticket.  Indeed, Flowset makes it possible to define automatic activity group assignments in workflows; but this template does not demonstrate this feature.

In this intermediate version of the Delivery Handling workflow. the Escalate activity is relatively simple. It assumes members of the escalation team have enhanced privileges and tools to be able to cancel the order, but does not attempt to deal with failure cases that might still arise.

Here is its task flow diagram : 

1. The first task (1) instructs the agent to cancel the order in the order system and record the success or failure in an (Yes/No) Process Persisted Field called Has the order been cancelled. As well as controlling the onward path here, the presence of this persisted value will later allow the re-entrant onward handling activities to know that control has been returned to them from Escalate
2. If the order is not cancelled, then path (2) is taken to ask the agent if this is because they wish to reject the complaint. It may be that something suspicious was found whilst analysing the order details
3. If the agent wishes to reject, then path (3) is taken to Add Rejection Details which the following decision ensures have been entered ....
4. .... before prompting the agent to finish the workflow with a Reject activity outcome (4) . In the top level workflow diagram the Reject  transition out of escalate includes the Rejection Details in its public transition comment to the customer.
5. Path (5) is taken if the agent could not cancel the order but the complaint was valid. Record Not Cancelled adds an internal comment explaining this failure before proceeding to task (7)
6. Similarly if task (1) cancels the order successfully , path (6) records this success as an internal comment before proceeding to (7)
7. Task (7) prompts the agent to select the correct transition to pass the ticket back to its original onward handling activity who will then offer the customer a refund. It uses the Process Persisted Field Complaint Type again to do this
8. Outcome Decision (8) also uses Complaint Type in its conditions to generate a set of outcomes for each potential return route back to its original activity. These outcomes are used to ensure only the correct return transition is available when the Escalate activity completes.

 

Other Rejection Routes

Lastly returning to Figure 1 we can see a couple of transitions out of Triage and Gather Photographic Evidence that deal with rejection cases.

These use a transition comment to add a standard response to the ticket politely informing the customer why there complaint is being rejected. 

Reject Complaint

So, for example, when the Reject Complaint and Finish Workflow transition is selected , a rejection comment is added to the ticket that includes the Reason For Rejection task field filled out during Triage. 

To see its definition : 

1. Select the transition line (1) in the diagram
2. Click the Transition Comment Edit button (2) in its properties panel   

   

Here is the body text of the comment including the task field reference (3) supplied during Triage  : 

 

Reject Photo

When the Reject Photo and Finish Workflow transition is selected after Gather Photographic Evidence, a fixed rejection comment is added to the ticket explaining that the complaint has been rejected because the photo evidence was insufficient. You can view the definition of this transition comment in the same way as above

 

Customization

The template provides a specific implementation of a delivery handing process.  Having created a workflow from this template, you are then free to customize it to better suit your needs.  Customization might consist of

1. Changing the pattern of the Customer Order Number regular expression field to enforce your organization's own order number format
2. Adding new activities to cover parts of your delivery handing process not covered by the template
3. Deleting activities that are not needed in your delivery handing process
4. Modifying the existing activities to gather more information or change the conditions to identify which task fields are mandatory to complete the task.
5. Adding task fields that are based on Zendesk Ticket fields.  This will enable selected task data to be recorded on the Zendesk Ticket and could be used for reporting purposes.

This is the intermediate delivery handling template. Flowset includes a  simpler "Basic" level template and a more complex "Advanced" level template for delivery handling.  It may be that your process is better matched by one of these other templates.

Delivery Handling Templates Summary

Name	Description	Features
Delivery Handling (Basic) Uses : Task Flows, Outcome Controlled Transitions, Transition Comments	A simple delivery handling process offering refunds to customers who have suffered a genuine unsatisfactory experience or rejecting with insufficient evidence. Offers guidance but no managed support for updating an external order processing system	✔︎ Ticket Triage ✔︎ Customer Communication ✔︎ Complaint Rejection ✔︎ Delivery Status Updates ✔︎ Credit Card Refunds  ✔︎ Coupons (sweeteners) ✘ Debit Card Refunds ✘ Simple Ticket Escalation  ✘ Advanced Ticket Escalation  ✘ Open Pending Lifecycles
Delivery Handling (Intermediate) Uses: Task Flows, Outcome Controlled Transitions, Transition Comments. Process Persisted Fields, Process Helper Fields	A richer process that offers an escalation path if problems are encountered interacting with the external order processing system. It also includes a richer dedicated common activity for analysing photographic evidence. For valid complaints it offers a choice of refund options for both credit and debit cards	✔︎ Ticket Triage ✔︎ Customer Communication ✔︎ Complaint Rejection ✔︎ Delivery Status Updates ✔︎ Credit Card Refunds  ✔︎ Coupons (sweeteners) ✔︎ Debit Card Refunds ✔︎ Simple Ticket Escalation  ✘ Advanced Ticket Escalation  ✘ Open Pending Lifecycles
Delivery Handling (Advanced)   Uses: Task Flows, Outcome Controlled Transitions, Transition Comments. Process Persisted Fields, Process Helper Fields, Activity Decomposition Diagrams, Reflexive Transitions,  Auto- transitions and Background Events using Open<>Pending Status Lifecycles	A sophisticated process that builds on the intermediate version but includes a significantly richer escalation activity whose task flow handles probable exception paths. It adopts fully managed customer conversations that automatically control Open<>Pending ticket lifecycle states.	✔︎ Ticket Triage ✔︎ Customer Communication ✔︎ Complaint Rejection ✔︎ Delivery Status Updates ✔︎ Credit Card Refunds  ✔︎ Coupons (sweeteners) ✔︎ Debit Card Refunds ✘ Simple Ticket Escalation  ✔︎ Advanced Ticket Escalation  ✔︎ Open Pending Lifecycles