Every enterprise sits on a pile of uncategorized text — ticket queues, contract terms, survey comments, and call transcripts to name a few. Reading through these by hand tops out at a few hundred rows, and a keyword filter misses the ticket that says the invoice math seems off instead of billing error.

A support queue that doubles in a quarter forces the question. A director asks for a breakdown by root cause, like billing confusion, shipping delays, or an integration bug that keeps showing up under different descriptions. Those categories live only as sentences buried in ticket bodies, so someone has to read enough of them to find the categories before anyone can start counting.

That work has a name: text analysis. There are three real ways to do it:

- Write custom code

- Buy a dedicated tool

- Add text mining to the workflow platform already handling everything else

The stakes are larger than one support queue, too. Unstructured sources like these make up an estimated 70% to 90% of the data organizations hold, according to Gartner analysts speaking at the Data & Analytics Summit in London this year. Most of what a company knows about its customers, contracts, and operations lives in exactly this kind of free text.

The decision to build, buy, or embed

Each path has its own pros and cons to consider:

- Build it. Hand the problem to a data scientist, or become one temporarily, and write code against an open-source NLP library. It’s flexible and tailored to the data at hand — right up until the person who wrote it moves to another team and the model becomes a file nobody can safely touch. This path also assumes a data scientist is available to hand the problem to, which is a bigger assumption than it sounds. In the World Economic Forum’s 2025 Future of Jobs Report, 63% of employers named skills gaps as the single biggest barrier to getting more value out of their data and AI investments. A specialized NLP hire is often the bottleneck a team is stuck waiting on.

- Buy a point solution. License a dedicated sentiment or text-analytics tool. It performs well on the use case it was built for, but it lives outside the rest of the analytic workflow. The categorized output has to be exported, re-joined, and re-explained to whoever owns the report downstream — a manual hop that gets rebuilt every cycle.

- Embed it. Run text mining as a step inside the same platform that already handles the blending, joins, and reporting, so a sentiment score or topic label becomes just another column feeding the same report as everything else.

All options carry tradeoffs, and the evidence on the build path is particularly discouraging. A widely reported MIT-affiliated study on enterprise AI deployment found that only a small share of custom-built enterprise AI tools ever reach production, largely because they’re built to impress in a demo rather than to keep running, unattended inside a workflow that absorbs staff turnover.

Test the approach with five criteria

Before comparing platforms, it helps to be explicit about what “good” looks like, regardless of which path a team takes:

- Accuracy on the language your team uses: Internal shorthand, industry jargon, and typos behave differently than the clean review text most product demos use.

- Repeatability without a standing request to the data team: Next quarter’s batch of tickets, comments, or contracts needs consistent, scheduled treatment without reopening a project.

- An audit trail: Someone will eventually ask how a sentiment score or topic label got assigned. “A model someone built two years ago” isn’t an answer IT or compliance can work with.

- Integration with the rest of the analytic workflow: A category label that lives in a separate export is a manual task away from the report it’s supposed to feed.

- A cost and tier fit that matches how the team already buys software: A specialized point tool is another line item, another vendor, and another login to provision and de-provision to handle.

Comparing the three paths against those bars

The three approaches trade capability for control in different places.

The table points to a single deciding factor: which approach is still running unsupervised, after the person who set it up has moved on to something else.

Inside a support ticket queue: pre-processing, sentiment, and topic detection

Picture the support team from the opening example, now trying to work through a backlog of open-ended ticket text without adding headcount. A workflow-embedded approach breaks the problem into steps an analyst can build and rerun without help:

First, raw ticket text gets tokenized and cleaned using a Text Pre-processing step that strips filler words and standardizes formatting. One detail worth knowing is that product documentation for this tool specifically warns against running it immediately upstream of sentiment scoring, since the cleanup step strips some of the exact words a sentiment model relies on to detect tone. The two tools solve different problems and, in this case, work best kept apart.

Sentiment scoring runs on the raw ticket text instead, using Sentiment Analysis to flag which tickets read as frustrated rather than merely descriptive — useful for triage, with the honest caveat that the tool currently analyzes English text only.

Meanwhile, Zero-shot Text Classification sorts tickets into categories the analyst defines on the spot — billing confusion, shipping delay, the recurring integration bug — without first collecting and labeling a training set. That’s the detail that matters most for a senior analyst without a dedicated data science team on call. There’s no model-training step standing between the question and the answer.

A Topic Modeling pass across the same batch catches something the predefined categories can’t — clusters of language nobody thought to name yet, including the complaint that hasn’t made it onto anyone’s list.

With an embedded approach inside Alteryx One Designer, text mining tools run as part of Alteryx Intelligence Suite as each step above produces a new column sitting next to the rest of the ticket data, ready to feed the same report that already tracks volume and resolution time. There’s no export, no manual rejoin, and no separate deliverable to remember to update.

Where the approach runs out of room

Someone mentions that a third of the support inbox comes in through the German site. The phrase “analyzes English text only,” easy to skim past in a tool’s documentation, now sets the actual scope of what this rollout covers this quarter. In Alteryx, Text Pre-processing, Text Classification, and Topic Modeling extend to French, German, Italian, Portuguese, and Spanish.

A team in this spot has three real options: cover categorization and topics everywhere and sentiment only where English applies, hold the German queue for a later phase, or route sentiment scoring for that language through a different process entirely. Each is a workable tradeoff, the kind that surfaces once a rollout touches real data instead of a demo.

A team asking for something else entirely — a model fine-tuned on millions of internal documents to make one narrow, high-stakes call — is solving a different problem than the one this covers. No amount of workflow tooling substitutes for a dedicated machine learning effort when that’s genuinely the ask. Most ticket queues, contract folders, and survey exports are recurring, moderate-scale problems that show up every quarter and need consistent treatment.

Start this week, not next quarter

Pull last week’s actual ticket export, run it through the steps above, and see what the categories look like by Friday — before the next quarter’s backlog makes the decision for you. Start a free 30-day trial of Alteryx One to try it against your own queue.