Buyer Requests, Proposals and Fulfillment
A business can describe an outcome it wants automated. Builders respond with a plan and a price. The buyer picks one. You get paid through the same marketplace checkout as any other sale.
How requests reach you
A buyer submits a structured brief: the outcome, current tools, implementation budget, timeline and maintenance preference. The platform keeps the buyer's account and workspace identifiers private and scores each open request against your published listings' categories and tags. Publish accurate categories and tool names, because matching depends on them.
A request belongs to builders. SchemaBounce does not copy it into its CRM or use its text to sell its own automations or services (dec-009). The raw request text is deleted 30 days after the request closes. Builders can read the full brief, so buyers are told not to include personal data, customer names, secrets or credentials.
Respond with a proposal
Open Sell, then Opportunities. The best matches are first. A proposal has:
- an implementation plan, 3,000 characters at most;
- a one-time implementation offer, chosen from your published one-time listings, or no implementation charge;
- an optional monthly maintenance offer, chosen from your published managed listings, with a written maintenance scope of at least 10 characters;
- an initial delivery estimate, 1 to 365 days.
Each publisher submits one proposal per request. The buyer sees implementation and maintenance prices separately (dec-008).
Acceptance
When the buyer accepts, no charge is made at that moment. The accepted proposal records the agreement. Payment happens through your published offers, so setup and maintenance stay two auditable transactions.
Fulfillment stages
After acceptance the marketplace tracks each line item. It derives each stage from evidence and never infers a later stage from an earlier one.
| Stage | Meaning |
|---|---|
| Accepted | The buyer accepted the proposal. |
| Checkout pending | A checkout exists for it. |
| Purchased | Payment completed and the entitlement is active. |
| Deployed | A provenance-stamped agent or workflow exists in the buyer's workspace. |
| Enabled | The buyer enabled it. |
| Ran | At least one run finished, manual test runs included. |
| Proven | At least one successful run that was not a manual test run. |
Refunded and revoked are final states. Needs attention is a flag when recent runs failed.
Run proof is the buyer's choice
On a one-time sale, you see stages up to Deployed. Enabled, Ran and Proven reach you only after the buyer shares run proof. It is off by default, because the workspace and its data belong to the buyer (dec-015).
Proof is metadata only: that a run exists, finished, succeeded, and came from the stamped agent or workflow. It never includes prompts, results, errors, step output or conversation content.
Installing stays a buyer action in the console. Nothing installs automatically on purchase.
Notifications
Marketplace notifications carry ids, counts, stages and timestamps only. They never carry request text or the buyer's identity. Email to builders is transactional only (dec-085).