Selling

You have something worth paying for. This chapter is about the distance between that and money arriving: putting a price on it, giving buyers a checkout that works, and getting them into the product the moment they pay — all from your own site, on your own terms.

On Omumu you don’t fill in a product listing on someone else’s marketplace. You tell your AI assistant what you want to sell and for how much, and it sets up the offer, the checkout, and the delivery. You can pre-sell a course that doesn’t exist yet, bolt an extra purchase onto your checkout, give a course away free to grow your list, invoice a company instead of asking for a card, or hand someone access as a gift — and, before any of it, have your assistant research the market and architect the offer from what buyers actually say. Every one of those is a few sentences of conversation. The rest of this chapter shows you the sentences — and, for each, the buttons in the admin UI that do the same thing. A path such as Sales and marketing → Offers names a group in the admin’s navigation — the rail on the left on a laptop, behind the Menu button on a phone — and the page under it.

Concepts

Selling on Omumu revolves around one object and one guarantee.

The object is the offer: a sellable bundle scoped to your site. An offer holds a list of products (courses, skills, and optionally a platform subscription plan), a price, a validity window, and an optional tag that triggers automations when someone buys. The offer — not the course — is what has a checkout URL. One course can be sold through many offers at different prices and framings; an offer can bundle several products into one purchase.

An offer has one status, shown everywhere: not published until you give it a Valid From date, scheduled while that date is in the future, live while it is within its window and the checkout can actually take orders, paused when it is within its window but the checkout cannot (the status says why — a payment provider not connected, for example), and ended after its Valid To.

The guarantee is that an offer’s price is frozen once it is published. The moment an offer’s validity window is set and it can be bought, its price never changes again. To charge something different, you copy the offer into a new one with a new price — the old offer id keeps meaning what every buyer saw when they bought. Your sales history stays honest by construction.

A few more terms carry the rest of the chapter:

A bump offer is an offer attached to a parent offer and presented as an optional checkbox on the order form — “add this to my order”. Only bumps that are currently live are shown, and a ticked bump fulfils as its own mini-purchase alongside the parent. Since a bump must be live (hence published) to be offered, its price is already frozen too.

A free offer is simply an offer priced at zero. The order form detects the zero price and fulfils immediately — no payment step at all. Understand what that means: while a free offer is live, anyone who submits the public order form gets the products. It is a live giveaway, not a private test.

An Invoice Request is a payment option for buyers who don’t pay by card at checkout — typically companies. Choosing it grants the buyer full access immediately, at the offer’s real price, and records an invoice request for you to bill against later. Grant now, bill later. Unlike a free offer it sits behind an explicit button at a real price, so it is not open-door access.

Behind all of these sits offer fulfillment, and its key property is that it is decoupled from payment. Granting access and recording payment are separate machinery: the access side gives the buyer their student role, product access, welcome email, and fires the offer’s automation tag; the payment side records the payment and sends the receipt. Card purchases run both; a free offer runs both with an amount of zero; an Invoice Request runs both without money changing hands yet; a gift grant (below) runs only the access side. Fulfillment is also exactly-once: however many payment signals arrive — buyer returning to the page, provider webhook, a retry — a purchase fulfils once, never twice.

Because fulfillment doesn’t wait for a finished product either, Omumu supports the pre-sale offer: an offer connected to a real but still-empty course, sold to validate demand before you build. Buyers get normal access immediately — to a product you then fill in. The platform’s validation page takes this further: a designed, structured sales page sold through a low-ticket offer, built to test whether strangers will pay for an idea. This chapter covers the selling mechanics of pre-sales; the validation page itself and its self-improving machinery have their own chapters.

Hands-on

The walkthroughs below follow Mira, an independent developer turned educator who teaches non-programmers to automate their work with spreadsheets and AI. She runs her course business by talking to her AI assistant, which operates her Omumu site directly. Each walkthrough leads with the conversation, shows what happens underneath, and gives the admin-UI route.

Build the offer from what buyers say

Before Mira prices anything, she wants to know what Norwegian solo consultants actually say about their repeat work. She tells her assistant:

“Start an offer document for Automate Your Week — for solo consultants in Norway who lose hours to repeat admin. Research what they say, then architect the offer. Build it on my existing course.”

The assistant opens an Offer DNA document (omumu_offer_dna_create) from the interview — the idea, the audience, any price idea, the intended size of the thing (a single video, a few lessons, a multi-module programme, or undecided), and either an existing course or a pasted outline to build on. Then it does the work itself, in two rounds. omumu_offer_dna_research_brief hands it the method rules and the exact shape the research must take; the assistant searches the web, and submits its cited findings with omumu_offer_dna_research_submit. omumu_offer_dna_architect_brief hands it the research verbatim, the method and the output schema; the assistant drafts the stack, the bonuses, the guarantee, name candidates and a score, and submits them with omumu_offer_dna_architect_submit. Degenerate or empty submissions are refused. None of this spends Omumu’s AI budget: the thinking is your assistant’s, and the platform validates and stores it. omumu_offer_dna_get returns the whole document; omumu_offer_dna_list lists the site’s documents with their completion state.

From there the offer and its page are ordinary work: omumu_offer_create with the price the architecture settled on, and a sales page written from the document (the Pages and Sales Pages chapter). The document stays as the evidence behind the offer.

There is no admin-UI path for this: the Offer DNA is your assistant’s instrument.

Sell your course from your own website

Mira’s flagship course “Automate Your Week” is ready. She tells her assistant:

“Create an offer for Automate Your Week at 1 490 NOK, card and Vipps payments, and put it on sale from Monday.”

The assistant creates the offer (omumu_offer_create) with the title, the price in cents, the course, the payment providers, and a validFrom date. Only a title and price are strictly required — currency defaults to NOK, and products, payment options, pages, and dates can all be added afterwards (omumu_offer_add_product, omumu_offer_update). Setting Valid From to now or to a past time publishes the offer; a future date schedules it. The result reports the status honestly — live only when the checkout takes orders, otherwise paused with the reason — and returns the checkout URL Mira can put behind any buy button. A payment provider the site has not connected is refused at once, so the assistant cannot create an offer that looks sellable and is not (Invoice always works).

One more refusal guards the page rather than the checkout. A new offer’s sales page is a starter letter with bracketed prompts where only Mira knows the substance, and the offer cannot be published while any remain: omumu_offer_update with a Valid From fails and lists each one (section, field, excerpt, where to fix it), omumu_offer_create with a Valid From drops the date and returns the offer not published with the list and a warning, and omumu_offer_get shows the list under salesPagePlaceholders for a check before trying. The edit page’s Valid From refuses the same way, each prompt a link into the editor. Until the offer is published, its sales page answers visitors with a 404 and shows the Headmaster a banner saying so; a scheduled offer’s page is public before launch. The Pages and Sales Pages chapter has the page itself.

Mira asks “what am I selling right now?” and the assistant lists every offer with its status, products, and pricing (omumu_offer_list), or pulls one offer’s full detail (omumu_offer_get). If a draft was a mistake, it can be deleted — but only an offer that has never been sold (omumu_offer_delete); sold offers are permanent sales history.

Two honesty notes. First, the frozen-price rule from Concepts applies here: once this offer is published, “change the price to 1 990” means the assistant copies it into a new offer at the new price — the update tool changes the price only while the offer is still unpublished. Second, whether the offer can actually take orders also depends on your site’s payment setup: card payments need your Stripe account connected and chargeable, Vipps needs your Vipps integration. Until at least one selected payment path is usable, the order form shows a neutral “not taking orders” state, the offer reads paused, and it un-pauses by itself when you finish the setup — no republish needed.

In the admin UI: the offer wizard at Sales and marketing → Offers → New offer walks through the same fields, and existing offers are listed and edited at Sales and marketing → Offers.

Get paid for a course idea before you build it

Mira has an idea for a second course — “AI Email Triage” — and wants proof people will pay before she records a single lesson. She says:

“Create an empty course called AI Email Triage, and sell it at an early-bird 790 NOK. I’ll build it in March.”

The assistant creates the skeleton course (chapter 2) and an offer around it, exactly as above. This is a pre-sale offer: a purchase fulfils like any other, so early buyers get real access immediately — to a course that is still empty. There is no special pre-order state and no gate; the “opens in March” date is a communicated expectation. Set it and the thank-you page tells buyers “Available on [date]” instead of showing an access button. As Mira fills the course in, the content simply appears for everyone who already bought.

Stated plainly: setting that access-opens date is UI-only today — it lives on the offer’s edit page in the admin UI and is not exposed through the assistant’s tools. The assistant can create and sell the pre-sale offer; Mira sets the date at Sales and marketing → Offers → edit.

If the idea fails the test, the exit is as honest as the entry: refund the buyers and revoke their access. And if what you want to validate is the pitch as much as the product, the validation page (see the Pages and Sales Pages chapter) is this same pre-sale mechanic wrapped in a designed, self-improving sales page.

Add an order bump to your checkout

Every buyer of “Automate Your Week” is a good prospect for Mira’s template pack, sold as its own small offer at 290 NOK. Rather than a separate campaign, she puts it on the checkout itself:

“Offer the template pack as an order bump on the Automate Your Week checkout.”

The assistant attaches the bump (omumu_offer_add_bump). From then on the order form shows a checkbox — buy the course, tick to add the templates — and a ticked bump fulfils as its own mini-purchase alongside the parent: the buyer gets both products, and your records show both sales. Both offers must belong to the same site, an offer cannot be its own bump, and only a bump that is currently live is actually shown to buyers — so if the template-pack offer’s validity window ends, the checkbox quietly disappears rather than selling something unbuyable. Removing a bump is the mirror move (omumu_offer_remove_bump).

In the admin UI: bumps are managed on the offer’s edit page at Sales and marketing → Offers.

Run a free course as a giveaway

Mira made a three-lesson mini-course, “Five Formulas That Replace an Hour of Work”, to grow her mailing list. She says:

“Create a free offer for the mini-course.”

An offer with a price of zero (omumu_offer_create with totalAmountCents: 0 and no payment providers) skips the payment step entirely: anyone who submits the order form gets the course immediately, with the full delivery — account, student role, access, welcome email, and the offer’s automation tag, which is what makes it a list-builder: tag the buyers and let your email automation (see the Audience and Email chapter) take it from there.

The honesty note is the one from Concepts, worth repeating because it bites: a live free offer is a live giveaway — the wizard’s review step says so under Valid From, and a free offer’s starter letter uses free wording rather than “pay 0 kr once”. The public order form fulfils it for anyone who submits. Do not use a free offer to preview a course privately — end the offer’s validity window when the giveaway should stop, or use a direct access grant (below) for individuals.

In the admin UI: create an offer in the wizard at Sales and marketing → Offers with price 0.

Take invoice payments from companies

An office manager wants “Automate Your Week” for her team of five and asks — as B2B buyers do — whether she can pay by invoice instead of card. Mira tells her assistant:

“Add invoice payment as an option on the Automate Your Week offer.”

Invoice Request is a payment provider like card or Vipps, set when creating the offer or added later (omumu_offer_create and omumu_offer_update both take paymentProviders; on update the list replaces the offer’s current providers). A buyer who clicks it gets full access immediately at the offer’s real price, and Omumu records an invoice request for Mira to bill against. The trade is explicit: the buyer is served now, and collecting the money is Mira’s follow-up, tracked so it isn’t forgotten. Because it needs no card machinery, an offer with Invoice Request enabled can take orders even before Stripe or Vipps is connected.

Stated plainly: the follow-up — seeing and settling recorded invoice requests — is admin-UI work (Products → Invoice Requests), not something the assistant does.

Give someone free access to a paid course

A podcast host who had Mira on as a guest should get “Automate Your Week” as a thank-you. No checkout, no zero-price offer visible to the world — just a direct grant:

“Give jonas@example.com access to the Automate Your Week offer — note that it’s the podcast thank-you.”

The assistant grants access (omumu_offer_grant_access): Jonas gets everything a paying buyer gets on the access side — student role, access to every product in the offer, welcome email, the offer’s automation tag — but no payment is recorded and no receipt is sent, because none exists. The optional message is kept as an audit note, so six months later “why does Jonas have access?” has an answer. Two constraints: the person must already exist as a user on your site, and offers containing a platform subscription plan can only be gift-granted by Omumu.

In the admin UI the equivalent is slightly different in shape: user management at Customers → Users grants access per product rather than per offer — pick the user, grant the course. Same outcome for a single course; the offer-level grant (all products in one move, offer tag fired) is the assistant’s move.

Reference

omumu_offer_add_bump

Adds a bump offer to an existing offer. The bump appears as a checkbox on the checkout page. Both offers must belong to the same site. An offer cannot be its own bump.

• Write category: standard write
• Access: requires the OFFER_WRITE permission

omumu_offer_add_product

Adds a product (course or skill) to an existing offer. The offer must not be live or ended. Subscription plans (SAAS) are added via omumu_offer_add_subscription_plan instead.

• Write category: standard write
• Access: requires the OFFER_WRITE permission

omumu_offer_add_subscription_plan

Adds a subscription plan (Omumu platform access) to an existing offer. When the offer is purchased, the buyer gets a new Omumu site provisioned on the plan’s tier. Use SAAS_BASIC for the Omumu Basic plan.

• Write category: standard write
• Access: requires the OFFER_WRITE permission

omumu_offer_create

Creates a purchasable offer with title, price, courses, and payment providers. Setting validFrom to now or a past time publishes the offer. status is ‘live’ only when checkout takes orders; otherwise ‘paused’ with pausedReason. A payment provider the site hasn’t connected is refused (Invoice always works). If the sales page still holds unrewritten placeholders, a validFrom is dropped rather than failing the creation: the offer comes back not_published with salesPagePlaceholders filled and a matching warnings message — rewrite the page with omumu_page_update, then publish with omumu_offer_update. Returns the offer with its checkout URL.

• Write category: standard write
• Access: requires the OFFER_WRITE permission

omumu_offer_delete

Deletes an offer. Only offers that have not been sold can be deleted.

• Write category: standard write
• Access: requires the OFFER_DELETE permission

omumu_offer_dna_architect_brief

Returns the complete offer-architecture task for a DNA — the method rules, the embedded research verbatim, interview context, the format-intent constraint when declared, the freshly-resolved fenced existing material, and the exact output schema. Pure read: no AI call, no budget interaction. Run your own architecture using the instructions and context, then submit with omumu_offer_dna_architect_submit. Step order: omumu_offer_dna_research_submit → omumu_offer_dna_architect_brief → omumu_offer_dna_architect_submit → omumu_offer_create and omumu_page_create.

• Write category: read-only
• Access: requires the OFFER_READ permission

omumu_offer_dna_architect_submit

Validates and stores an offer architecture the calling agent produced itself — no AI budget is spent. The proposal object must have architecture, compression, and score matching the schema returned by omumu_offer_dna_architect_brief. Degenerate, empty (no solutions and no stack), or malformed submissions are rejected with a descriptive error; nothing is stored on failure. Re-submitting replaces all three prior sections. Next step: create the offer with omumu_offer_create and its sales page with omumu_page_create, using the DNA’s architecture.

• Write category: standard write
• Access: requires the OFFER_WRITE permission

omumu_offer_dna_create

Starts a research-based offer document (ADR-0034) from a creator interview. Returns its id; follow with omumu_offer_dna_research_brief.

• Write category: standard write
• Access: requires the OFFER_WRITE permission

omumu_offer_dna_get

Returns the full Offer DNA document: interview, cited research, architecture, compression (touchstone + big four), and score.

• Write category: read-only
• Access: requires the OFFER_READ permission

omumu_offer_dna_list

Lists the site’s Offer DNA documents, newest first, with their completion state.

• Write category: read-only
• Access: requires the OFFER_READ permission

No parameters.

omumu_offer_dna_research_brief

Returns the complete voice-of-customer research task for a DNA — the method rules, interview context and the exact output schema the submission must match. Pure read: no AI call, no budget interaction. Run your own web research using the instructions and context, then submit with omumu_offer_dna_research_submit. Next step after submitting: omumu_offer_dna_architect_brief.

• Write category: read-only
• Access: requires the OFFER_READ permission

omumu_offer_dna_research_submit

Validates and stores research the calling agent ran itself — no AI budget is spent. The research object must match the schema returned by omumu_offer_dna_research_brief. Degenerate, empty-findings, or malformed submissions are rejected with a descriptive error; nothing is stored on failure. Re-submitting replaces the research section while leaving any existing architecture untouched. Next step: omumu_offer_dna_architect_brief.

• Write category: standard write
• Access: requires the OFFER_WRITE permission

omumu_offer_get

Gets an offer by ID with full details including checkout URL, status (with pausedReason when paused), products, pricing, payment providers, and salesPagePlaceholders (unrewritten starter prompts still on the sales page, each with section, field, and excerpt; empty when none remain or the offer has no sales page)

• Write category: read-only
• Access: requires the OFFER_READ permission

omumu_offer_grant_access

Grants a user access to all products in an offer WITHOUT requiring payment. This bypasses the normal checkout/payment flow entirely. The user receives the same access as if they had paid: STUDENT role, product access entries, welcome email, and offer-tag execution. An offer containing a SAAS plan can only be granted by Omumu. The user must already exist on the same site as the offer.

• Write category: standard write
• Access: requires the OFFER_WRITE permission

omumu_offer_list

Lists all offers for the current site with their status (not_published/scheduled/live/paused/ended, with pausedReason when paused), products, and pricing

• Write category: read-only
• Access: requires the OFFER_READ permission

No parameters.

omumu_offer_remove_bump

Removes a bump offer from an existing offer.

• Write category: standard write
• Access: requires the OFFER_WRITE permission

omumu_offer_update

Updates an offer’s title, tagline, buttonText, price, payment providers, or validity dates. Only provided fields are updated; others are preserved. Setting validFrom to now or a past time publishes the offer. status is ‘live’ only when checkout takes orders; otherwise ‘paused’ with pausedReason. A payment provider the site hasn’t connected is refused (Invoice always works). Setting validFrom while the sales page still holds unrewritten placeholders fails, listing each one with where to fix it — rewrite the page with omumu_page_update, then retry.

• Write category: standard write
• Access: requires the OFFER_WRITE permission