You must decide whether or not you want your organization to allow guest checkout functionality, which allows a web user to purchase product(s) for your website without creating an account. The guest checkout functionality is intended for the casual, occasional consumer. In your database a "guest" record is created for the web user. For more information, refer to Adding Demographic Information to a Constituent's Record in CRM360®.
The guest checkout workflow serves several purposes:
· Web users can see if they are already have a username/password for website to save them data entry time.
· Your organization can prevent a number of duplicate customer records by encouraging existing web users to log into your website rather than create a new back office record that will need to be merged later.
Email is
used to search SSO records, NOT all customer communication records. SSO
emails are kept in synch with the primary email address for each constituent.
The intent of this process is to screen for duplicates in a non-intrusive
manner that strikes a balance between data integrity and customer privacy/security.
· If the email address is NOT found, it is captured on the customer record as a "guest" record and the web user does not need to re-key it.
Returning guest web users will be prompted to login, because they never set up a password. It is expected that they will select "Forgot Password". If you feel your web users will be bothered by this workflow, then your organization can choose not to use the guest checkout option.
If you decide to use the guest checkout workflow, you will have to create a page with the Login control and an option to proceed as guest to complete the checkout process. This page is called the Checkout Landing page. When the web user selects "proceed as guest", he/she is redirected to the Guest Email Lookup page.
If you decide NOT to use the guest checkout workflow, then direct unauthenticated users to the standard login page on the website. Even if you decide not to use the guest checkout process, if you do not already have a standalone page with the Login control (e.g., the login that appears on your main page or in-line on some other page), then your site should still use this landing page.
There is
no option to proceed directly to step 1, because the checkout workflow
needs to account for users that are not logged in.
Before configuring the Guest Email Lookup control, it is important that your back office configurations are accurate. If not, these configurations will not display properly on your e-Business website. See Configuring the Back Office Settings for the Guest Email Lookup Control for more information on the system types and codes that need to be web enabled before setting up this control.
If you decide to use the guest checkout workflow, as a best practice, it is recommended that you set up a checkout landing page before this control. This will provide web users who have an account on your website the opportunity to log in and if not, they can select a link that redirects them to the first step in the checkout process. See the Checkout Landing Page section for more information.
The Guest Email Lookup control checks your system to see if the web user's email is already in your database. This is to ensure data integrity. If the web user's email is not in your system he/she proceeds through the checkout process as a guest. If his/her emaill address is already in your database, he/she has the following options: log into the site, retrieve his/her forgotten password or username, or provide an alternate email address.
When
a guest goes through the checkout process, the default customer class
assigned to them is "Guest". In addition, if you want to change
this default, it would require a change to the data service.
See Also:
· If you want an overview of the guest checkout process, refer to Workflows for the Guest Email Lookup Control.
· To add the Guest Email Lookup control to a page on the web, see Configuring the Web Settings for the Guest Email Lookup Control.
· To see how to set up the Checkout Landing page for web users who are not logged into your site before they start the checkout process, refer to Additional Steps: Checkout Landing Page.
After configuring the Email Lookup control and Checkout Landing page, the process displays differently depending if you allow multiple web users to share the same email address or not.
If you do not allow multiple web users to share the same email address, the workflow displays similar to what is shown below. If the web user's email address is NOT in your system, the web user begins the checkout process as a guest. If your web user's email address is in your system, he/she has the following options:
· Log into your site
· Retrieve his/her forgotten password
· Provide an alternate email address to begin the checkout process
If you allow multiple web users to share the same email address, the workflow displays similar to what is shown below. If the web user's email address is NOT in your system, the web user begins the checkout process as a guest. If your web user's email address is in your system, he/she has the following options:
· Log into your site
· Retrieve his/her forgotten password
· Provide an alternate email address to begin the checkout process
· Create a new account with this email address
As
of 7.5.2, the CHECKDUPEMAIL application parameter will determine on the
Guest Email Lookup, Membership
Join Registration, Membership
Join User Already Exists, Registration,
and User Already Exists
controls in e-Business whether the same email address can be shared by
multiple web users. If you set this parameter to 'N" (you allow duplicate
emails), multiple users can share the same email address. In addition,
if you allow web users to share the same email address, you should NOT
set the application parameter CUS WEBUSERNAME_FORMAT
application
parameter to "CUSTOMER_EMAIL_ADDRESS".
