A System Model: ACME B2B Reseller Platform
The product:
Add B2B sales services to an existing B2C sales platform.
The problem:
The ACME product team had no agreed-upon set of requirements. Extensive work on a checkout flow had to be abandoned because we didn’t understand customers’ business practices.
The solution:
The ACME product team used a system model to:
Capture customer requirements and business processes in a clear, easily referenced way.
Help the product team quickly agree on requirements which were in scope and would be used as the basis for product decisions. This sped decision making and limited scope creep.
Generate preliminary plans and strategies which could be validated (or not) by current and potential ACME customers.
Provide context for long-term product development strategies and short-term reductions in scope.
Unblock developers prior to the delivery of final screens.
Background
In 2016, I was Head of Design (and sole design resource) at a small startup named ACME (honest). ACME’s existing B2C SaaS platform provided asset management and visitor ticket sales services for museums, theaters, ferry services, bus tour companies, and the like.
In addition to selling tickets directly to visitors (either online or in person) these venues also conduct significant business with resellers who promote the venues in otherwise inaccessible markets. A San Francisco-based bus tour company, for example, can attract visitors from around the world thanks to the promotional efforts of regionally-based resellers.
Venues sells tickets to resellers at a substantial discount. The reseller then sells tickets directly to visitors with a markup. Visitors benefit because reseller ticket prices are typically lower than tickets purchased directly from the venue.
At the time, venues’ account managers conducted reseller sales in person or by mail, fax, or phone. Venues delivered printed tickets to resellers who, in turn, distributed them to their customers. Tickets were often lost, stolen, or simply overlooked until they were no longer valid.
ACME’s business opportunity was clear—allow resellers to buy digital tickets online from venues and provide immediate delivery with no chance of loss or theft.
“When can you get us some screens?” (aka “the product kickoff”)
Product Management was confident they understood B2B sales requirements because they understood existing B2C sales requirements. There was no need to conduct additional market, customer, or competitive research. All we had to do was extend existing functionality. And so, by definition:
Design was late and…
Development was blocked.
In spite of my previous product definition experiences (see Amazon Kindle eReader OOBE▸) I fell into the trap of delivering detailed screens and flows as quickly as possible. These became the formal plans of record. After every product review I fixed mistakes, added new requirements, created, updated, and discarded dozens of ever-more complicated screens and functional flows in an attempt to get things “right”—the magic moment Development would be unblocked.
The ACME product team could not agree on overall product scope. We were working at the feature level and not thinking about larger solutions or business problems. We kept uncovering critical customer requirements for features we had thought designed and delivered.
We had no idea what we were doing (aka “the guest checkout assumption”)
It took one particular issue to make the scope of our ignorance clear.
The plan had been to simply extend existing ACME B2C functionality to support resellers. The B2C platform had no customer accounts—all sales were basically guest checkouts. We assumed reseller B2B sales could also be conducted as guest checkouts. Development had done significant work on the reseller shopping cart feature when we found out that reseller guest check outs were impossible and reseller accounts were mandatory.
There were no technical blockers—current business processes were the blockers. Every venue wanted to carefully validate and approve every reseller. Venues wanted to assign resellers to different discount and event availability tiers. Venues and resellers had a wide variety of payment methods and terms.
All of these processes had to be accommodated in the B2B sales flow.
We needed a system model, not screens.
I stopped designing screens. I insisted that we conduct customer research to understand how venues sell tickets to resellers and visitors, how resellers sell tickets to visitors, and how the existing ACME point-of-sale (POS) and B2C sales features fit into all of that.
I took what we had learned (and were continuing to learn) to create a system model the team could use as context for making B2B product decisions.
System Model 101: Begin at the beginning…
Document the basics, the stuff that’s supposedly so painfully obvious it’s not necessary to talk about. That’s the whole point of building a model—to find out where your team differs on the basics, the opportunities, and what you (eventually) want to build. You should be able to state what each incremental version of the model adds to the team’s understanding.
So, what was the business ACME was attempting to disrupt?
“Visitors buy tickets, either in person or online, from venues in order to obtain admission.”
Where do resellers fit in?
The ACME product team believed that reseller sales was a new opportunity. How did resellers fit into the current model?
“Venues sell discounted tickets directly to resellers such as hotel concierges and discounters who sell them visitors. Resellers provide sales channels venues otherwise couldn’t support themselves. Resellers then sell tickets to visitors for more than what they paid the venue but for less than what the visitor would pay the venue directly.”
What does ACME currently provide?
ACME was providing B2C services to venues. I added that to the model.
“ACME has a white-label, B2C online sales platform and an integrated point-of-sale application used by ACME customers (venues) to sell tickets directly to visitors.”
What was the ACME opportunity?
“ACME believes enabling online reseller B2B ticket sales is a great opportunity. ACME will add reseller ticket sales functionality to the existing platform.”
And we were off and running. Assumptions were proudly recast as requirements. I began creating screens. Development began work. That’s when we hit a dead end. We had assumed reseller sales could be transacted as guest checkouts. We were flat-out wrong. Existing code would have to be thrown out.
That’s when I called a halt to attempts to design-by-screen. I demanded we create a system model to use for identifying and capturing product requirements and decisions.
Expand the model: B2C transactions between visitors and venues
I documented everything we thought we knew about B2C transactions. This included the fact that venues could not manage their ACME-hosted B2C sales directly. They had to contact an ACME account exec who then manually updated event, schedule, and pricing content.
“Venues sell tickets to visitors directly at a POS kiosk or online through ACME. Venues’ access control validates tickets (digital or printed) and grants visitor access. Venues work with ACME sales executives to keep online sales inventory databases up-to-date.”
The updated model helped the team realize that continuing to use in-house account execs was not scaleable. We agreed to include a requirement for venue account self-management into our product planning.
Expand the model: Resellers’ B2C transactions with visitors and B2B transactions with venues
Customer research, as expected, uncovered significant business and technical requirements. For example, the venue-reseller B2B relationship is far more complicated than the venue-visitor B2C relationship.
Resellers must apply directly to venues for pre-approval to qualify both for discounts and for the ability to issue vouchers.
Venues categorize resellers with different discount and ticket availability tiers.
Resellers sell visitors three different proofs-of-admission:
Tickets: Digital, print-at-home, or pre-printed tickets (picked up directly from the reseller or sent by mail).
Sales confirmations: Redeemed at the venue will-call in exchange for a ticket and/or admission.
Vouchers (new): A promise-to-pay sold by the reseller to their customers.
Vouchers had been totally overlooked during the initial product definition phase. Vouchers are essentially IOUs. An authorized reseller can sell a voucher to a visitor. The visitor presents the voucher to the venue. The venue then bills the reseller for the agreed admission price. Venues and resellers use vouchers because of the difficulty in integrating various ticket inventory services. Any ACME B2B solution should have an option for venues to pre-authorize vouchers to better predict attendance.
“Resellers buy tickets directly from venues face-to-face or via phone, mail, email, or fax. Physical tickets are frequently lost, stolen, or simply overlooked. Resellers sell discounted tickets directly to visitors via a POS kiosk or online. A reseller may sell a voucher instead of a ticket.
Expand the model: B2B integration with existing B2C sales services (platform architecture impact)
Customer research identified that:
Existing ACME B2C customers must be able to add new B2B features seamlessly.
New ACME customers must be able to choose either B2C features, B2B features, or both.
Reseller sales features must be added to the ACME point-of-sale (POS) application.
Scanning and redemption procedures were not standardized across venues; tickets required multiple forms of validation (QR codes, UPC codes, serial numbers, etc.).
The product team realized it wouldn’t be possible to simply extend existing B2C functionality to cover reseller-specific needs such as venue pre-approvals, tiered pricing, and the like. B2B functionality would therefore have to be a separate, parallel set of functionality. This decision freed Development to begin necessary architectural work to support stand-alone B2B functionality.
“ACME B2B reseller functionality will be separate from existing B2C functionality due to unique approval, account, and pricing requirements.”
Expand the model: Support for venue and reseller accounts
Reseller accounts required:
Access management and roles and permissions for reseller employees.
Inventory (ticket) management and integration with existing B2C sales functions.
Applications to venues for reseller status.
Voucher registration (uniquely identify vouchers to make it easier for venues to redeem).
Venue accounts required:
Access management and roles and permissions for venue employees.
Event scheduling, capacity (limits on ticket sales), fixed and variable pricing.
Reseller approvals and categorization (tiers).
Reseller billing (voucher redemption).
There are industry-standard account creation patterns which I modeled in detail separately from the larger system model. This allowed Development to begin work on key reseller and venue account requirements without the need for screens.
“Resellers would be redirected from venue home pages to an ACME landing page. Resellers would have options to log in to their account and make purchases or apply for a new ACME reseller account. Resellers and venues could also log in to their ACME accounts or create new accounts from the ACME home page.
“Reseller and venue accounts would have activity dashboards linked to inboxes for specific activity objects. Each activity object would have its own unique detail view with associated options.”
Expand the model: The “final” model
The final system model showed the entire scope of the venue-reseller B2B platform ACME wanted to build.
The model showed:
Major platform architecture changes: B2C and B2B services would be related but separate. They would, however, have to access a common inventory of events, merchandise, and other items for sale.
ACME had to develop a significant Web presence to service venue and reseller customers.
The basic structure of both reseller and venue accounts and key integrations between the two (e.g. the ability for resellers to apply for pre-approval). The sales model would be a reference as additional details and requirements were understood and added to the product plan.
Summary
I worked on the system model in parallel with customer research efforts, updating it as we learned more about the B2B business. In its “final” form, shown above, the system model kept the product team aligned and working efficiently. We could refer to the system model at any time and understand what had been completed, what was under development, and what hadn’t been started.
Of course, the product team had to identify additional functional details for every element in the model—and Design (i.e. me) eventually had to deliver screens.
In terms of product strategy, the system model helped the product team imagine several entirely new ACME services such as a marketplace for venues and resellers to promote themselves to each other (e.g. a venue could request a reseller to apply).
As always, technical problems arose and the product team had to make trade-offs between features, schedules, and resources. Instead of trying to reduce scope across the board, the product team, thanks to the system model, realized it could drop venue accounts entirely from the first release. Why? Because ACME already had a working (if not very extensible) way to meet venue needs through account executives and manual back end updates.
This decision allowed ACME to focus on building a solid, robust B2B solution while promoting venue accounts as a coming feature.
I’ve shown the ACME system model growing smoothly and logically from a simple two-way transaction to a complicated representation of the major relationships, transactions, and data flows between visitors, venues, resellers, and ACME itself. Of course, that’s not what happened in practice. The product team would change its mind, a particular visualization didn’t capture an issue, or we simply learned something new.
The system model ebbed and flowed in complexity and breadth, but always reflected what the product team understood and had agreed on at that point in time.
And Development was unblocked early and often. The product team could make fundamental decisions affecting overall product architecture with confidence. Design based all major interactions on existing, well-understood patterns which could be referred to in lieu of screens. Development could identify an element in the system model and huddle with Design to hash out a detailed-enough solution which could easily be refined later.