A SaaS landing-page prompt with a worked example

Tell the assistant what the software does today

A useful SaaS landing-page prompt names the buyer, the job the software performs, the evidence available, and the action the product can support. “Make a modern SaaS page” often leaves the assistant to invent pricing tiers, customer logos, and a signup flow. Supply those facts or mark them as unknown.

The worked example here uses Pageree’s documented product workflow: an assistant can save a landing-page draft, publish it after review, configure form delivery, and read supported analytics after traffic arrives. The copy below is an original editorial example based on those facts, not a measured campaign result or a transcript of an externally tested AI session.

Choose trial, demo, or waitlist before writing

Action	What must exist	What the page should say
Start a trial	A real account and trial-start process	Describe the actual access and terms
Request a demo	Someone who can respond and demonstrate the product	Explain that the request needs follow-up
Join a waitlist	A real interest-capture and update process	Explain current availability honestly

Do not display all three as equivalent primary actions. A product may offer alternatives, but one should match the campaign’s goal. For a product sold through a conversation, use the demo template. For a product that is not ready, use the waitlist template.

Copy this complete SaaS prompt

Create a focused landing page for Pageree.
Buyer: a founder or small business owner who already uses an AI
assistant and needs a landing page that can receive enquiries.
Job: turn a business brief into a reviewed, published page and
continue improving it through the assistant.

Verified product facts:
- Pageree connects through supported AI-assistant workflows.
- Pages are saved as private drafts before approved publication.
- Forms can deliver accepted submissions by email or configured HTTP.
- Custom domains can be connected after publication with DNS setup.
- Supported page analytics can be reviewed after real traffic arrives.
- Native booking, payments, newsletter autoresponders, and A/B
  traffic splitting are not part of this landing-page workflow.

Primary action: Create an account.
Destination: https://console.pageree.com/signup
Secondary context: https://pageree.com/docs/
Do not invent customer numbers, time savings, integrations, or ROI.
Do not invent plan prices; link current pricing instead of guessing.

Use a direct hero, a three-step workflow, an enquiry-delivery
explanation, supported use cases, practical FAQ, and account CTA.
Show genuine product imagery only if supplied; otherwise use a
clearly labelled workflow illustration. Keep the text readable on
mobile. Produce the complete copy first, then a private Pageree
draft after the outline is approved. Return the preview and wait
for review before publication. Reuse the existing page ID if editing.

A finished copy example from those facts

Headline: Build your landing page with the assistant you already use.

Supporting copy: Give your assistant the offer. Review a private preview, publish the approved page, and send enquiries to the destination you choose.

Primary action: Create an account.

Workflow: Start with the business brief. Review the page before it goes public. Check your enquiries and choose the next improvement once visitors arrive.

Delivery section: A form should do more than show a success message. Configure owner email or an approved HTTP workflow, then test the published page through to the final inbox or record.

Fit section: Use Pageree for a focused offer, waitlist, consultation request, or quote page. Use an external service for checkout or confirmed calendar booking when the offer requires it.

FAQ answer: “Can I use my business domain?” Publish the page first, then connect the exact hostname you own and add the DNS record returned by Pageree.

This output makes the product’s job understandable without adding a fabricated customer story. It is one possible version, not evidence that this headline performs better than another.

Adapt the example without importing its assumptions

Replace every product fact with your own verified capability. A software screenshot should show a real available workflow, or be labelled as a concept. State whether a trial requires payment details only when the actual flow confirms it. Keep feature availability consistent between the landing page and onboarding.

Then review the public destination, confirmation behavior, and goal measurement. A click toward account creation is not automatically a completed signup. Use the brief worksheet to collect the missing facts, and use your product’s own data to assess the complete acquisition journey after launch.