Service Request Action Plans

This post profiles Oracle B2B Service Cloud’s Action Plan functionality. Customer service agents can use Action plans to quickly generate a set of activities that must be performed to resolve a Service Request (SR). Action plans are particularly useful if the support agent needs help from other resources, or if many actions are required to resolve the SR. If actions plans are not a fit for your organization, they can be removed from the UI to streamline your application. Now let’s take a look at how Action Plans work.

The end-to-end action plan flow follows these seven steps:

1. Administrator defines actions and assembles into action plan templates.
2. During initial SR review, the assigned agent determines an action plan is required to resolve customer issue.
3. Agent selects appropriate plan template, makes any needed adjustments, and then initiates the plan.
4. Oracle generates tasks, appointments, and additional SRs populating attributes per the action plans’ mapping rules. Oracle also projects a completion date and time based on the template durations and work calendar.
5. As related action objects are completed by the owner, the action plan statuses and completion dates are updated. Any dependent actions are then activated until the plan is completed and the SR can be resolved.
6. Throughout the process, the agent can monitor the action plan, make necessary updates to plan dates, follow-up on late actions, and keep customers apprised of progress from the SR page.
7. Managers can view summary reports across SRs to understand action plan metrics and trends, such as number of past due actions and total time past due by agent.

The following cross-functional process diagram illustrates the same flow with a bit more detail. Fully automated steps are shown in green.

Now that we have general understanding of the action plan flow, let’s take a closer look at how Action Plans are used by agents to facilitate effective resolution of customer issues.

Using Action Plans

The first step is to apply an action plan to the service request. This is done manually, generally by the SR’s assigned agent during the initial service request review and diagnosis. Note that for simple one-call resolution SRs, an action plan normally wouldn’t apply. To add an action plan, the agent selects Add Action Plans from the Actions menu.

This launches the Action Plan Template window where the agent can browse and add the appropriate template. In this example, the agent is adding the Product Replacement template because the customer’s product had a warranty failure and needs to be replaced.

Once the template is applied to the SR, the agent starts the plan which will set actions in motion.

By clicking on the Action Plan Number link, the agent can view individual action details. Here we can see that the first action, a task assigned to the account manager to review issue and product replacement plan, has been created and is in progress.

The agent can also make some adjustments to actions not started. Let’s say that the final action for Operations to build a custom replacement is not required since the current product is kept in stock; the agent then clicks the Skip option to exclude that step from the plan.

You’ll notice that steps #2 and #3 are not started. This is because they have been defined with step #1 as a prerequisite.

Next, we’ll jump over to look at the action object from the owner-assignee perspective. Typically, we’d create a notification that is triggered when a new task is assigned. In this case, the task is assigned to the customer account owner, Willa. She opens the task in Sales Cloud and sees information that is automatically populated from the service request and action plan based on configurable mapping rules (for this example: Description, Account, Type, Subject). The task also references the source Service Request which allows the user to drill into the SR to view additional details if needed. To approve, the account manager simply marks the task Complete.

Once the task is completed, Oracle automatically updates the action plan step #1 to Completed and activates steps #2 and #3 since these have been configured to run in parallel.

The plan on the SR will now show as:

Note that the Projected Completion Date is automatically recalculated based on the previous steps’ actual completion times and remaining action durations.

At any time, the agent can view the action plan in Diagram View mode which can be useful for plans with a mix of prerequisites and parallel steps. Here we see the above plan with step #1 completed (green) and steps #2 and #3 currently active and scheduled in parallel:

If any actions are still in progress after their expected completion date, they will be flagged so the agent knows that follow-up is required.

The agent can also manually adjust the end date to provide more time if needed. These adjustments will then be reflected in the Projected Completion Date. Once all actions are completed the Actual Completion Date is recorded and the Plan status is updated to Completed.

The service request remains open because completed action plans don’t necessarily mean the issue is resolved (if the plan covered troubleshooting instead of remediation, for instance). In our scenario, the SR is now resolved, so the agent would finally perform the Resolve action to complete the SR.

Limitations and Workarounds

What happens if the account manager didn’t want to send an advance replacement in step 1 but instead wanted to wait for return product receipt?  Here’s where we run into some limitations of Action Plans. First, they do not support conditional branching. So we can’t automatically skip actions based on previous step outcomes. We also can’t manually skip a step once it’s been started. And while the agent could open the Order advance replacement task and cancel it, the task cancel status can only map-back to a Completed action status (which isn’t accurately reflecting what happened on this SR).  

One workaround is to add an agent “review and skip” action before current steps #2 and #3. Another option is to split this plan template into separate templates:

• Account Manager Review & Advise template: single task action
• Product Return and Replace template: with the replacement task to be dependent on the return task
• Advance Replacement template: with both return and replace tasks to run in parallel

Then the agent would apply the appropriate product replacement template after the first Account Manager Review action plan is completed. 

As you can see, up-front design and testing efforts are important to defining action plans that are straightforward to use while handling the varied support scenarios.

Reporting on Action Plans

B2B Service Cloud does not ship with out-of-the-box reports for Action Plans, but it does include a BI subject area that will support most reporting requirements. Here’s an example of a custom report showing current Actions that are past due by owner.

Reports like this are straightforward to build and can be embedded in the Service application or linked to the Service Infolets homepage as detail reports. providing managers easy access to real time performance metrics.

That pretty much wraps up B2B Service Cloud ‘s Action Plan functionality as of Release 20D. If you have any questions about Action Plans, or whether Oracle Service Cloud might be a good fit for your support organization, give me a call or send me an email.