Research

What?

Salesforce is a cloud computing company based in San Francisco, California. Its main product is an enterprise solution that allows businesses to manage relationships with their customers, in a user-friendly, customizable platform. In 2018, Salesforce dominated the worldwide CRM market with a 19.5% market share which is more than double its nearest rival, SAP, at 8.3% share. 

Why?

Creating a payment integration into Salesforce was placed on the roadmap for two main reasons: 
  1. Because of the popularity of Salesforce as a CRM platform businesses use to conduct numerous workflows crucial to running their organization 
  2. Due to the needs of various job roles like sales people and customer service reps, to take payments and gather payment method details from customers, for a variety of reasons including taking payment for services, charging deposits before goods are shipped, and running pre-authorizations to check funds are available before custom items are manufactured.

How?

My team and I set out to identify the specific use cases for companies wanting to take payments inside their Salesforce CRM instead of within their ERP or accounting software. We were aware of reasons why companies can benefit from taking payments inside their CRM from previous payment integrations of ours, but I felt it was important for my team and I to start from the beginning and allow research focused on Salesforce users specifically to guide our product mapping. 

Users & Use Cases

Our research found that the use cases for companies wanting to take payments inside their Salesforce CRM instead of within their ERP or accounting software are just as varied as the wide range of industries and company types that Salesforce itself is used by.

We worked with a Salesforce implementation expert and actual Salesforce users to define potential user types and use cases. These drove discussions on what features to include, where to integrate within Salesforce, and how to design within Salesforce lightning components to create useful and impactful functionality.
Examples of potential use cases
A sales or customer service representative taking a payment for a customer, helping a customer with a new or previous order, up-selling, or charging for a part, a repair, or some other kind of service or product. ​
A customer calling in to pay a bill (utility, phone, internet, cable, etc)
Field sales/service individuals needing to take payment or save card data using the Salesforce mobile app or cloud application at a kiosk, trade show, customer location, or some other location away from the office for services or items

Defining the Integration

We decided to divide our offering into two pillars: a native component that can be placed on any object in Salesforce (to accommodate the varying workflows of Salesforce users), and an EBizCharge app that houses additional payment functionality for automating and streamlining payment processing and collection. 
We studied Saleforce's Lightning design system and utilized their robust documentation to design our first prototype. 

EBizCharge Component

The EBizCharge component allows users to take payment on any object in Salesforce, whether on an account, an opportunity, a contract, or an order. 

Directly from any Salesforce page, users can:
  • Take payments over the phone for accounts
  • Schedule one time and recurring payments
  • Send email payment requests for customers to view and pay orders
  • Send payment method requests so customers can securely add credit cards via a secure web form 
​Payment on account or order
Schedule recurring payment
Email payment request
Request payment method

EBizCharge App

Process Payments 
Based on our user research, we discovered users need the ability to:
  • Process payment on one or multiple orders, sometimes for the full order amount and other times for a partial amount as a deposit before invoicing
  • Set up recurring payments for subscriptions or repeat orders 
  • Process with credit cards and ACH accounts

So we created the "Process Payments" section below.
  • We designed a modular, sectioned layout that is commonly found in Salesforce
  • We added visuals cues (such as card icons) to make key information easier to view and repetition (such as the bolded total payment amount) to add clear confirmation before actions

Transaction History & Transaction Detail

We wanted to allow users to view transaction details and take actions like voiding, refunding, and emailing receipts, without needing to navigate to a separate payment gateway. We created a Transaction History section that displays key info at a glance. Clicking on a transaction reveals more transaction details. 

Email Payment Requests

Based on interviews with Salesforce users, various companies said:
  • They would save significant time, effort, and reduce liability if their customers were able to make payments on their orders themselves via secure, encrypted payment forms. 
  • Emailing payment links to customers would greatly reduce collection efforts of accounts receivable personnel. They no longer need to track down every customer, get them on the phone, and get sensitive credit card data over the phone to pay orders.
We added an Email Pay section where users can select an account, view their open orders, and select orders to send for payment. 
Create new email payment request
Pending payment requests

Recurring Payments

When designing recurring billing functionality, we kept hearing two main ways users wanted to set up recurring payments.
1. A fixed amount at a certain frequency (weekly, monthly, yearly, etc.)
2. Set up automatic payment of customer monthly balances for customers who are comfortable opting into auto pay  

Prototype 

We created a prototype of our designs and conducted a series of user testing via Zoom with existing Salesforce users.
Our user test plan defined: 
  1. Goals and objectives
  2. Participants and methods
  3. Procedure (tasks and a post session questionnaire)
  4. Usability performance measures such as completion rate and time on task. 
We provided an Adobe XD prototype link to participants asked them to show us how they would complete certain tasks and for their opinions throughout. After analyzing the findings, we made some design changes.

Current Progress

My team provided designs to developers via Zeplin and Adobe XD. I am currently working with development in the execution of the designs, with our designers providing additional design tweaks wherever needed.

< Back to all projects