Executive Summary

Checkout.com’s support communication with existing merchants was primarily through the use of online forms and email. This gave the merchants a somewhat disjointed experience when compared to the rest of the platform they used with Checkout and limited visibility for existing requests and no real way to control the various levels of access their own employees would have to both view and create new merchant change requests.

Checkout.com came to us with a project to create a new Salesforce Community for their merchants to log into and access, remedying the issues outlined above whilst also integrating seamlessly with the existing work and case management we had done for them on the backend solution in Salesforce for Checkout’s own support staff.

Our Approach

 The main requirements for Phase 1 of the project were:

• Allow merchant contacts to view existing cases (merchant change requests) across one or more of their associated accounts

  • Both tracking the process of the case and updating said case via comments (Chatter) and uploading new files

• Submit new merchant change requests for the change of the account authorised signatory.

• Have some control of User access, being able to:

  • Give access to the new portal to contacts on the same accounts/s

  • Viewing the list of contacts on the account/s in the community

  • Controlling the level of access the related contacts have, being able to disable contacts access or downgrading the level of access

After getting the initial high-level requirements above, we set about solutionizing the various web pages, LWC components and other community setup changes needed and created the majority of Jira tickets needed to be worked on the project.

After the initial creation and setup of the community, we created “white-label” components for the various functionality needed across the new community portal, whilst we waited on designs for both the wider theme across the site and designs for the individual pages.

This enabled us to get started immediately and implement a majority of the community site logic. This was beneficial in a few ways including giving us plenty of time to work in an agile way before the deadline to fine-tune the work we had done to provide the best possible experience for the end user whilst also making sure the end users only had the exact amount of accessibility to sensitive data they would require. 

Furthermore we were able to collaborate with Checkout’s internal design team on the site easily, giving them access to the white label components created so they could share designs and we could then implement them quickly and efficiently.

Alongside the main community site we also created new Flows and Email templates in Salesforce for the merchant users to stay updated with any changes/comments made on the change requests. On top of this, we also modified the existing standard Salesforce emails for adding new users and password resets to apply our own Checkout branding, to maintain consistency for the users experience.

Outcomes

Once the new community site was in a near complete state, we demonstrated the portal to Checkout and received positive feedback on the work completed. Off the back of that Checkout decided to look into expanding the initial scope and functionality of the Merchant community portal before a general release, and we moved onto working on a new, higher priority portal for a new set of Checkout customers (Partners).