AI Customer Segmentation

AI customer segmentation groups customer records according to defined characteristics, with model assistance for interpreting relevant text. Define non-sensitive segment rules first, apply them to supplied records, and keep ambiguous or incomplete customers visibly unassigned.

This guide produces a reviewed membership table and reconciled segment counts. A model can propose an interpretation; the written rule and the source record determine whether that interpretation is accepted.

By Ai Flowi · Published 10 October 2026

example configuration, not a recorded test
documented in the catalogue; not production-tested by Ai Flowi

1. Write segments around a useful business question

Choose a question that the available records can answer, such as which customers have requested onboarding help or which supplied account types need a different review checklist. Make the outcome concrete: a segment should correspond to a review process or approved content category. A descriptive cluster without a clear purpose may not justify a workflow.

For this example, each record gets one primary segment. Define precedence if multiple rules match, and use unassigned when no rule applies or required evidence is missing. Multi-label segmentation is also possible as a policy choice, but its counts describe memberships rather than distinct customers; do not mix those definitions in one report.

2. Establish authorised fields and definitions

Prepare a customer snapshot approved for segmentation, a workspace, a stable customer identifier and a versioned rule set. Limit attributes to relevant, non-sensitive business information supplied for this purpose. Do not infer protected characteristics, personal wealth or private circumstances from names, writing style or location.

Define every segment using fields that exist in the dataset. Include rule identifiers, accepted values, exclusions and evidence requirements. Missing values should be distinguishable from negative answers. When a rule relies on free-text requirements, specify what wording qualifies and which expressions are too vague to classify confidently.

For interpreting customer notes, configure your provider account and API key via the connection reference; interpretation usage is charged separately by that provider. Exact categories already present in structured fields can be assigned with ordinary rules. Consult the catalogue to verify the inputs selected for this membership policy.

3. Prepare a canonical segmentation dataset

Check the loaded customer snapshot against its membership contract using the JSON validation procedure.

For a synthetic exclusive segmentation policy, define needs setup help and needs scope clarification, with scope clarification taking precedence. A customer note requesting setup while asking whether an extra requirement is included matches both purposes. Assign the primary membership to scope clarification, retain the setup request as supporting context, and record the precedence rule. A second customer whose note simply says hello remains unassigned. That outcome answers a workload question without treating vague text as evidence of a buying preference.

Resolve duplicate customer identifiers before counting. Two rows for the same customer may represent separate observations rather than separate customers. Record the reconciliation policy and retain excluded rows in an exception list. Do not let a deduplication step silently select whichever observation happens to appear first.

Check field types before rule application. A string category and a free-text note can look similar in a table while carrying different meaning. Keep segment definitions separate from imported records, and reject unexpected rule identifiers so a source field cannot silently redefine your policy.

4. Use a model only for ambiguous text

Optional note interpretation starts from the prepared customer list: Data → DataFrame supplies a Table to aMap at source. Define the proposed membership and evidence columns in aMap’s required schema table editor. The configured Language Model provides the interpreter through aMap’s model input; the customer identifier remains part of the supplied record.

Use instructions to restrict proposals to the rule vocabulary, require a supporting excerpt and mark inadequate evidence unresolved. Preserve source columns by enabling append_to_input_columns. Check returned fields and customer identity with a synthetic membership case before including those proposals in a count report.

The model’s proposal is an additional field, not a replacement for the original customer information. A reviewer must verify that the quoted evidence actually supports the proposed rule. If a model rewrites a customer identifier or omits a row, stop reconciliation and fix the mapping before counting.

5. Assign membership using explicit rules

For the data-only path, apply the written segment rules in JSON Operations. For the assisted path, review aMap’s proposed interpretations first, then submit the accepted record list to the same rule evaluation. Preserve the applied rule version, matched rule identifier, final segment, evidence reference and unassigned reason.

Table Operations can provide a membership view using "Filter" or "Select Columns". Supply the membership Table at df; column_name identifies its segment field. Choose the membership comparison with filter_operator, then put the sought segment value in filter_value. These views help inspect assignments; they do not establish an aggregation operation.

Calculate counts from the canonical JSON membership list with a separately checked JSON Operations query. The proposed procedure groups accepted records by final segment and counts entries in each group, including unassigned. For this exclusive policy, the segment counts must sum to the number of accepted unique customers. Report rejected or unresolved duplicate records separately from that denominator.

6. Publish an interpretable segment report

The desired output contains a membership row for each accepted customer and a segment-count summary with its population definition. Add the rule version, snapshot scope, source references and reasons for unassigned cases. The report should explain membership, rather than presenting a segment name as an unexplained prediction.

Test records that match two rules, match none, lack required attributes, repeat an identifier or contain instructions inside a note. Check that precedence is explicit, unassigned remains visible and the count reconciliation holds. An empty dataset should produce an empty membership list without inventing an audience profile to fill the report.

Separate a rule revision from a change in customer behavior. If scope clarification becomes the primary segment under a new precedence policy, a customer can move segments even though their supplied note is unchanged. A comparison report should identify that policy change before describing any membership movement. Likewise, adding previously excluded records changes the population: reconcile the revised denominator and preserve the former snapshot. Segment counts are interpretable only when the reader can tell whether the rules, source coverage or customer evidence changed.

When is customer segmentation unnecessary?

This proposal does not discover new customer facts, predict purchases or send a campaign. It differs from sentiment classification because its segments follow stated business rules and authorised attributes. If your source system already holds the required categories, a filtered export may be enough.

A segment is not permission to contact a person. Treat qualification and nurturing draft preparation as separate decisions with their own review criteria. Re-run the segmentation review when rules or source fields change; old membership counts describe the old snapshot.

Customer membership rules and selected inputs

Usage for ai customer segmentation

Plans: Go from USD8/month billed yearly (USD10 monthly), Plus from USD16 (USD20 monthly), Pro 100 from USD80 (USD100 monthly), Pro 200 from USD160 (USD200 monthly) and Pro 500 from USD400 (USD500 monthly), with 5,000 to 250,000 Flowi Tokens/month and top-ups; 1 token per node run; third-party API and model usage is not included.

Related reading for ai customer segmentation

• Documented use cases
• Component catalogue
• AI Lead Qualification
• Sales Pipeline Analysis