IBM Palette and the AI sales deck: what makes a file ready for a customer?

A small team can generate a polished sales presentation and still send a customer the wrong promise. A pilot becomes a launch date. A blank cell becomes an invented result. A layout repair hides the qualification that made a claim true.

On November 3, IBM Research published Palette, an approach to generating presentations in a particular design language. That makes a practical question timely for founders building AI document features: what must happen between generating a deck and letting someone send it?

The useful product boundary is the customer-ready file, including its facts, brand choices, readability, and delivery format. A successful generation is only one input to that decision. This article offers a fictional sales scenario, a reusable review sheet, and a way to compare automated drafting against the team's existing workflow. It is for nontechnical founders and small product teams evaluating a presentation feature, rather than a guide to training a model.

We have not run Palette, reproduced its evaluation, or tested a customer deployment. Published results below belong to their authors. The examples and proposed checks are our own; they show how to evaluate a product promise without claiming that a particular implementation passes.

1. What Palette changes, and what it leaves unproven

IBM's November 3 account describes a 20B model adapted to IBM's design language. A planning role produces a structured brief; a coding role builds individual slides. A surrounding checking system renders output, detects layout problems, and conditionally retains repairs.

IBM reports a three-domain PresentBench mean of 59.7, behind NotebookLM's 60.8. The article also says that the benchmark does not measure adherence to a particular design language. Adapting existing customer templates from one or two files is described as future exploration. These are publisher-reported findings, not evidence that another startup's template already works.

For a founder, the immediate implication is a change in what to request from a prototype. Ask to inspect the intermediate brief and the delivered file, with evidence connecting the two. A striking sample alone cannot show whether the system preserves your product's limits or your customer's template.

Here, a brief means the intended content and visual decisions before slides are drawn. A harness means the surrounding software that runs checks and manages revisions. Brand fidelity means compliance with an explicitly agreed design system, rather than a subjective impression that a deck looks professional. Content fidelity means preserving the source's meaning and qualifications. These last two can fail independently.

Owning a model also creates operational work. Before treating ownership as a procurement advantage, ask who maintains the deployment, supports failed exports, approves data handling, and updates the checking process. This article establishes no access, licensing, hardware, or total-cost guarantee for Palette. Verify those particulars before committing to a pilot. There is enough evidence to investigate the workflow, but an investigation should have a narrower promise than an unattended customer presentation service.

2. Read the benchmark as a map of questions

The PresentBench paper, submitted in March 2026, describes 238 evaluation instances and an average of 54.1 manually designed binary checklist items per instance. That is useful background: the work treats presentation quality as many specific questions tied to a particular task, rather than one universal beauty score.

The implication for your product is to write task-specific checks before comparing outputs. A renewal deck needs the correct contract period and an unmistakable renewal request. A product demo needs an accurate distinction between shipped functionality and a concept. An onboarding presentation needs steps a new user can actually follow. A generic question such as “Does this look good?” cannot substitute for any of these.

The official evaluation repository accepts generated slides as PDF and organizes evaluation around the source material and instructions. A PDF-oriented evaluation does not by itself establish whether an editable PowerPoint preserves text, shapes, or behavior in your customer's environment. Treat benchmark scores as a reason to inspect relevant tasks, then test the deliverable you sell.

Avoid converting a reported average into a probability that a customer's deck will be acceptable. A score on a rubric is not a measured approval rate for your audience. A narrow domain selection is also different from the full range of your incoming work. Record which task types resemble the evaluation and which do not.

A useful procurement question is: “Which of our required checks could this evaluation miss?” Have the supplier demonstrate one failure, its detection, and the resulting user experience. A failed export that stays visibly pending is less damaging than a clean preview that encourages a user to send a misleading file. You are choosing a workflow with a failure policy, not simply choosing the highest number.

3. Turn your brand into decisions a reviewer can verify

“Use our brand” is an ambiguous instruction. It could mean matching a cover, using an approved type family, following a grid, or maintaining a recognizable narrative voice. If the founder and designer disagree about the requirement, a model cannot resolve that disagreement reliably on their behalf.

IBM's own design documentation illustrates how concrete a design language can be. Its color guidance specifies palettes and how colors serve a visual hierarchy. Its 2x Grid describes a framework for organizing space. Its typeface guidance defines the typography of that system. These are examples of documented choices, not instructions to copy IBM's identity into your product.

For your pilot, ask a designer to supply a small approved reference pack: a cover, a dense information slide, a chart, and a closing request. Alongside it, write down what may vary. Perhaps an accent color is optional, but the status label for a roadmap item is mandatory. A compact layout may change; an attribution may not disappear.

Give reviewers a way to mark acceptable variation, brand mismatch, and content failure separately. A different spacing choice may be acceptable. An unauthorized partner logo is a brand and permission issue. A correct color palette around an unsupported customer claim is a content failure. Do not let visual consistency compensate for factual errors in an average score.

Make exceptions explicit for Chinese or other target-language decks. A type family approved for an English specimen does not establish that the Chinese version renders correctly. Ask for an approved fallback and review actual line breaks in the delivery environment. Do not merely shrink text until it fits. If the content needs another slide, that is a legitimate editorial decision requiring a second look at sequence and context.

Freeze the reference pack during a comparison. Otherwise a changing brand brief can make successive outputs appear better or worse for reasons unrelated to the generation system.

4. A fictional pilot deck that looks finished too early

Consider a fictional startup, Harbor, building an AI intake assistant for service businesses. Harbor wants a short presentation for a prospective customer. The input notes say that the assistant prepares draft responses, a staff member approves them, and a calendar connection is planned. The customer has asked whether it can change appointments automatically.

The source contains no validated response-time result, no customer logo permission, and no committed calendar launch date. Those absences are part of the assignment. A good deck can explain the present workflow and identify open questions without filling the gaps with plausible achievements.

In the first imagined output, the title is “Automate every appointment.” A roadmap slide places the calendar connection in the current quarter. Another slide displays a smooth improvement chart without a source. All text fits. The slides share a color palette. A geometry checker could report no overlap and still miss the central problem: Harbor is promising a different product.

The reviewer should mark the claims against the input, not ask whether they sound realistic. Replace the title with a description of draft preparation and staff approval. Move the calendar connection into a clearly labeled discussion of planned work without inventing a delivery date. Remove the performance chart; use a simple workflow illustration that makes no unmeasured performance claim.

Now imagine a second output. Its claims are accurate, but a repair moves “staff approval required” into tiny footer text. The words survive, yet a customer reading only the headline and main diagram could reasonably misunderstand who acts. The check needs to cover meaning in context, including the prominence of a restriction, not just string presence.

A third output preserves that restriction and the source boundaries. It is a candidate for delivery review, not proof of customer understanding. Ask someone unfamiliar with Harbor to explain what the product does today, what requires approval, and what remains planned. Record their answer before offering hints. This is a proposed test, not a report of a study we conducted.

5. Use a customer-readiness sheet with separate owners

Copy the following sheet into your product review. Each row needs a named owner and evidence from the exact version being considered. “Not checked” remains an unresolved condition. For a genuinely irrelevant row, record why it is outside the promised scope rather than silently treating it as passed.

This is our proposed worksheet, not a validated scoring system or a description of Palette's controls. Small teams may assign several roles to one person, but should avoid allowing an automated layout score to stand in for that person's factual approval.

For Harbor, the unsupported improvement chart blocks delivery even if all other rows pass. An unresolved spacing preference may justify a minor revision without changing the claim review. The distinction stops a team from spending an hour on a cover while overlooking an incorrect promise.

Keep the worksheet proportional to the feature. An internal outline tool does not need to promise a finished client file. If your interface offers “Send to customer,” however, the final authorization row becomes part of the workflow you are selling. Connect that button to a specific approved artifact. If the file or its approved source changes afterward, show that it needs review again; an approval attached only to a conversation is too easy to misapply.

6. Define improvement before allowing automatic repairs

A repair system needs a clear answer to “better according to which checks?” A layout measurement can improve while meaning, readability, or editability deteriorates. For your product, a lower overlap count should therefore be evidence about layout, with other checks retaining their own authority.

Suppose Harbor's feature comparison slide has overlapping text. A repair can remove the overlap by shortening “Draft only; staff approval required” to “Automatic responses.” It can also remove the overlap by shrinking every label beyond comfortable reading size. Neither is an acceptable repair under Harbor's assignment. A third option adds space and preserves the qualification; that option still needs inspection in the output file.

Write down content that a repair may not silently change: product status, dates, prices, quantities, units, citations, restrictions, and the requested customer action. Your implementation partner should explain how changes to those fields are surfaced for approval. This is a product requirement, not a claim that checking literal words proves semantic equivalence.

Also consider contradictions introduced across slides. One slide might correctly say that staff approve drafts while the closing slide promises unattended operation. Checking each slide independently will not settle the deck-level promise. Have the content owner read the sequence with the closing request in view.

Set a bounded repair policy. After the allowed attempts, the user should get a useful draft with a visible issue, a manual editing route, or a clear failure. Choose the bound for your latency budget and support capacity; there is no universal number supported by this article. Keep an original version so that a rejected revision does not destroy useful work.

For evaluation, retain before-and-after pairs, including rejected changes. A gallery containing only successful repairs cannot reveal the frequency or seriousness of regressions. Label failures by their consequence: cosmetic inconvenience, unreadable information, false claim, or delivery failure. Those labels help a founder decide which problems can remain in a limited pilot and which require stopping external use.

7. Inspect the file your customer will actually use

A preview is a view of one rendering path. A customer may download a PowerPoint file, open it in another application, edit a number, or forward a PDF. Decide which of those paths your product supports, then inspect them explicitly.

The PptxGenJS saving documentation describes file generation and several output formats. Completion of that operation establishes that a file was produced. It does not establish that a recipient can use the presentation as intended. Keep “export completed” and “delivery checked” as distinct statuses in a prototype.

For Harbor, the delivery reviewer opens the exported file in the customer's agreed application and checks the same restriction, roadmap label, and chart sources that were reviewed in the preview. They then make one ordinary edit, such as replacing the customer name, and confirm that the slide still communicates the same promise. If PDF is the only supported delivery format, say so plainly rather than implying full editability.

Accessibility belongs in this review. Microsoft's PowerPoint guidance covers reading order, alternative text, contrast, meaningful links, and using more than color alone to convey meaning. A rendered image cannot establish that the underlying objects have a sensible reading order. Use the relevant application checks and inspect the result with the intended users' needs in mind; an automated pass is not a blanket accessibility certification.

A small team should document its tested environment and supported outputs. Untested environments remain unknown. If a template uses unavailable fonts, record the fallback and inspect whether it changes line wrapping or hides a qualification. If a deck includes links, verify destinations in the delivered artifact rather than assuming they survived an export.

Retain the reviewed file itself. Regenerating “the same” presentation later may produce a different artifact, and reviewing a screenshot does not authorize every future export from the same prompt.

8. Compare review effort across the entire workflow

The commercial question is whether the feature reduces the work needed to produce an acceptable deck for your customers. Measure from approved input to approved deliverable. Generation time alone leaves out source preparation, reviewer corrections, export failures, and abandoned attempts.

Use a small set of representative assignments and hold some back while refining the workflow. Include an ordinary update, a sparse input with deliberate unknowns, a dense chart slide, and an assignment requiring your target language. These are proposed categories, not a statistically sufficient sample. Choose real work you are authorized to use, or synthetic material clearly labeled as such.

Compare against the existing template workflow using the same approved source. Record preparation minutes, generation waiting time, factual review, design edits, delivery checks, and rework. Count attempted decks and approved decks separately. If a system quickly produces many rejected files, averaging time only across successful exports conceals that cost.

Two useful measures are total hands-on minutes divided by approved deliverables, and total workflow spend divided by approved deliverables. State what spend includes. For a self-managed system, account for the operational work you actually incur rather than treating a model invocation as the whole service. Keep elapsed delivery time separately: a workflow can save staff effort but still be too slow for a customer meeting.

Report categories of failure alongside any average. A single unsupported claim may matter more than several layout fixes, depending on the deck's purpose. Do not combine these into a reassuring number without retaining the underlying cases. Explain how much human intervention was required before approval.

Ask reviewers to evaluate the artifact before discussing the system that produced it where practical. Familiarity or excitement about a model can influence impressions. Afterward, collect workflow feedback: could the reviewer locate the source of a claim, edit one slide without losing the rest, and recover from an export failure? Those observations connect a model demonstration to a product someone can support.

9. Choose the smallest honest launch promise

The first useful version may be a drafting assistant that produces a reviewable brief and editable candidate slides. That can serve a small team even when unattended delivery is unjustified. Make the status visible and keep the person responsible for the customer relationship in the approval loop.

Expand only when the evidence matches the new promise. Supporting another brand needs its own reference pack and review. Supporting another language needs actual content and rendering checks. Offering automatic sending needs a reliable connection between approved version and delivered file. None of those follows automatically from a benchmark result.

There are also cases where this workflow is a poor fit. A one-off keynote may depend so heavily on narrative judgment that maintaining an automated pipeline offers little benefit. A team without approved source material needs to settle its claims first. A presentation containing sensitive customer material needs an approved data-handling arrangement across the whole service, including previews, exports, storage, and support; model location alone cannot answer that question.

For a first product decision, ask the team to bring three concrete artifacts: the approved input and brand pack, a candidate deck with completed review notes, and the exact file that would reach the recipient. Discuss unresolved rows before adding more generation features. If the team cannot show the file or explain a qualification, narrow the scope to internal drafting.

The opportunity raised by Palette is worth investigating because presentations are useful business outputs with inspectable structure. The founder's job is to turn that opportunity into a defensible customer promise. Harbor should launch a feature that helps prepare accurate, reviewable customer conversations before promising to automate those conversations away.

References

• IBM Research: Palette, November 3, 2026
• PresentBench paper, March 2026
• PresentBench official evaluation code
• IBM Design Language: Color
• IBM Design Language: 2x Grid
• IBM Design Language: Typeface
• PptxGenJS: Saving presentations
• Microsoft: Accessible PowerPoint presentations