A software supplier labels a customer “healthcare.” Sales uses the label to route the account, product teams use it to prioritise integrations, and analytics uses it to compare revenue. The customer is actually a group containing clinics, a laboratory, and a company selling software to other providers. One label may be adequate for an account list while being misleading for product requirements or statistical reporting.
Business vertical classification groups organisations around industry-related needs or activities. It can make a large market easier to understand, but a useful implementation needs more than a list of sector names. The team must define what is being classified, why the distinction matters, how assignments are supported, and how changes reach the systems that depend on them.
Distinguish a Vertical From an Official Industry Code
A business vertical is usually a market focus shaped by related customer needs. Labels such as healthcare, retail, financial services, or logistics are common, but their boundaries depend on purpose. A software vendor’s healthcare vertical might include organisations that an official statistical classification places in several industries.
Official industry classifications provide a defined structure for economic statistics and related uses. The US Census Bureau’s NAICS documentation describes classification of business establishments by activity. ANZSIC, documented by the Australian Bureau of Statistics, supports industry statistics in Australia and New Zealand.
These systems are useful reference points, not automatic definitions of a vendor’s addressable market. An industry code does not establish that an organisation needs a particular integration, has a specific buying process, or is subject to every regulation associated with a broad sector.
Keep the concepts separate in the model. An official industry code, a sales vertical, and a product-fit segment can coexist as different fields or relationships. Their definitions should explain why they may differ. Replacing them with one ambiguous industry column makes later disagreement difficult to diagnose.
Decide Which Entity Receives the Classification
The unit matters. A legal company, corporate group, establishment, operating division, customer account, and individual location are not interchangeable. A retailer’s head office and distribution operation can require different software even when they belong to the same group.
NAICS generally classifies establishments according to their primary business activity. ANZSIC also uses defined statistical units and predominant activity within its framework. Read the relevant NAICS manual or ANZSIC guidance for the intended statistical use rather than assuming a company name uniquely determines a code.
For the healthcare customer, the account might represent the whole group while implementation takes place at individual clinics. The sales system could retain a group-level vertical and link locations to more detailed activity and requirement records. This supports a broad commercial view without forcing every location to inherit an unsuitable configuration.
Identify the unit in reports too. “Twenty customers in manufacturing” could count contracts, legal entities, or factories. Those denominators support different conclusions. The data-analysis strategy article explains why the grain of a dataset belongs in the analytical question from the beginning.
Corporate relationships need their own representation. If a group owns three subsidiaries, retaining those links lets an analyst choose a group-level or subsidiary-level view deliberately. Repeating the parent company’s industry label across every account does not resolve that counting choice and may hide meaningful differences in activity. Classification and organisational hierarchy should work together without being treated as the same relationship.
Use Industry as Context for Requirements
Industry can suggest useful questions. A manufacturer may need lot traceability and equipment integration. A retailer may need stock visibility and returns handling. A clinic may need records associated with patients and encounters. These are examples of operating needs to investigate, not guarantees about every organisation assigned the label.
Within a vertical, size, geography, operating model, user roles, and purchasing arrangements can differ substantially. A small independent practice does not have the same implementation constraints as a hospital network. An online marketplace and a local shop may both sell products while handling fulfilment and customer relationships differently.
Capture decision-relevant requirements directly where possible. If offline access affects product suitability, record that need instead of deriving it from “construction.” If a customer requires a specific access-control or audit feature, confirm the requirement rather than inferring it from a sector stereotype.
Legal applicability needs particular care. The original classification is not a compliance determination. Rules can depend on jurisdiction, the organisation’s role, the data processed, and the activity performed. The data-protection article describes how to connect those actual conditions with controls.
Vertical and Horizontal Describe Product Focus
A vertical product concentrates on a set of industry-related workflows. A horizontal product addresses needs shared across industries, such as identity, collaboration, or accounting. Neither description means the product has no customers or requirements outside that focus.
A general identity platform may serve a university, a hospital, and a manufacturer through a shared core. Each can still need different integrations, identity lifecycles, or approval rules. A specialist clinic platform may use that horizontal service while modelling patient appointments and clinical roles in its own application.
Products can combine these approaches. A common platform might offer industry-specific modules. A specialist vendor might discover a capability that applies more broadly. The categories describe where product effort and market understanding are concentrated; they do not establish a permanent technical identity.
Evaluate the trade-off through requirements and evidence. Specialisation can reduce custom work for a particular customer, but it can also introduce assumptions that make another customer’s process harder. A larger potential market does not automatically make a horizontal strategy more profitable, and deeper specialisation does not guarantee better fit.
Design Assignment as a Governed Record
A useful classification record identifies the entity, scheme, code or category, scheme version, source, and effective period. Where assignment involves interpretation, preserve an appropriate review status and the evidence used. The goal is to explain why the classification exists and which decisions may rely on it.
| Record element | Question it answers |
|---|---|
| Classified entity | Which company, unit, location, or account is described? |
| Scheme and version | Which definitions apply to the code? |
| Category or code | What assignment was made? |
| Source and review status | What supports the assignment, and was it verified? |
| Effective period | When is the assignment intended to apply? |
A single-select field may be sufficient for a small, low-consequence account list. More consequential uses may require several activity relationships, a designated primary assignment, and separate requirements. Choose the structure for the decisions it supports rather than building the most elaborate taxonomy possible.
Distinguish unknown, unreviewed, and genuinely outside scope. Using “other” for all three can conceal poor coverage. A customer without enough evidence should not be confidently assigned a category merely because a reporting dashboard requires every row to contain a familiar label.
Handle Mixed Activities and Changes Explicitly
An organisation can enter a new market, sell a division, acquire a business, or change its predominant activity. Official classifications also evolve. A code without its scheme and version can become ambiguous, particularly when historical reports combine data collected under different editions.
Do not assume a crosswalk creates a one-to-one equivalence between schemes. A category can split, merge, or cover a different combination of activities. When mapping into a reporting hierarchy, retain the original assignment and document how ambiguous cases are handled. A roll-up convenient for one report may lose detail required elsewhere.
Decide whether historical analysis uses the classification recorded at the time or a restatement under the current scheme. Both can answer legitimate questions. Quietly overwriting old labels can make a revenue trend appear to change because the classification changed, not because the customer base did.
The production data-strategy article examines these semantic changes across dependent systems. Changes need an owner, impact assessment, and communication to users who rely on the category for routing, analytics, or configuration.
Test Automated Assignment Against the Intended Use
Rules or models can suggest classifications from activity descriptions, websites, or reference data. Those sources can be incomplete, outdated, or promotional. Evaluate the assignment against a defined reference and the actual entity, rather than treating a familiar company name as sufficient evidence.
Where human judgment is needed, document borderline examples and review disagreement. A confidence score from a classifier is not the same thing as a verified official code. The system should preserve a route to abstain, request more information, or correct an assignment.
Use stricter review when the label controls a consequential action. A marketing segment used to choose an email template has a different risk profile from a category that determines contractual terms or access to a service. Avoid turning an uncertain descriptive label into an unquestioned eligibility rule.
Keep the Classification Useful to Its Consumers
Review whether the categories improve the work they were designed to support. Can sales route accounts appropriately? Can analysts compare a stable population? Can product teams find customers with the required workflows? Frequent corrections or large undifferentiated categories may indicate that the scheme no longer fits its purpose.
Industry gives context, while verified requirements establish what a customer needs. A maintainable classification connects the two without pretending they are identical. Its value comes from clear definitions, supported assignments, and controlled change, so that one convenient label does not become several incompatible assumptions across the business.
