Delivery Handling (Advanced)

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 customers 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 aspects of an advanced level Delivery Handling  process including :

• A Triage sub-process to record contextual customer data and classify complaints; it fully models a Zendesk ticket conversation to clarify the issue with the customer
• A dedicated sub-process to gather and analyse photographic evidence; it fully models a Zendesk ticket conversation to obtain the photographs from the customer
• 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 sophisticated escalation activity providing technical support for the order processing system; it models resolution paths for common types of issue.
• Alternative routes out of Triage and Escalation to reject invalid complaints as details become clearer
• A dedicated activity for handling complaint rejections of different types

Template Design

This template  builds on Delivery Handling (Intermediate)

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

This advanced workflow 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. 

[You can right click on the images in this document and open them in a new tab to zoom in. ]

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 (Advanced) template.

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

The activities (in green) show the main steps in the process. The first two activities are decomposed into sub-processes, as indicated by the green cross in the top left corner of their activity shape    :   

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

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

• Wrong Order
• Wrong Items
• Missing Items
• Poor Quality
• Order Not Received  (also decomposed)

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). The Escalate activity can transition to itself, as indicated by the reflexive "Retry" path (11)

There are also alternative ways to complete the workflow

• using rejection routes (3)
• using direct resolution routes (4), (for when the customer does not respond in a timely fashion)

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 template 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	Yes
Does this customer have a history of making complaints	Yes / No	Used in Triage when gathering contextual information about the customer	No
Correlating Factors	Drop Down	Used in Triage when gathering contextual information about the customer	No
Context Details	Text Area	Used in Triage when gathering contextual information about the customer	No
State	Drop Down	Hidden field used to record the latest ticket conversation state with the customer	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, Unclear	Yes
Rejection Reason	Drop Down	Set by earlier activities to indicate the reason for rejecting the complaint. Used by the Reject Complaint activity to generate the appropriate customer response	Yes
Issue Category	Drop Down	Used in Poor Quality to classify why the order is not acceptable. One of Damaged, Poor Quality or Performance, Defective, Not as Advertised, Incompatible, Other	No
Issue Category Details	Text Area	Used in Poor Quality to add supplementary reasons for the quality classification	No
Photographic Evidence	Text Area	Used in Photographic Evidence > Request Review Photo to record why the supplied photo evidence is unacceptable	No
Cancellation Status	Drop Down	Records the type of problem encountered with the external order processing system. One of Order Not Found, Order Cancellation Failed, Items Not Found, Item Cancellations Failed, Item Not Cancellable, Order System Unavailable, Order Cancelled	Yes
Cancellation Error Notes	Text Area	Supplementary information about the cancellation error that can help the Escalation team	No
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.	No
Rejection Argument	Text	Set to fixed phrases by tasks in the Escalate activity that are dealing with different possible rejection cases, like order not found. Used in the response sent to the customer by the Reject Complaint activity	No
Estimated Delivery Time	Date Time	When the order is due to arrive	No
Delivery Window (Business Days)	Integer	The amount of time allowed between placing the order and receiving the delivery	No
Delivery Status	Drop Down	The state of the delivery. One of Unknown, On schedule, Late	Yes
Retrying Escalation	Checkbox	Used to indicate when the Escalate activity has been re-entered from the Retry Escalation Steps transition	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 (Decomposed Activity)

This activity examines the customer's profile and categorises their complaint. It also manages a ticket conversation with the customer if more clarity is required. 

Click on the plus icon to open the decomposition diagram for the activity :

Figure 2

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

Assess and Categorise (1) contains a task flow to capture details about the customer and attempt to classify their complaint. It has various activity outcomes (4) that control onward transitions from Triage in the top level workflow diagram. Strictly speaking these outcome paths do not need to be drawn inside the decomposition diagram (they are inferred by the workflow) but, for clarity, it is good practice to draw paths to stop shapes named in accordance with the possible outcomes (as shown here)

The Triage activity in Delivery Handling (Intermediate) contained a task in which the agent was advised to have a side conversation with the customer if further clarity was needed to classify the complaint. The task flow did not manage this conversation in any way and the workflow was effectively paused on this task until clarity was obtained.

In this advanced version of the template this conversation is fully managed using a standard Zendesk open<>pending ticket lifecycle . If clarity is needed during Assess and Categorise (1), the task flow enables the Seek Clarity outcome. Transitioning to Await Customer Response (2) adds a public comment that is sent to the customer and then automatically sets the ticket status to Pending.  When the customer replies, Zendesk reopens the ticket. The Pending>Open automatic transition (3) returns to Assess and Categorise (1) where the new information can be used to re-attempt classification of the complaint.

Await Customer Response (2) is effectively a "holding" activity where nothing really needs to be done until a response is received. However if the customer doesn't respond within a reasonable amount of time the agent can manually select the Resolve Directly and Finish transition and submit. This will add a standard message stating the ticket will be solved due to a lack of response and complete the workflow.

Now let's look in a bit more detail at the task flow inside the first activity, Assess and Categorise (1)

 

Assess and Categorise (Activity)

Click on the arrow icon   in the top left of the 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

Let us describe the high level logic implemented by the task flow. We will not examine how the components of the tasks and decisions are defined using property panels; this has been explained already in Delivery Handling (Intermediate) but you are encouraged to examine the property panels for the following tasks and decisions by viewing the template itself in the Flowset Configurator

1. The first decision (1) determines whether an order number has already been entered. If it has it will have been stored in the Process Persisted Field Customer Order Number
2. If it has not, task (2) displays a simple guidance field that explains the format required.
3. Task (3) then presents an editable field in which to capture the Customer Order Number for the first time, or to edit its current value after a clarification response from the customer
4. Decision (4) has two conditions that make use of a Process Persisted Field called State
   1. Initial : satisfies when State is empty and indicates this activity is being encountered for the first time
   2. Clarification : satisfies when State is equal to a value of "Clarification" and indicates the activity is being run again after a clarification response from the customer
5. On the Initial run, the task flow follows path (5) and captures some contextual information about the customer's history.
6. On a Clarification run, the earlier contextual information is summarised in a guidance field and the agent is asked to review the customer's latest response
7. In either case task (7) asks the agent to categorise (or re-categorise) the complaint.
8. If there is sufficient clarity for a valid categorisation to be made, the activity will finish at outcome decision (8) where the outcome will either be Order Not Received or one of (Wrong Order, Wrong Items, Missing Items or Poor Quality)
9. If the complaint is being rejected, the activity will finish at outcome decision (11). Here the Rejected outcome will enable the Reject Complaint and Finish transition, (in the top level workflow), where a transition comment informs the customer of the Rejection Details, entered earlier
10. Finally if there is  insufficient clarity to categorise the complaint, the activity will finish at outcome decision (9). Here the Seek Clarity outcome enables the transition to Await Customer Response (see Figure 2) to allow an initial (or subsequent) conversation with customer. The Stop Shape (10) sets the persisted State field to Clarification to indicate that we are in a customer communication cycle. (see point 4. above)

 

Photographic Evidence (Decomposed Activity)

This activity analyses any photographic evidence the customer has provided to support their complaint. It also manages a ticket conversation with the customer to obtain a successful photo if one is initially not forthcoming,

Click on the plus icon to open the decomposition diagram for the activity :

Figure 3

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

Photo Required (1) contains a task flow to determine whether a photograph is needed. It has various activity outcomes (3) that control onward transitions from Photographic Evidence in the top level workflow diagram.  If a photo is not required, supporting arguments must be given, but then the workflow will typically follow the correct transition to one of the onward complaint handling activities, based on one of these outcomes.

If a photo is required then we stay within the decomposed activity and transition to Request / Review Photo. (2). Its task flow analyses any existing photograph that may have been provided, unsolicited, on the original ticket. If this photo is already acceptable, one of the various outcomes (3) will be enabled and then we can transition to its onward complaint handling activity. If not, we enter into a conversation with the customer to obtain an acceptable photo. (4). Here we adopt the same open pending ticket lifecycle pattern that we used during Triage.

If we need to ask the customer to send a photo then Request / Review Photo (2) enables the Await Photo outcome. Transitioning to Await Photo (4) adds a public comment that is sent to the customer and then automatically set the ticket status to Pending.  When the customer replies, Zendesk reopens the ticket. A Pending>Open background event fires which causes the workflow to transition automatically back to Request / Review Photo (1) where the new response and photo can be analysed. We could have used a pending>open automatic transition again like in Triage but a background effect here is equally effective.

Again Await Photo (4) is effectively a "holding" activity where nothing really needs to be done until a response is received. However if the customer doesn't respond within a reasonable amount of time the agent can manually select the Resolve Directly and Finish transition and submit. This will add a standard message stating the ticket will be solved due to a lack of response and complete the workflow.

Now let's look in a bit more detail at each of the activities

 

Photo Required (Activity)

Click on the arrow icon   in the top left of the 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)

1. The first task (1) determines the need for a photo using a Yes/No task field, Is there any reason why a photo is not required? 
2. If the answer is Yes, then decision (2) routes the flow to task (3)
3. Task (3) requires Supporting Arguments for the photo exemption
4. Decision (4) ensures that the Supporting Arguments have been supplied
5. Task (5) requires that an internal Photo Exemption Comment be added to the ticket detailing the Supporting Arguments. 
6. Decision (6) ensures that the Photo Exemption Comment has been added
7. Task (7) advises the agent to select the appropriate transition to the onward complaint handling activity
8. Outcome decision (8) ensures that the correct outcome is enabled for this transition (using the value inside the persisted process field Complaint Type)
9. Returning to decision (2) the flow is routed to task (9) if a photo is required and asks if one has already been supplied
10. If it has, and it is acceptable, decision (10) routes to task (7) again which finishes the activity with outcome decision (8) as above
11. Otherwise if no acceptable photo yet exists decision (10) routes to task (11) that asks the agent to select the transition to the next activity Request Photo and sets the Photo Required activity outcome
12. In this case stop shape (12) sets the Helper Process Persisted Field, State, to a value of PhotoNotRequested. (Here we are re-using the same Helper field that we used to manage the state of the customer conversation in Triage. ) But this time the value of PhotoNotRequested indicates that we are about to enter a conversation for the first time about photos

 

Request / Review Photo (Activity)

Click on the arrow icon   in the top left of the 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)

1. Decision (1)  uses the value of State to determine if we have asked for a photo yet. If the value is PhotoNotRequested (see point 12 for Photo Required activity above), then the decision routes to task (2). 
2. Task (2) requires that a public Request Photo Comment to be added to the ticket, asking the customer to supply a photo for the first time.
3. Decision (3) ensures that this comment has been added.
4. Task (4) asks the agent to select the transition to the next activity Await Photo and finishes the activity with the Photo Required activity outcome (5) to enable this transition. The stop shape for activity outcome (5) sets  the Helper Process Persisted Field, State, to a value of PhotoRequested to indicate that we have already asked the customer for a photo when we return to this activity.
5. Returning to decision (1), if the value of State is PhotoRequested we are returning to this activity after a response from the customer (see point 4 above) and the decision routes to task (6)
6. Task (6) uses a Yes/Not task field to ask Has the customer supplied a photo that adequately illustrates their complaint? 
7. If the answer is Yes, decision (7) routes to task (8) 
8. Task (8) advises the agent to select the appropriate transition to the onward complaint handling activity
9. And outcome decision (9) ensures that the correct outcome is enabled for this transition (using the value inside the persisted process field Complaint Type)
10. Returning to decision (7) if the photo evidence is still unclear, task (10) asks Would you like to ask the customer to send another photo?
11. If the answer is Yes decision (11) routes to task (12) 
12. Task (12) adds a slightly different public comment to the ticket explaining that their photo is inadequate and asking for another. Decision (3) ensures that either this comment (or the first comment from task (2) ) has been added, before the activity can proceed
13. Returning to decision (11), if the answer is No, we are going to reject the complaint and route to task (13). This tasks asks for details as to why the photo is not acceptable in a text area field called Photographic Evidence. A later activity (Reject Complaint) will include these details in the response sent to the customer.
14. Decision (14) ensures that the Photographic Evidence. has been filled out.
15. Then task (15) asks the agent to select the transition that leads to the Reject Complaint activity.  Outcome decision (9) enables the Rejected outcome for this transition when the value of No has been entered in task (6) for Has the customer supplied a photo that adequately illustrates their complaint? 
16. Finally stop shape (16) sets the Helper Process Persisted Field. Rejection Reason, to a value of Photo. This is used later in the Reject Complaint activity to govern which type of rejection response should be sent to the customer

Await Photo (Activity)

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

1. The task flow is very simple with a single task (1) advising the agent to :
   • wait for a customer response
   • or to select the Resolve Directly And Finish transition if no timely response if forthcoming (see outcome path (7) in Figure 3

but this activity also has a background event defined. Click its Background Events button {2} to see this :

1. If a pending-open event (1) occurs (because the customer has responded), the response outcome (2) will be set which will trigger an automatic transition from Await Photo back to Request / Review Photo. See transition (5) in Figure 3

 

Onward Complaint Handling Activities

Wrong Order, Wrong Items, Missing Items and Poor Quality are broadly similar and do not differ significantly from their behaviour in the Delivery Handling (Intermediate) template. See Wrong Order (Activity) as an example of the logic in their task flows 

Note that these are all re-entrant activities and have logic at their start to determine if they are being run for the first time or after control has been passed back to them from Escalate.

 

Order Not Received (Decomposed Activity)

The main logic of this activity does not differ greatly from the task flow for the same activity in Delivery Handling (Basic) . It determines the delivery status and takes different actions  if the status is : 

• still on schedule
• late 
• unknown

There are some significant structural differences and extensions from the basic version however.

1. Firstly it is a decomposed activity with dedicated sub-activities for handling the possible delivery status values above.
2. Secondly, like the other onward complaint handling activities, it is also re-entrant, but differs by having two possible escalation routes :
   • One for problems determining the delivery status at the start
   • One for problems cancelling the order later if a refund is being offered

Two process persisted variables are used to manage this slightly more complex re-entrant state of the activity; they are Delivery Status and Cancellation Status, explained below

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

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

1. The task flow inside Activity (1) first checks the value of the persisted field, Delivery Status. If it is undefined it knows that it is being called for the first time from Triage. (see transition (6) in the top level workflow diagram Figure 1) In this case it then asks the agent to check the external order system and set the value of Delivery Status to one of  : "On Schedule", "Late" or "Unknown"
2. If the Delivery Status is "On Schedule" activity (1) sets the On Schedule outcome; this enables the transition to the On Schedule handling activity (2) where details about expected delivery times are entered and a response is sent to the customer. Once done the activity sets the Resolved outcome (8) which allows the agent to transition and finish the workflow
3. If the Delivery Status is "Late" activity (1) sets the Late outcome; this enables the transition to the Late handling activity (3). Earlier versions would immediately offer a refund here, but in this advanced version, activity (3) first adds a public comment to the ticket asking if they are willing to wait a little longer. The agent then transitions to activity (4) where they wait for a response whilst the ticket is placed into pending.
4. Activity (4) defines a pending-open background event that sets the response outcome. This fires when the customer has responded and the workflow transitions automatically to activity (6)
5. Alternatively if the customer does not respond within a reasonable time period the agent can select the transition to Resolve Directly (5)
6. After the auto transition to activity (6) the agent is asked to read the response; if the customer is happy to wait, a "thank you" comment is added to the ticket. It then sets the Resolved outcome (8) which allows the agent to transition and finish the workflow.
7. If the customer is not willing to wait activity (6) enables the Cannot Wait outcome so that the agent can transition to activity (7) and issue a refund. If all goes well, details of the refund are added to a public comment for the customer and the Resolved outcome (8) is set allowing the agent to transition and finish the workflow
8. The Resolved stop shape (8) is not strictly required for the decomposition diagram, but is helpful in highlighting the Resolved outcomes from the earlier sub-activities
9. If a problem is encountered cancelling the order, activity (7) sets the Escalate outcome (9) which allows the agent to transition to the Escalate activity in the top level workflow (see activity (10) in Figure 1). The Escalation team resolves the problem and sets the Cancellation Status field. On return from escalation, activity (1) sees that Cancellation Status and sets the Order Cancelled outcome; this allows the agent to transition back immediately to activity (7) and continue offering the refund.
10. Similarly, activity (1) enables the Escalate outcome (10) if a problem forces the agent to set the Delivery Status to "Unknown". This allows the agent to transition to the Escalate activity so they can help determine the true status of the delivery and set the Delivery Status on their behalf. On return from escalation, activity (1) sees that Delivery Status is now either "On Schedule" or "Late" and sets the appropriate outcome to transition to activity (2) or (3) respectively.
11. The Escalate stop shape (11) is not required for the decomposition diagram, but is helpful in highlighting the possible Escalate outcomes (9) & (10) from the earlier sub-activities

 

Escalate (Activity)

There is an escalation route out of the above complaint handling activities to help resolve any problems with the external order processing system.

Often an escalation route of this kind benefits 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. Instead guidance messages before and after escalation advise assigning the ticket manually to the appropriate group.

In the 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 many of the failure cases that might still arise.

In the advanced version the task flow has been expanded significantly to anticipate likely failure conditions and provide guidance for each one.

The activity is re-entrant because it can repeat itself during a retry operation, (see the reflexive Retry transition (11) in the top level workflow diagram Figure 1)

Here is task flow diagram for the Escalate activity. 

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

For brevity we will just highlight the main paths through the flow, referring to blocks of related tasks 

1. The first block (1) gathers and displays some persisted field values that were filled out by prior activities, eg Customer Order Number as well as Cancellation Status & Cancellation Error Notes; these last two fields hold descriptions of the problems encountered whilst using the order processing system. An internal comment is added to the ticket recording that it has been escalated.
2. Decision (2) is key in determining the correct path through the Escalate activity to handle the specific use case. It's conditions are based on the value of Cancellation Status eg :
   • Order Not Found, Order Cancellation Failed, Items Not Found, Item Cancellations Failed, Item Not Cancellable, Order System Unavailable
3. Block (3) handles when the order system was unavailable, eg it was offline, or had crashed. It instructs the agent to wait for the system to come back on line and then cancel the order as an administrator. It then : 
   • sets the Cancellation Status to "Order Cancelled"
   • adds an internal comment explaining that the order has been cancelled
   • and returns control back to the original handling activity via blocks (11) and (12)
4. Although not all on the same path, block (4) highlights the need for preliminary tasks that instruct the agent to check the system logs for evidence of say an order being placed or items being included in the order, before then proceeding to handle a particular use case. 
5. Block (5) handles the case when the order could not be found in the order processing system but the logs showed evidence that an order was indeed placed. An internal comment is added explaining that evidence of an order was found and instructs the Tier1 agent to issue a customer refund. No further action is needed except to return the ticket to the original complaint handling activity via (11) and (12)
6. Block (6) is taken if the Tier 1 level agent received an error trying to cancel the order. The administrator tries to cancel the order again using admin privileges. If this succeeds the admin sets the Cancellation Status  to "Order Cancelled" and an internal comment is added informing the Tier1 agent that the order has been cancelled on their behalf. If the administrator cannot cancel the order because the order system is now offline, they are instructed to wait for it to come back online and then select the Retry transition which runs the Escalate activity again. The original path is followed again but this time, with system back online, the order can be cancelled successfully and control returns to the Tier 1 agent via blocks (11) and (12)
7. Block (7) handles when there is no evidence in the logs of an order or items being placed as claimed by the customer. In this case an internal comment is added explaining this and setting Rejection Argument to the precise details. The activity completes with a Rejected outcome and the stop shape sets the Rejection Reason helper field to "Order Description". The escalation agent can then transition to the Reject Complaint activity which uses Rejection Reason and Rejection Argument to add an appropriate rejection response for the customer.
8. Block (8) is very similar to block (5) but handles the case of order items that could not be found , but for which evidence was found against the original order in the system logs.
9. Block (9) handles the case for non cancellable items, eg small ticket items that are supposed to be included with the order but do not arrive. An internal comment is added advising that a small refund and coupon should be given for the inconvenience. Then control is passed back to the Tier 1 agent via blocks (11) and (12)
10. Block (10) handles the case when the Tier 1 agent could not find the delivery status for the order. The subsequent tasks ask the escalation agent to find this information instead and fill out the process persisted fields that are normally completed by the Tier 1 agent;  i.e. Delivery Status, Estimated Delivery Date & Time and Delivery Window (Business Days). An internal comment is then added with these values. It recommends a refund only if the Delivery Status is "Late" or still "Unknown". Control is then passed back to the Tier 1 agent via blocks (11) and (12)
11. Block (11) is common to all use cases apart from rejection or a retry. It advises the escalation agent to assign the ticket back to the Tier 1 group  and then select the appropriate transition to pass control back to the original onward complaint handling activity.
12. Block (12) contains the different outcomes for forwarding back to the original onward complaint handling activity. The outcome decision uses the original Complaint Type in its conditions to enable the appropriate outcome. This ensures that only the one correct transition is available for selection

 

Rejection Routes

Returning to Figure 1 we can see an explicit rejection path (3) out of Triage. This uses a transition comment to add a standard response to the ticket politely informing the customer why there complaint is being rejected. The comment includes Rejection Details filled out during the Triage activity. This same approach is  used by the intermediate level Delivery Handling Template and is explained in more detail here

As we advance through the activities in the advanced workflow other possible rejection paths become possible. Rather than have multiple rejection paths to stop shapes for each one, these other rejection paths (3) route to a dedicated activity called Reject Complaint. This interprets the values of a 
Process Persisted field, Rejection Reason, set by earlier activities to determine the appropriate rejection response comment to send to the customer.

 

Reject Complaint (Activity)

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

1. The first task (1) displays the Customer Order Number and Rejection Reason for reference (as read-only fields).
2. If the Rejection Reason is "Photo", decision (2) routes the flow to task (3). A Rejection Reason of "Photo" is set as a helper field on the stop shape of the Photographic Evidence > Request / Review Photo activity when its task flow enables the Rejected outcome
3. Activity (3) adds a public comment explaining to the customer that their complaint is being rejected due to insufficient photographic evidence. The comment adds specific details by including the value of the Photographic Evidence process persisted field. This process persisted field is completed during the Evidence Unclear task inside Photographic Evidence > Request / Review Photo
4. If, instead, the Rejection Reason is "QualityClassification", decision (2) routes the flow to task (4). A Rejection Reason of "QualityClassification" is set as a helper field on the stop shape of the Poor Quality activity when its task flow enables the Rejected outcome. Activity (4) adds a public comment explaining to the customer that there complaint of poor quality is being rejected. The comment adds specific details by including the values of the Issue Category & Issue Category Details. These process persisted fields are completed during the Categorise Problem task inside Poor Quality.
5. If instead, the Rejection Reason is "OrderDescription", decision (3) routes the flow to task (5). A Rejection Reason of "OrderDescription" is set as a helper field on the stop shape of the Escalate activity when its task flow enables the Rejected outcome. Activity (5) adds a public comment explaining to the customer why their complaint is being rejected. The comment includes specific details by including the value of the Rejection Argument. This process persisted field is completed during either the No Evidence of Items task or No Evidence of Order task inside Escalate.
6. Decision (6) ensures that a rejection response comment has been added to the ticket by one of the mutually exclusive paths above

7. Task (7) asks the agent to select the Reject and Finish Workflow transition and submit the ticket.

   This sends the rejection response to the customer and solve the ticket.

As an example of one of the comment definitions, here is the property panel for task (3) : 

The body of the comment task field (1) includes :

• the Customer Order Number for reference (2)
• and the persisted process field, Photographic Evidence (3) detailing why the photo was inadequate.

 

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 advanced delivery handling template. Flowset also includes a simpler "Basic" level template and an "Intermediate" 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