Commerce & Checkout
Why Clean Checkout Data Matters After the Order Is Placed
Checkout feels like the end of an ecommerce order.
For the distributor, it is closer to a handoff.
The customer has entered a shipping address, selected billing information, supplied whatever customer or location details the program requires, and submitted the order.
Now other systems and people have to use that information.
A field that looked harmless on the checkout screen can become a shipping problem, an order-entry problem or another piece of information someone has to clean up manually.
That is why checkout data matters after the shopper is gone.
Free text is flexible until somebody has to use it
Letting someone type anything into a field is easy.
It is also how one location becomes:
- New York
- NYC
- New York City
and perhaps an internal code somebody else uses entirely.
A person can usually recognize that those values may refer to the same place.
A downstream system may not.
Commerce's Responsive checkout supports predefined list selections for configurable shipping and billing fields in addition to text entry. Administrators can define the values a shopper chooses from rather than asking every user to enter the information independently.
The shopper gets a straightforward choice, and the order gets a predictable value.
A valid-looking address can still create work later
People are good at understanding imperfect addresses.
Shipping systems can be less forgiving.
A missing direction, incorrect ZIP code or inconsistent city may become a problem only after the customer has already completed the order.
Commerce can verify newly entered custom shipping addresses during Responsive checkout. When a suggested correction is available, the shopper can compare it with what they entered and choose which version to use. If the address cannot be verified, the customer is warned but can still continue.
That behavior is important. Address verification can help improve the information without pretending every address the service cannot verify is necessarily wrong.
Current Commerce functionality also supports refinements around city verification and international-address handling.
The next system may have different limits
A checkout field can accept information that the back-office system cannot store in the same way.
In that case, the shopper may have entered everything correctly. The problem appears later.
When one system cannot accept what another allows the customer to enter, that mismatch has to be dealt with somewhere.
Catching it while the customer can still see and correct the information is much better than discovering a shortened address after the order has moved downstream.
Some checkout values matter more after checkout
A location code can look like an ordinary field or account setting to the shopper.
Another system may use that value to determine how the order is identified or processed.
Commerce supports buyer-account scenarios where the appropriate location code has to be preserved as an order moves downstream.
The person ordering may never know that distinction exists.
The system receiving the order does.
This is why checkout configuration cannot be based only on what makes the form convenient to complete. Some values exist because the next part of the process depends on them.
International orders expose assumptions quickly
An address form that works perfectly for U.S. orders can reveal its assumptions as soon as another country enters the picture.
State and province structures differ. Postal formats differ. Country information has to survive the handoff. Shipping logic can change.
Current Commerce functionality includes handling for international country display, saved custom locations, shipping information and non-U.S. Punchout orders.
Those are different scenarios, but the underlying issue is the same.
International support has to exist in the data, not just in a country dropdown.
Bad checkout data creates work somewhere else
Most organizations do not have a person whose job is simply to repair ecommerce order data.
The work lands wherever the problem becomes visible.
Customer service corrects an address.
Operations works out which location the customer meant.
Someone fixes a value before the order can move into another system.
The warehouse discovers that shipping information is incomplete.
A back-office field contains a shortened version of what the shopper actually entered.
Each correction may be small. Repeated often enough, the corrections become part of the process.
For more on what happens when ecommerce hands an order into the rest of the business, see B2B Ecommerce for Print & Promo Distributors.
Design checkout for the people who receive the order too
The shopper still needs a clear, uncomplicated checkout.
But the form has another audience: the people and systems that use its information afterward.
Values that need to remain consistent should be collected consistently. Downstream field constraints should be understood before customers encounter them. Address information should be useful to the shipping process. Customer and location identifiers should mean the same thing on both sides of the handoff.
None of that needs to make checkout feel more complicated.
It means doing more of the data work while the information is still being collected, rather than asking someone to repair it after the order arrives.
Commerce connects customer ordering with the workflows responsible for processing those orders, including checkout controls that help carry usable information downstream.