Problem–Solution Ad Examples: Make the Demo Answer the Problem

A worked example: follow Calo's transition, not its promise

The recorded scene guide for this 41-second reference has five parts: a calorie-deficit statement at 00–06s; a question about knowing whether one is in a deficit at 06–12s; a plate and app opening at 12–18s; a displayed calorie, macro and ingredient result at 18–29s; then a return to the creator and product close at 29–41s. These timings are reference annotations, not a recommended template length.

The strongest connection is between uncertainty about food information and the act of scanning a meal. The creator supplies a reason to look at the interface. The interface supplies something concrete to inspect. That is more useful as a production reference than simply copying a line about a frustrating problem.

The limit matters just as much. The result screen is evidence that the creative displays an estimate. It is not independent evidence that the estimate is accurate, that someone is in a deficit, or that a health outcome follows. A narrower opening about understanding the contents of a meal would be closer to the visible demonstration. This is a creative critique, not nutrition guidance.

A second example: a decision can be the problem

Pin Trading uses a collector and convention context before demonstrating identification and collection information. There does not need to be an angry ‘before’ scene. The unresolved task—understanding an item before a trade—is enough to motivate an action.

Our interpretation is that this reference makes the problem situational. The scan becomes useful at a particular moment. But identification and value context still do not prove that a trade will be fair or profitable. Keep those ideas separate when writing your own close.

This is a useful alternative when your product helps with a modest decision rather than an urgent pain point. A checklist can help someone remember an item; it need not be described as eliminating travel stress. A receipt organizer can make a document retrievable; it need not promise to solve every bookkeeping problem.

Use a promise-to-proof worksheet

Take a hypothetical receipt organizer. The weak version opens with ‘Never worry about taxes again,’ shows a camera capture and ends with an install prompt. The demo only shows document capture, so it cannot support the opening. The problem is not a lack of animation or urgency. It is a mismatch in scope.

A more defensible version opens with a person searching a messy folder for one receipt. They photograph that receipt with the app, attach a project label, and retrieve it by that label. The proposed close is ‘Keep your next receipt with its project.’ This example is an original teaching scenario, not a real ad or evidence that a specific product supports those features.

Before production, verify every action in the actual product. If retrieval needs a paid tier, show the relevant context rather than implying it is free. If the interface does not support labels, change the script. A reference should not persuade you to invent a feature for the demonstration.

• Problem: describe one observable task the viewer cannot complete easily.
• Bridge: write why the next product action is relevant to that task.
• Action: record the real interaction, including necessary intermediate steps.
• Evidence: identify the exact screen element that answers the problem.
• Limit: remove any claim that goes beyond the screen and your supporting evidence.
• Close: ask for the next action that follows naturally from this demonstration.

Check the bridge with three freeze frames

Choose a frame from the problem, one from the interaction and one from the result. Put a short caption under each: ‘I need X,’ ‘I do Y,’ ‘Now I can see Z.’ Read only those captions. If Z does not answer X, the script needs a different result or a narrower problem.

Next, remove the spoken explanation and inspect the frames. Can someone still identify the object, interaction and output? This is an editorial check, not a formal audience study. It helps expose an interface that is too small, a result that disappears immediately, or a transition that depends entirely on the narrator's claim.

Finally, ask a colleague unfamiliar with the script what they believe the product promises. If they describe an outcome you cannot support, rewrite the opening or add the missing context. A disclaimer at the end is not a good substitute for an accurate central claim.

Finish with a complete, modest promise

The practical deliverable is a script in which the opening, product action and result belong to the same task. You do not need to inflate the discomfort to make that task worth showing. Film the version you can demonstrate honestly, then assess it against your own campaign objective.

If attention is strong but users misunderstand the product, reconsider the promise before adding more hooks. If the intended action is clear but the screen is unreadable, fix the demonstration. Those are different creative problems and call for different revisions.

Frequently asked questions

Sources and method

This analysis uses HookRef’s reviewed public reference records and their scene annotations. Source listings are linked beside each case; some providers may require an account. We have not independently verified the advertisers’ product claims, ad spend or outcomes. Reference headlines may be editorial summaries, not verbatim transcripts. Suggested adaptations are original teaching examples, not observed ads.

For background, TikTok’s Creative Codes recommends a hook, body and close. The case-specific critiques and worksheets here are HookRef’s editorial interpretations; they are not platform-endorsed performance claims.