Generative AI in SaaS: use cases that improve the product experience, with examples

SaaS companies use generative AI in seven recurring product patterns: drafting content a person accepts, summarizing material, answering questions from the product's own content, turning a description into a working object, suggesting decisions with reasons, checking work and flagging problems, and acting on the user's behalf. The experience improves when each pattern gets the control its risk requires.

Last reviewed: September 28, 2026

Lists of "AI use cases" usually sort by department: marketing, support, analytics. That tells a product leader what other companies bought. It does not tell them what to build. The useful unit is the product pattern, because two features in different departments can share the same risk, and two features that look alike can need very different controls.

How are SaaS companies using generative AI to improve user experience?

The seven patterns below run roughly from least to most authority. The public examples are described from each vendor's own documentation, which tells you how the feature is designed, not how well it performs. Where Tcules has published work on a pattern, the case is named.

Most mature products combine several patterns in one surface. The distinction still matters, because each pattern fails differently and needs to be tested differently.

1. Draft something a person accepts and owns

This is the most common pattern and the best studied. In a study of 5,172 customer support agents, access to a generative AI assistant that suggested responses raised issues resolved per hour by about 15% on average, with the gains concentrated among less experienced agents (Brynjolfsson, Li and Raymond, Quarterly Journal of Economics, 2025; the earlier working paper reported 14%). The finding is about a person using suggestions, not about suggestions replacing the person.

The design risk is that a draft quietly becomes the final version. Tcules saw this at Omny AI, which generates product benefits and use cases for Amazon sellers. The original design filled the content area with suggestions before the user did anything, and Omny's team described users holding Omny accountable for suggestions they had not properly reviewed. Tcules redesigned it so the content area starts empty, suggestions sit in their own panel and adding one takes a deliberate click. Purple marks anything the AI generated; blue marks anything a person typed, chose or overrode. Omny reported that users became more aware of how they were using the AI and more forgiving when a suggestion was wrong; that is a qualitative client report, not a measured change.

Decide before building: who is accountable for the draft once it is accepted, and whether accepting takes at least as much effort as reading.

2. Summarize material the user already has

Meeting recaps, thread digests, document summaries and ticket histories all transform material the user supplied. The source exists, so the risk is not invention from nothing. It is omission and changed meaning.

The key design decision is distribution. Zoom's AI Companion, for example, lets participants receive a meeting summary automatically if the host chose to share it, and only the host can edit the summary. That is a reasonable default for a low-stakes recap. For a summary that becomes a record, such as a customer call note or an incident timeline, a product team should ask whether anyone reads it before others rely on it.

Decide before building: where a reader can jump from a summary line to the passage behind it, and whether the summary is shared before or after a person checks it.

3. Answer questions from the product's own content (AI search)

This is the pattern behind most "AI search" in SaaS: the system retrieves passages from the customer's workspace, help center or records and writes an answer from them.

Two public examples show the controls that matter. Notion's Enterprise Search says it will always cite its sources when it answers from the workspace or a connected app, and its security documentation says permissions are checked at query time, not only when content is indexed. Intercom describes Fin as a retrieval system with models to retrieve and rerank content and to summarize the customer's issue, plus a model that detects when to escalate to a human; teams can restrict which content Fin uses and target it by audience.

Search is also an entry point, not only an answer box. In the Eden AI case, Tcules redesigned a workflow builder's three starting paths (find a template, ask AI for help, start from scratch) around one adaptive search surface. Preview cards and direct documentation access let people inspect a capability before adding it, and the chosen entry continued into the builder rather than into a separate product.

A fluent answer can hide a missing source. Evaluate retrieval separately from the written answer, and design the state where the system found nothing usable. The AI Search and Recommendation service covers this layer in detail.

Decide before building: which sources are eligible for which user, how a person checks a claim against its passage, and what the product says when it has no good answer.

4. Turn a description into a working object

Here the user describes an intent in plain language and the product produces a structured object: a workflow, a report query, a form, a configuration. The output is not prose. It is something that will run.

Zapier Copilot is a clear public example. A user describes an automation, and Copilot generates a basic outline of a trigger and actions. Copilot fills in apps, existing account connections and field values, and lists anything it cannot do; the user completes those items and clicks Publish. Generation shortens the blank page; the person keeps the switch.

At Eden AI, the same idea appeared as a mode inside search. The recorded design used the Tab key to move from search into AI assistance, so search and AI stayed close without pretending to be the same operation.

Decide before building: whether the generated object is shown in the product's normal editor (so users can inspect it the usual way) and what testing happens before it goes live.

5. Suggest a decision and show the reason

Recommendation patterns rank, route or propose: which team should own this ticket, which template fits, which account needs attention. The risk is invisible optimization, where the system is optimizing something the user cannot see.

Linear's Triage Intelligence proposes teams, projects, assignees and labels, and flags likely duplicates. Users can accept or decline a suggestion or view why it was made. Each team can choose whether suggestions for each property are shown, hidden or auto-applied. That last control is the useful idea for a product leader: authority is a setting the customer adjusts per property, not a single product-wide decision.

Decide before building: what the recommendation is optimizing, what reason the user can see, and who can turn a suggestion into an automatic action.

6. Check work and flag problems with evidence

In this pattern the AI reviews something a person made: a drawing, a contract, a code change, a data set. The output is a finding, and the user has to decide whether to believe it.

At BuildTwin, AI quality checks ran on structural-engineering drawings, and a quality engineer still had to defend each judgment before approval. The earlier review surface showed status without the evidence a reviewer needed. Tcules turned the result list into a review workspace: each result links to its drawing reference, source document, observation and conclusion; a check that could not run says what information is missing; and a correction needs both a new state and a reason, with the original AI result kept visible. A stakeholder described the adoption risk directly: at the start, users won't trust it. The design answer was to make confidence reviewable, not to make the system sound more certain.

Decide before building: what an expert must see to accept or reject a finding, and whether overrides become data your team can learn from.

7. Act on the user's behalf

Agents change records, send messages, run workflows or ship code. This pattern carries the most value and the most consequence, so it needs the tightest boundary.

GitHub's documentation for its Copilot cloud agent is a useful model of that boundary. According to its risks and mitigations page, the agent can push only to a single branch, its draft pull requests must be reviewed and merged by a human, the person who asked for the change cannot approve it, and workflows do not run until someone with write access approves them. Only users with write access can trigger it. Each rule answers a specific question: what can it touch, who checks it, and who is prevented from checking their own request.

Decide before building: the resources the agent may change, the confirmation point, the activity record, the stop condition and who owns recovery. Tcules covers these controls with examples in AI trust, control and human review.

Where does generative AI belong in your product?

Start from the work, not the model. The strongest evidence for caution comes from a 2023 field experiment with 758 Boston Consulting Group consultants using GPT-4. On tasks inside the model's capability, consultants completed more tasks, faster and at higher quality; on a task designed to fall outside it, those using AI were 19 percentage points less likely to reach a correct answer (Dell'Acqua et al., "Navigating the Jagged Technological Frontier"). The models have changed since, so the specific numbers are dated. The lesson is not: the boundary between tasks AI helps and tasks it harms is uneven, hard to see in advance and easy to miss when the output reads well.

A practical checklist for choosing where to put generative AI:

• Name the user's work state. Finding, drafting, deciding, checking or doing. Each maps to a pattern above.
• Pick the narrowest pattern that creates value. A draft is cheaper to get wrong than an action.
• Test on real tasks from your product, including hard and unusual ones, before committing to a pattern.
• Design three states for each feature: useful output, partial or uncertain output, and no usable output. Say what the user can do in each.
• Separate machine work from human work visibly, as Omny did with color and BuildTwin did with kept overrides.
• Earn wider authority with evidence. Move from suggest to auto-apply only when the record shows it is safe for that property, as Linear's per-property setting allows.
• Keep a non-AI path for users and tasks where the feature does not help.

These echo long-standing guidance. Microsoft's Guidelines for Human-AI Interaction, tested by 49 design practitioners against 20 AI products, include "make clear how well the system can do what it can do," "support efficient correction" and "make clear why the system did what it did."

How should a product team measure an AI feature?

Usage alone rewards the wrong thing. A feature that people accept without reading scores well on adoption and badly on outcomes, which is the problem Omny had before the redesign.

Vendor metrics need the same care. Intercom counts a Fin resolution when, after Fin's last answer, the customer either confirms it helped or leaves without asking for further help, the latter counted as an "assumed resolution." That is a sensible billing definition. It is not the same as a solved problem, so a product team should also track whether the customer came back.

Where this work sits

Choosing the pattern, then designing its authority, evidence, correction and recovery, is the work of AI Product UX at Tcules. For patterns in commerce, see generative AI in ecommerce.

An earlier, department-by-department take on this topic is available as a video: 7 Gen AI Use Cases Transforming SaaS.