Segmenting Prospective Customers by Data and Integration Needs

Hello again. In the previous lesson, you identified the people behind a customer ingestion journey: who sets up a connection, who can authorize data sharing, and who decides whether the result is useful. Those roles matter during discovery because the person requesting “an integration” may not know what the source system can actually deliver.

This lesson shifts from one customer journey to patterns across prospective customers. You will segment them using four dimensions: source system, data volume, freshness need, and integration capability. The aim is not to give every prospect a permanent label. It is to recognize which customers can follow a similar ingestion journey, which need different support, and where a requirement may be impossible with the source currently available.

Segment the ingestion problem, not just the company

A company’s size or industry can be useful context, but neither reliably tells you how its financial data will reach your product. Two similarly sized customers might both want a draft financial report. One can export a trial balance from a modern accounting system on demand; the other must request a file from an external administrator after each close. Their downstream goal is similar, but their ingestion journeys are not.

The unit you are segmenting is therefore a customer–dataset–use-case combination. The same customer may belong to one segment for a monthly trial balance and another for payment-instruction data needed throughout the day. Keep the roles from the previous lesson attached to that combination: an available export is not an available integration if nobody has permission to configure or send it.

The following video is about B2B segmentation broadly, rather than ingestion specifically. Its useful idea here is to combine a small number of relevant lenses instead of assuming that one company attribute explains every product need.

Your four lenses answer different questions:

Keeping these dimensions separate prevents a common shortcut: treating “large customer” as a synonym for “high volume,” “needs real time,” or “has an integration team.”

Identify the actual source and its constraints

“Accounting data” and “ACH data” describe datasets, not source systems. A trial balance might come from an accounting application’s built-in CSV export, a scheduled report from an ERP system, or a customer-controlled warehouse containing replicated finance data. An ACH instruction might be delivered in a structured file or exposed through an operational system that holds instruction records. Each origin presents a different path to the first usable product state.

Record both the system of origin and the available way to extract the relevant data. “Has an API” is not enough: the API must expose the needed records and fields, at an acceptable cadence, to someone who can obtain approved access. Likewise, a customer may possess a warehouse without having the trial-balance tables or permission to share them. Do not infer dataset availability from a vendor name or a list of general platform features.

It helps to distinguish a source’s properties from the customer’s ability to use them. A source may support scheduled exports, but the customer might lack an administrator who can configure one. Conversely, a capable implementation team cannot produce intraday updates from a source that publishes only an overnight file. This is where your role map becomes useful: ask the implementer what can be extracted, the administrator what can be configured, and the data owner and risk reviewer what can be authorized.

Measure volume and freshness separately

Volume describes the amount of data the ingestion journey must handle. Ask for typical and peak records, files, and file sizes over a stated period. Also ask about an initial historical load and later backfills: a customer might send only a small daily update but require years of records during onboarding.

For file-based data, file count can conceal the work involved. The ACH structure pictured below contains entry-detail records inside a batch, surrounded by control records. One received file is not necessarily one business record—or even one batch.

Freshness is about the deadline for use, not simply how often a job runs. A precise requirement might be: “The final trial balance for a closed period must appear in the draft report by 09:00 on the next business day after the customer makes it available.” That is more informative than “daily ingestion.” It identifies the relevant source event, the usable product state, and the deadline. A five-minute requirement similarly needs a starting point: five minutes after an instruction is created, after the source publishes it, or after your product receives it are materially different promises.

A short video introduces the distinction between collecting records for a batch and processing a continuing flow. Treat these as useful concepts, not as automatic recommendations: a batch can be small or frequent, and a streaming pipeline cannot make source data appear before the source publishes it.

Microsoft Learn’s Determine integration requirements connects amount, frequency, and system capability. Read it with a product-discovery question in mind: what would you need to verify before placing a customer in a segment?

The distinction between average and peak load is especially important. Receiving 60,000 records evenly over an hour differs from receiving all 60,000 at once just before a reporting deadline. For segmentation, a rough peak estimate and the reason for the peak—month-end close, daily cutoff, or initial backfill—are often more useful than a precise annual total.

Turn four dimensions into usable segments

A segment is useful when it predicts a different product or onboarding need. The following are illustrative profiles, not universal thresholds for fintech customers:

The first two profiles differ in both load and operational support, despite sharing a scheduled-data shape. They may need different onboarding guidance and capacity planning. The third is different for a more fundamental reason: its desired freshness conflicts with its confirmed source capability. Labeling it “real-time customer” would hide the discovery gap. The appropriate next question is whether another authorized source exposes the needed instructions sooner, or whether the user’s deadline can change. Receiving an instruction record sooner would still not prove that the payment settled.

Notice what these segments do not prescribe. They do not yet choose an API, file-transfer mechanism, or streaming architecture. They describe constraints sufficiently well to make those later choices informed. Nor should the example row counts become product-wide cutoffs; validate boundaries against actual customer distributions, processing behavior, and the differences they create in setup or support.

In discovery, capture the four dimensions in a consistent short profile and mark each claim as confirmed, estimated, or unknown. For example:

• Source: name the system and the specific export, table, file, or feed containing the needed dataset; identify who has verified it.
• Volume: request a recent typical period, a peak period, and any onboarding backfill. State the unit—entries, account rows, files, or bytes.
• Freshness: ask the end user what decision the data supports and the latest usable time; separately record when the source actually publishes it.
• Capability: verify permissions, available extraction options, an implementer and ongoing administrator, and any required data-owner or risk approval.

An unknown is a discovery task, not evidence that a prospect fits the easiest segment. If several prospects share the same source constraints, peak pattern, deadline, and setup capacity, they may form a repeatable target segment. If they merely share an industry label, they may not.

Key takeaways

Segment the customer–dataset–use-case combination by its source system, typical and peak volume, deadline for usable data, and verified integration capability. Keep source availability distinct from desired freshness, and technical features distinct from permission and operating capacity. The result should explain where onboarding can be repeatable and where a constraint needs further investigation—not prematurely dictate a connector.

Next, you will turn a downstream fintech use case into explicit requirements for freshness, completeness, accuracy, and traceability. The freshness needs and source limits recorded here will give those requirements a concrete starting point.