A customer-support dashboard may need to answer a simpler question than a generative chatbot: what topics are people complaining about, which products are mentioned, and which comments express frustration? Those are text-analysis tasks. A large language model can discuss them conversationally, but a dedicated language-analysis capability may produce more consistent structured signals for a dashboard. Building a small application around that distinction is one of the practical steps covered by the current Azure AI Fundamentals syllabus.
A retailer can triage service comments by extracting product names, key topics and sentiment without generating a new free-form answer for every message. The useful output is a structured signal that reviewers can inspect and correct. Microsoft AI-901 includes keyword extraction, entity detection, sentiment, summarization and a lightweight text-analysis app. Developers should evaluate these transformations separately and never treat a sentiment label as an authorized decision about a person.
Decide what each signal will actually support
Imagine a retail team analyzing several hundred short support comments each day. It wants to identify recurring product issues, route urgent complaints for review and observe whether a shipping-policy change improves customer experience. Key phrase extraction can surface common concepts; entity recognition can identify products or locations when the supported feature is appropriate; sentiment can provide an imperfect directional signal. None of these outputs, alone, should decide whether a refund is approved or a customer is telling the truth.
Write a data contract: each input has a record identifier, permitted language, submission time and text, and each result has a feature name, extracted values and analysis status. Keep the original text accessible to appropriately authorized reviewers, because a phrase such as ‘the battery is not bad’ can confuse a system that relies on polarity without context. Distinguish AI workloads and models at the data-contract level; an application contract preserves that distinction when the output reaches a dashboard.
Key phrases are topics, not facts about root causes
Key phrase extraction looks for salient topics or concepts within text. From a complaint about a damaged power adapter and a delayed replacement, it may identify ‘power adapter’ and ‘replacement delivery’. That helps an analyst cluster complaints but does not prove the adapter was manufactured incorrectly. The source may describe a customer misunderstanding, a logistics issue or a genuinely defective part. A dashboard should allow analysts to open representative underlying messages before declaring an operational cause.
Test short messages, mixed topics and negation. A one-word response may yield little useful context; a long message about two orders may return overlapping phrases. When the application counts key phrases, normalize obvious formatting variations while preserving the original service response. Otherwise ‘power-adapter’ and ‘power adapter’ may be counted as unrelated incidents. The right normalization rules depend on the business vocabulary, not solely on the NLP service.
Entities identify references, not authorization
Named entity recognition can identify mentions of people, organizations, places and other supported categories. That can help sort comments by referenced store or product family where categories and custom vocabulary are appropriate. But detecting a person’s name does not entitle the application to find that person’s private record. Text analytics answers what appears in the text; business authorization answers what the caller may do with the underlying data.
If the team analyzes support messages containing personal information, remove unnecessary identifiers before sharing results widely. Restrict access to original messages and evaluate whether the NLP outputs themselves reveal private facts. An extracted patient name or account number can be sensitive even if it is returned as a compact field. Responsible AI must govern retention, consent and exposure of extracted content before any feature reaches customers.
Sentiment can guide a queue but should not control the person
Sentiment analysis generally estimates whether the language expresses a positive, negative or neutral attitude, often with confidence-related output depending on the supported service. For example, ‘I love the design, but this is the third replacement’ contains positive and negative aspects. A single overall score may hide the issue the team must resolve. Opinion-related features can help identify what people like or dislike, but they remain estimates of language, not measurements of customer intent or character.
Route urgent messages based on explicit operational rules as well as any sentiment signal. ‘My account is locked before travel’ may require rapid service regardless of its polite tone. Conversely, a strongly negative review does not automatically indicate fraud or abuse. Treat sentiment as a triage aid and monitor cases where its interpretation is clearly wrong. That produces a much fairer workflow than using an opaque negative score to restrict customer choices.
Summarization solves a different problem
Summarization turns longer text or conversations into a concise representation. Extractive methods preserve original sentences; abstractive approaches produce newly worded text that attempts to retain meaning. Both can omit a qualification. For an internal case summary, a useful test set includes messages with a disputed refund, a time-limited exception, and an explicit statement that no action has yet been taken. Losing any of those conditions makes the summary operationally misleading.
Do not assume summarization output is equivalent to structured extraction. A summary such as ‘customer reports a delivery issue’ may be useful for an agent’s handoff, but an application that needs the exact order number should validate an extracted field separately. A generation model may help explain the narrative; deterministic code can verify a format or compare the field with a trusted database. Good system design gives each technique work it can handle reliably.
Connect a lightweight text client securely
A minimal application should load its permitted resource configuration, obtain credentials using a supported authentication path, send text with a declared language when required, and parse the returned feature-specific fields. Microsoft Azure Language in Foundry Tools exposes text-analysis capabilities through APIs and SDKs. The exact package and parameter names depend on service version; use the current vendor quickstart instead of constructing a guessed endpoint or embedding a key into browser-side JavaScript.
Handle the results as structured data. A single failed record should not silently disappear from a daily report, and an unsupported language should be surfaced as a known limitation. Use a record identifier to correlate the original message, service result and later analyst correction. Basic operational logs should include result status and timing, not full customer messages by default. These conventions make a beginner application inspectable without adding a heavyweight architecture.
Test the transformations before testing a dashboard
Prepare ten or twenty representative messages with expected interpretation notes. Include one sarcastic review, a polite urgent request, a mixed-sentiment comment, several languages and a message containing personal data. Ask whether the extracted phrases represent the issue, whether entity categories are useful and whether the sentiment signal is too confident about ambiguous wording. Compare these against the original text, not just the output displayed in a graph.
Aggregate only after the record-level tests pass. Counting model-estimated sentiments across a large dataset can make a dashboard look statistically convincing even when the tool systematically misreads a customer group or a product category. Sampling analyst corrections and measuring errors by language or message type make the numbers more trustworthy. Use Responsible AI test cases to test whether those errors fall disproportionately on particular language or message categories.
Run a small field-level interpretation review
Construct a test table with a dozen synthetic support comments, each annotated by a human reviewer for expected product references, key themes and urgency. Include messages such as ‘Delivery is late but your staff were excellent’ and ‘The replacement arrived; unfortunately it is also defective.’ The expected result is not a single positive or negative label in every case. Ask reviewers to record which phrase carries the complaint, where the message contains two opinions and whether the model missed a negation. This produces much more useful evidence than checking if the API returns a sentiment field.
Compare the language service’s structured results with reviewer annotations. The team might discover that a particular product abbreviation is missed while broad sentiment remains usable. That suggests improving domain vocabulary or downstream normalization rather than replacing the entire application with an unconstrained generative prompt. Record unresolved cases, feature versions and any changes made to post-processing. If a later update improves product recognition but worsens urgent-case routing, the system should be able to detect and discuss that tradeoff.
Choose analysis and generation deliberately
A user who asks ‘which products appear most often in complaints?’ usually needs stable categorization and counting, not a model’s free-form guess about the dataset. A user who asks ‘help me write a diplomatic response to these complaints’ needs generative language. A user who asks ‘what is the exact customer refund status?’ needs a trusted transaction lookup. These three questions may appear in the same application but should not be answered by the same uncontrolled prompt.
The main AI-901 lesson is to work backward from the information that must be returned. Labeling entities, estimating sentiment, extracting key phrases and generating a summary are different transformations. A modest text-analysis client should make each transformation and its limitations visible, secure the input, preserve a route for review and produce outputs that downstream systems can use without pretending every linguistic inference is a proven business fact.