A System Model: ACME B2B Reseller Platform

The product:
Add B2B reseller ticket sales to an existing B2C ticket sales platform.

The problem:
The ACME product team had no agreed-upon set of customer requirements and therefore could not agree on what needed to be built.

The ACME product team used a system model to:

  1. Capture customer requirements and business processes in a clear, easily referenced way.

  2. 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.

  3. Generate preliminary plans and strategies which could be validated (or not) by current and potential ACME customers.

  4. Provide context for long-term product development strategies and short-term reductions in scope.

  5. 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 had an existing B2C SaaS platform providing 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) venues such as these do significant business with resellers who can 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 for markup. Visitors benefit because reseller ticket prices are typically lower than when purchased directly from the venue.

At the time, venues’ reseller account managers conducted 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. Immediate delivery, no chance of loss or theft.

“When can you get us some screens?” (aka “the product kickoff”)

Product Management had gathered plenty of feedback from existing ACME customers and was confident they understood B2B sales requirements. There was no need to conduct additional market, customer, or competitive research.

And so, by definition:

  1. Design was late and…

  2. Development was blocked.

In spite of my previous product definition experiences (see the “Amazon Kindle eReader OOBE” use case) I fell into the trap of delivering detailed screens and flows which quickly 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”.

Which, of course, was supposed to unblock Development.

By taking an ad-hoc, screen-based approach the ACME product team could not agree on product scope which made it impossible to agree on a product definition. The product team kept uncovering critical customer requirements for features that were already “in”.

The guest checkout assumption (aka “we had no idea what we were doing”)

It took one particular issue to make the scope of our ignorance clear.

The working product 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 carefully validates and approves every reseller. Venues assign resellers to different discount and event availability tiers. Venues and resellers have 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 continually learning) to create a system model the team could use as context for making B2B product decisions. As I’ve said, you build models incrementally, beginning with the simplest, most obvious concepts.

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—finding out where your team differs on the basics, the opportunity, and what you (eventually) want to build.

You should be able to state what each incremental version of model adds to the team’s understanding.

So, what was the business ACME wanted to disrupt?

“Venues such as museums, theaters, ferry services, bus tour companies, and the like sell tickets to visitors who want to tour their facilities, attend their events, or use their services.”

Where do resellers fit in?

The ACME product team believed that reseller sales was a new opportunity. How do resellers fit into the model as it stood?

“Venues sell discounted tickets to resellers such as hotel concierges and discounters who sell them visitors. Resellers provide sales channels venues otherwise couldn’t create and support themselves. Venues sell discounted tickets directly to resellers. Resellers then sell tickets 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 were our assumptions at product kickoff?

“ACME believes enabling online reseller B2B ticket sales is a great opportunity. ACME will add reseller ticket sales functionality to the existing platform.”

This is what we had believed at product kickoff.

Assumptions were proudly recast as requirements. I began creating screens. Development began work.

That’s when we hit a dead end by assuming (incorrectly) that reseller sales could be transacted as guest checkouts.

That’s when I called a halt to design-by-screen.

That’s when I demanded we create a system model that was sufficiently detailed to:

  1. Use as a starting point for product decisions.

  2. Capture new requirements found during customer research.

  3. Keep us from overlooking entire critical features and requirements.

Adding detail: Venue B2C transactions

I demanded we document everything we (thought) we knew about B2C transactions in detail. This included the fact that venues could not manage their ACME-hosted B2C sales directly. They communicated event, schedule, and pricing changes had to an ACME account exec who then manually updated the ACME backend.

Common sense (i.e. no research needed in this case) told me resellers would want to manage their business directly, not through ACME intermediaries.

“Venues sell tickets to visitors directly at a POS kiosk or online through ACME. Venues’ access control scans tickets (digital or printed) and grants access to visitors. Venues work with ACME sales executives to keep online sales inventory databases up-to-date.”

Adding detail: Reseller-venue B2B and reseller-visitor B2C transactions

“Resellers deal 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 a POS kiosk or online. A reseller’s digital ticket may, in fact, be a voucher due to a lack of integration with the venue’s inventory management system (i.e. ACME).

Customer research

Detailed customer research, as expected, uncovered significant business and technical requirements.

Business requirements

Customer research showed that the venue-reseller B2B relationship is far more complicated than the venue-visitor B2C relationship.

  1. Resellers must apply directly to venues for pre-approval to qualify both for discounts and for the ability to issue vouchers.

  2. Venues categorize resellers with different discount and ticket availability tiers.

  3. 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. Resellers sell vouchers to visitors. A customer presents the voucher at a venue, is admitted, and then the venue bills the reseller after the fact.

Product requirements

Customer research revealed three major new requirements:

  1. Integration with existing venue sales services (platform architecture impact)

    • 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.).

  2. Reseller accounts

    • 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).

  3. Venue accounts

  • 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).

Using the model to make product decisions

Armed with a system model of the current state of the business and a new set of requirements, the product team began to fit everything together.

Requirement: Integration with existing venue sales services

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.

“ACME B2B reseller functionality will be separate from existing B2C functionality due to unique approval, account, and pricing requirements.”

Requirement: Reseller and venue accounts

There are industry-standard account creation patterns. I could model them separately from the larger system model allowing 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.”

The “final” model

The final system model showed the entire scope of the venue-reseller B2B platform ACME wanted to build.

The model showed:

  1. 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.

  2. ACME had to develop a significant Web presence to service venue and reseller customers.

  3. 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 findings, 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, allowing two-way connections (e.g. a venue could request a reseller to apply), and the creation of custom bundles.

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.