Delivery Handling (Basic)

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 basic aspects of a Delivery Handling  process including :

• A simple Triage process to classify complaints
• A set of follow on activities designed to handle a specific classification of complaint including offering standard refunds to customers
• Alternative routes out of Triage to reject invalid complaints

Template Design

The delivery handling template consists of a number of activities.  Each activity represent 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

Figure 1 shows the top level workflow diagram for the Delivery Handling (Basic) template.  The activities (in green) show the main steps in the process. These are :

• Triage

followed by one of

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

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

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

You will in Figure 1 see that the workflow defines a follow-on activity designed to handle each of these complaint types. 

There are also alternative ways in which to complete the workflow, including rejection cases. These are represented by paths to different stop shapes,

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

Detailed Design

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

 

Triage

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 : 

 

 

(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 or activity outcomes 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, often with an associated 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) asks the user to classify the customer's complaint into one of :
   • • Wrong Order, Wrong Items, Missing Items, Poor Quality Order, Order Not Received, Complaint Rejected
2. Based on this classification the next decision diamond can route the flow via path (2) to Analyse Photographic Evidence  but only for valid orders that have been received.
3. Path (3) is taken if the photographic evidence is insufficient to support the claim....
4. ... and path (3) ends the activity with an outcome (4) called Reject Photo.
5. Path (5) is taken if the photographic evidence supports the claim which will lead on to path (7)
6. Path (6), for orders not received, bypasses photographic evidence and leads straight to path (7)
7. Path (7) leads to an outcome decision diamond for all valid complaint types.
8. The possible activity outcomes for valid complaints are shown by the named paths leading to the different stop shapes (8). The outcomes control which onward activity (in Figure 1) should be used to handle the specific type of complaint. (In this task flow all the outcomes are mutually exclusive but multiple simultaneous outcomes are also valid)
9. Finally if task (1) immediately categorises the issue as Complaint Rejected, then the next decision routes the flow along path (9); here the agent is first prompted to enter a Reason for Rejection before being asked to select the Reject Complaint and Finish Workflow. The Reason for Rejection will be included in the final transition comment that is sent to the customer (as explained later in Other Rejection Routes)

Tasks

Let us examine the first task (1) - Categorise Complaint, 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 read only Rich Guidance fields offer advice to help the agent to complete the task.
2. The Complaint Type field prompts the agent to specify the type of complaint

Decisions

Now let us examine the decision immediately following the Categorize Complaint task. 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 conditions are defined : 

And clicking say the first button brings up a further modal in which to define the condition for the "Order Not Received" decision : 

So in this simple example the Order Not Received decision uses a single condition specifying that the Complaint Type field, in the previous task, has been given a value of "Order Not Received".

We encourage you to examine the other conditions; for example Order Received is a little more complicated and uses multiple ALL conditions.

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

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

Outcome Decisions

Path (7) leads to an Outcome Decision. Double click on the shape to open its property panel

Conditions for Outcome Decision are defined in exactly the same way as "normal" Decisions (explained above). The main differences for Outcome Decisions are that :

1. for each condition that is satisfied its outcome name is enabled against the completed activity
2. all the conditions are evaluated so that multiple outcomes for the activity can be achieved simultaneously

The five outcome conditions in this example are very simple and just check that the Complaint Type entered earlier matches a particular value corresponding to its outcome name. So in this case there will only ever be one outcome satisfied.

eg for "Wrong Order" the outcome condition is : 

 

Wrong Order

Returning to the top level workflow diagram see Figure 1 we see that, once Triage is complete, the workflow can transition to a number of different onward complaint handling activities based on the satisfied outcome.

Let us imagine that the complaint was classified as a wrong order during Triage and examine the onward Wrong Order handling activity in more detail

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

 

The task flow consists of three tasks separated by decisions. The decisions ensure that mandatory fields have been filled out in the preceding task before the next task is presented

1. Task (1) presents a simple checkbox to tick once the order has been cancelled in the order processing system
2. Decision (2) ensures the checkbox task field has been ticked in the preceding Cancel Order Task before presenting the next task
3. Task (3) presents guidance fields on what monetary rewards to offer the customer and captures amounts for a refund value and coupon value in "currency type" task fields.
4. Decision (4) ensures that values have been entered into both the refund and coupon fields before presenting the next task
5. Task (5) uses a comment task field to add a standard public comment to the ticket (similar to a macro) which includes the monetary refund and coupon values entered earlier.
6. Outcome Decision (6) ensures that the public comment has been added in Task (5) before the activity can complete. (The "Response Added" outcome itself is not used anywhere else)

Now let us examine (3), (4) and (5) in a little more detail

Task 3 - Identify Repayment 

 

The task field dialog for the Identify Repayment looks like this : 

1. Field (1) offers general guidance as to which fields need to be completed below
2. Field (2) offers specific guidance for completing the Refund field
3. Field (3) captures the Refund amount in pounds Sterling
4. Field (4) offers specific guidance for completing the Coupon field
5. Field (5) captures the Coupon amount in pounds Sterling

Decision 4

The edit dialog defines one decision called "Fields Completed" : 

and it condition looks like this : 

The "Present" operator ensures that both currency fields must have been given some value before the next task is presented

Task 5 - Credit Card Refund

The task field dialog for the Credit Card Refund looks like this : 

• Field (1) offers guidance to add a comment, using the field below, before finishing the workflow.
• Field (2) is called "Refund Message" and adds a public comment (3) to the ticket.
• The body of the comment includes references to the Refund Amount (4) and Coupon Amount (5) entered earlier in Task 3 - "Identify Repayment"

Outcome Decision 6

This simply ensures that the above public comment has been added to the ticket before the activity can complete. The condition for the "Response Added" outcome is simply : 

Wrong Items

The onward activity for handling Wrong Items is similar to Wrong Order. Here is its task flow :

The main differences are

1. A checkbox instruction in Cancel Items (1) to cancel just the missing items not the entire order.
2. Guidance regarding entering the refund value in Identify Repayment (2) (which states this should be just for the missing items)
3. A slight change to the wording of the public comment in Credit Card Refund (3) (again reflecting missing items rather than a wrong order)

Missing Items

Again the onward activity for handling Missing Items is almost identical to Wrong Items. Here is its task flow :

The only real difference is :

1. the wording of the public comment in Credit Card Refund (1) (reflecting "incorrect" rather than "missing" items)

Poor Quality

The onward activity for handling Poor Quality is also similar when handling valid complaints but includes an alternative path to reject the complaint if the claim of Poor Quality is unjustified. Here is its task flow : 

1. Task (1) - Analyse Complaint presents a simple Yes/No field asking if the complaint should be rejected because the arguments for poor quality are not valid.
2. If the answer is No, then the following decision takes path (2) to cancel the order and offer a standard refund in the same way as Wrong Order, Wrong Items and Missing Items
3. If the answer is Yes the decision routes the flow to path (3) and the Reject Complaint task adds a standard public comment to the ticket to inform the customer why their complaint is being rejected.
4. Outcome decision (4) uses ANY conditions to test that a response comment has been added to the ticket from either route

Note in this activity we could have created two separate outcomes for valid and invalid complaints and introduced another "rejection" transition on the parent workflow diagram. Then we could have added the appropriate response comment to each finish transition. But allowing the logic of the task flow to offer an alternative comment field for each path in the activity itself, neatly allows us to avoid this and use just a single outcome and higher level finish transition.

 

Order Not Received

Like the earlier activities this also includes tasks to offer a refund if the delivery is late but also includes earlier tasks to establish the status of the delivery which might still be on schedule. Here is it's task flow : 

1. Task (1) Examine Delivery Status, asks the agent to examine the order system to determine the order status and record a result of Unknown, On Schedule or Late in a dropdown task field
2. If the status is unknown we trust the customer's claim and take path (2) to offer them a standard refund.
3. If the order status is "known" the decision routes the flow to path (3) where a task captures the Estimated Delivery Date & Time (used later in the response to the customer)
4. A following decision then routes to path (4) if the delivery is late and offers the customer a standard refund.
5. If the delivery is still on schedule the decision routes to path (5) where the subsequent task and  decision ensure that Delivery Window information is recorded.
6. The On Schedule Response task asks the agent to add a public comment explaining the delivery is still on its way and includes the information gathered in the earlier task fields for reference :
7. Lastly the Outcome Decision (6) defines a pair of ANY conditions to ensure that a public comment has been added to the ticket :
   • either the On Schedule Response above,
   • or the standard refund response from following paths (2) or (4)

 

Other Rejection Routes

Lastly returning to Figure 1 we can see a couple of transitions out of Triage 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) : 

 

Reject Photo

When the Reject Photo and Finish Workflow transition is selected a fixed rejection comment is added to the ticket explaining that the complaint has been rejected due to lack of photographic evidence. 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. Adding new activities to cover parts of your delivery handing process not covered by the template
2. Deleting activities that are not needed in your delivery handing process
3. Modifying the existing activities to gather more information or change the conditions to identify which task fields are mandatory to complete the task.
4. 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 basic delivery handling template. Flowset includes other more complex templates for delivery handling.  It may be that your process is better matched by one of these more complex 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