Building high performance into your Customer Service applications
|Request to Publish|
|Version as of|
↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓ Please Read Below ↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓
Enter your content below. Use the basic wiki template that is provided to organize your content. After making your edits, add a summary comment that briefly describes your work, and then click "SAVE". To edit your content later, select the page from your "Watchlist" summary. If you can not find your article, search the design pattern title.
When your content is ready for publishing, next to the "Request to Publish" field above, type "Yes". A Curator then reviews and publishes the content, which might take up to 48 hours.
↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓ The above text will be removed prior to being published ↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓
Building High performance customer service applications
When building your implementation of customer service on either customer service horizontal or different verticals such as customer service for financial services their are a number of key design decisions
that will help ensure a high performance implementation. The remainder of this article will break these problems into key areas and provide tips and pointers on each.
Workpools and tables
Depending on the version of customer service you are implementing you may have anywhere from 2 to 4 work pools out of the box. When setting up your implementation ensure that you have at minimum one work pool for the interaction classes and one work pool for the service intent cases pointed to 2 different tables.
- By default ootb both service case and interaction work pools point to the same table which for small implementations will work but for larger implementations a single table becomes a bottleneck.
- For extremely high volume implementations think of creating work pools that mirror your core entities or interaction driver categories such that load is spread across more tables. The more tables present the lower IO contention is at high volume.
- Example: BigBank-Servicing-Work-Acct ( work pool for account related case )
- BigBank-Servicing-Work-Gen ( work pool for general related cases )
BigBank-Servicing-Work-Interaction ( work pool for customer interactions )
- For report definitions and dashboards that don't have to be instantly up to date consider using a reporting data source instead of the primary data source. If on pega cloud usage of read replicas may also come into play.
How the user experience and in turn the UI is designed and built can have a large impact on performance both actual and perceived. Determining what is needed when is extremely import in a customer service implementation where anywhere from 6-30 interfaces may get invoked as part of running and loading the interaction and 360 customer composite.
- Don't display something until you actually need it. An example methodology to help determine usage and data placement can be found at Customer Service methodology for agent interaction and Customer composite data placement.
- For example when searching for a customer you only need enough information to select the customer not verify them at that point in time. Wait until verification to pull in the additional required information.
- Ensure sections are collapsed and defer loaded if possible.
- When showing a list of items set a reasonable page size usually < 15 to display at once and enable progressive loading
Clipboard and data pages
A clean clipboard on agent requestors, reasonable overall requestor clipboard size and efficient and correct load strategies on data pages can mean the difference from being an unstable customer service application that is constantly plagued by complaints of slow response over time to one that has the same performance and response profile for an agent throughout their shift be it 6,8 or more hours continuous and scales with far more users per node.
- Make data pages request level if possible to avoid constant reload. System of record data, data used across cases and data shared across interactions and service intents are all good candidates to be requestor level.
- Do not use the reload once per interaction option. This will actually reload the data page every http interaction vs. what some may think is the customer service interaction. For example if a screen has 4 sections that are defer loaded all of which are rendered the same data page. Each defer load is a different http interaction and thus the data page will be reloaded 4 times. If you need a fine grained reload strategy consider using the reload if older than or the do not reload when but forcing the condition to evaluate true.
- Always select "clear pages after non-use" when this an option ( on read only requestor level data pages )
- Ensure data pages are being cleared out appropriately.
- Upon wrap up of an interaction customer service will invoke activity CPMPreClose which contains two different methods of removing requestor level data pages being CPMRemoveRequestorDataPages which loops through D_Interaction_RequestorDataPages and removed them explicitly by signature or in data transform CPMCleanInteractionPages. Unless you have touched a page from the portal thread which does not get removed when an interaction is closed or you did not check the clear pages after non-use on your requestor level data pages you will need to add your implementation build data pages to CPMCleanInteractionPagesExtension. Also note that if you have changed the parameter signature of any of the OOTB data pages you may also have to add this update into the extension.
- Periodically during the development and QA cycle check that all data pages are getting cleared upon wrap of of interactions and service cases.
Use case examples
Provide a business example to help users understand the objective.
Before you begin
Is it necessary to plan anything in advance, or are external steps using other tools required to achieve the goal? If any specific configuration procedures (how-tos) exist on Pega Community pages, you can link to those assets here by providing the URL.
Process/Steps to achieve objective
What do individuals need to know to achieve the outcome? What do individuals need to know to achieve the outcome? Enter the precise steps to guide the user to achieving the desired outcome. Remember to always state where in the software the user must perform an action, before giving the action.
If “How To…” documents exist for specific configuration procedures please link (using the url) to those assets on the community **
What do you expect the user to see or be able to do after they complete this design pattern?