Information informs when architected intelligently.
The revenue engine will cough and sputter, and may even blow a gasket if data does not flow friction-free throughout the system. Yet friction-free is hard won. It requires you to think through your information architecture carefully and to execute flawlessly at every node throughout the entire system. Since it’s hard to redo once implemented, you want to get it right the first time. To make that happen, focus on these two things:
- Smart data structure
- Smart data flow architecture
Smart Data Structure
Smart data structure exhibits clear, unambiguous definitions of data elements, and the rules governing the relationships between data elements. The objective of this chapter is not to provide a comprehensive documentation of the factors to consider in your information architecture, but rather to provide a glimpse into the degree of rigor required to get it right.
Let’s take the example of a B2B SaaS company. We must start at the very beginning. Here’s a simple question: what is a customer?
This issue is not as simple as it seems. Is a customer a person, or a company? Let’s assume you determine it’s a company (let’s use the word “account”). When does an account become a customer? We can’t answer that question until we further define an account. Is the account General Electric, or is the account the marketing department in the San Francisco region of General Electric? Let’s assume you determine that the parent account is General Electric, and the child account is the San Francisco region, and the grandchild account is the marketing department in the San Francisco region.
We go on. Is an account (whether parent, child or grandchild) a customer the moment you define it as a prospect? Stop right there. What is a prospect? Is a prospect a person, or is a prospect an account? Perhaps you decide the answer is both: a prospect contact is a person, and a prospect account is an account. Prospect accounts are those accounts that fall within the definition of your ideal customer profile (ICP). Prospect accounts include prospect contacts. So is a prospect account a customer?
Let’s assume you determine that the status “customer” is only achieved once an account buys at least one product item or package from you. If three grandchild accounts inside General Electric separately purchase a product item from you over a six month period, in three separate transactions, does this constitute three customers or one? And if an account becomes a customer and then later cancels, do they revert to being a non-customer or do they continue to be considered a customer?
Your answers to these questions are imperative. The definitions you establish must be carried throughout your whole system: into your CRM, your product system, your accounting system, your billing system, and your financial plan. Any inconsistency from platform to platform will turn your data into a confusing mess.
There may be no single universal list of “right” answers, but it is critical that your answers are internally consistent throughout your revenue engine.
Here is one example of a set of definitions for a prospect contact and a prospect account:
- A company is a prospect account if it meets the ICP definition
- A prospect account may have a hierarchy: such as parent account, child account, and grandchild account
- A prospect account comprises prospect contacts
- Each prospect contact associates with at least one level in the prospect account hierarchy
- A single prospect contact may be touched by, and may act on, multiple actions or campaigns
- An action by a prospect contact that results in an incoming data packet (lead form, email message, etc.) generates a raw lead
- A raw lead from a prospect contact is designated a marketing qualified lead (MQL) if an automated score (based on contact characteristics, type and amount of data entered and level of activity) achieves a predefined threshold
- Prospect leads (raw leads and MQLs) may or may not be able to be tracked back to a specific marketing or sales action or campaign via an attribution rule
- Since multiple outbound campaigns and connections may yield a single raw lead or MQL, the attribution rule defines the method by which credit attributes to outbound campaigns
- One prospect contact may generate multiple leads
- Multiple prospect contacts may generate multiple leads for a single prospect account
- An MQL becomes a sales qualified lead (SQL) once a sales development rep (SDR) determines that: the account meets the ICP; the prospect contact meets the target persona; the prospect contact meets the thresholds for budget, authority, need, and timing (BANT); and, an appointment is set up between an AE and the prospect contact
- An SQL becomes a sales accepted lead (SAL) once an account executive (AE) has held an initial call with the prospect contact, has reconfirmed the contact meets BANT and is interested in going to the next step
- At the point that the next meeting is held, the appropriate prospect account hierarchy is established, and the lowest appropriate level in the hierarchy becomes a prospect account opportunity (i.e. General Electric — San Francisco region — marketing department)
- All prospect contacts within the prospect account that fit the profiles of decision maker, influencer, user or blocker may be identified and retained in the prospect account record, associated with their appropriate hierarchical level
- A prospect account opportunity goes through four steps: discover, prove, negotiate, and close.
Here’s one example of a set of definitions for a customer account:
- An account becomes a customer account with purchase of a product item or package, at which time an account ID is assigned.
- The account ID is a unique identifier and is used consistently across all systems (CRM, product system, billing system, accounting system, financial plan, etc.).
- An account ceases to be a customer account when no product item or package is live, but it retains the account ID — when this happens, it returns to its status as a prospect account.
- Any level at which the product can be sold and serviced is an account (parent, child, grandchild, etc.).
- Parent / child / grandchild relationships are tracked via a nested set of account IDs
- These account hierarchy relationships are identified in an account tracking system (possibly the CRM).
- The number of customer accounts is measured based on the most atomic level of product purchase capability. For example, the marketing department in the San Francisco region of General Electric might be one customer account, and the marketing department in the Minneapolis region might a second, separate customer account (sitting inside General Electric’s nested parent account hierarchy).
- An account (at any level in the account hierarchy) may have one or more external affinities (examples: OEM, ad agency, partner). These affinity relationships are specified in the account record in the CRM system.
- Every account has a unique account ID, which is applied consistently throughout the whole system (the CRM system, the contract system, the product system, the billing system, the accounting system, the financial plan, etc.).
- In an account hierarchy, the parent is a customer account if at least one child / grandchild / great-grandchild account is live with at least one product item or package.
- The system can support reporting of account status for all levels within an account hierarchy under the parent.
- An account is live if there is at least one product item or package that is active, paused, or cancel pending.
- Live vs. not live status is determined at any account hierarchy level (parent, child, grandchild, etc.).
Notice that the definitions are exacting and rigorous. There’s no wiggle room. That’s the key to a smart data structure.
Smart Data Flow Architecture
Data structures are set up to support workflows. For instance, to manage workflows such as customer acquisition, product selection, pricing, contracting, product provisioning, product launch, and ongoing customer success, four data structure categories are key: prospect account lifecycle stages, customer account lifecycle stages, orders, and billing arrangements.
Prospect Account Lifecycle Stages
The stages of a prospect account can now be defined using the data structure definitions and mapped to the Bow Tie domains as shown below:
Prospect account lifecycle stages are:
- Prospect contact: raw lead
- Prospect contact: marketing qualified lead (MQL)
- Prospect contact: sales qualified lead (SQL)
- Prospect contact: sales accepted lead (SAL)
- Prospect account: opportunity (discover step)
- Prospect account: opportunity (prove step)
- Prospect account: opportunity (negotiate step)
- Prospect account: opportunity (close step)
- Customer account: closed / won
Customer Account Lifecycle Stages
Similarly, the lifecycle stages of a customer account can now be identified and mapped to the Bow Tie domains as shown below.
- Contract signed
- Launch pending — new
- Launch pending — paused
- Launch pending — unpaused
- Pending paused
- Cancel pending and pending paused
- Cancel pending and paused
- Cancel pending — no pause
- Expansion transactions
Orders are the means by which changes are made to the lifecycle stage, term, price, or invoice amount of a product item or package. Order types include:
- New order
- Price / term length / billing arrangements (PTB) change order
Specific PTB change orders may include:
- Pause order
- Unpause order
- Cancel order
- Stop cancel order
- Credit order
- Price change order
- Billing arrangements change order
Billing arrangements touch upon the billing entity or entities, the billing method, the billing type, and the billing cycle.
- Usually, the customer is also the billing entity — but not always. One or more billing entities may exist
- Billing methods include prepay, advance billing, and arrears billing
- Billing types include credit card, check, and automated transfer
- The billing cycle is the agreed start day and end day of service for each period for which the customer is billed
You get the idea. In tightening up your workflows, the same rigor must apply in selecting product items and packages, using the price book, signing contracts, executing product provisioning, managing accounting and billing, managing employee data (titles, hierarchies, departments), etc.
Data elements and their relationships are used daily in the business to manage your workflows.
A critical resource for various teams across the whole system is the customer account record.
The customer account record includes:
- Customer account ID. Every customer account has a customer account ID, which is a unique identifier across all systems (the CRM, contract system, accounting system, billing system and the transaction logs that flow into the financial plan). The customer account ID is displayed in the customer account record in the CRM.
- Contact information. List all contacts with name, phone, email, mail information. Certain contacts may be designated particular contact roles tied to alerts and other correspondence they are to receive as appropriate.
- Account hierarchy. If the customer exists within a customer hierarchy (parent, child, grandchild, etc.), its position in the hierarchy and relationship to other customer account records is recorded via its nested customer account ID structure.
- Affinity groups. If the customer is tied to any affinity groups (ad agency, OEM, etc.), these relationships are recorded.
- Customer configuration. By product item and package, provisioning configuration detail and current lifecycle stage are identified with orders and billing history. Current and historical invoices and statements are shown. The billing arrangement, billing status, and credit order status are shown.
- Customer support. Customer survey data and customer support open cases and history are shown.
- Communications. The archive of past communications (email history, etc.) is shown by department (sales, customer success, finance, etc.).
- Account team. The assigned account exec, launch rep, customer success manager, and finance contact are identified.
Access to the customer account record is available via a link in:
- The product system
- The contract system
- The accounting system
- The billing system
It’s hard to overestimate the power of getting data structure and data flow architecture right. If you step back and think it through then carefully implement it at the most granular level across all workflows, you will build serious horsepower into your engine. Your metrics dashboards will be unfailingly accurate. You won’t waste time cleaning up the messes created by bad data, bad handoffs, or uninformed employees. You’ll be running a massively more efficient company that is much more prepared to scale.
If your company suffers from ill-conceived information architecture, it’s critical to come to terms with the magnitude of the problem. It’s a significant drag on your future. To overhaul your engine requires a material investment of time, effort, and money (front-end loaded) to get the payoff (back-end loaded). You may well need to bring in contractors to help you execute the redesign and implementation successfully. It will be worth it. Once overhauled, your engine can begin to perform like a Porsche.
Hit the gas.
. . .
If you would like more CEO insights into scaling your revenue engine and building a high-growth tech company, please visit us at CEOQuest.com, and follow us on LinkedIn, Twitter, Facebook, and YouTube.