SAYLOR The result you are building
A sellable service package that tells the right buyer exactly what result they receive, what they must provide, what is excluded, how changes are priced, when acceptance occurs, and how delivery is proven.
Use this guide when:
- You repeatedly build websites, automations, agents, audits, data products, or repairs.
- Every proposal currently starts from zero.
- Scope creep and payment ambiguity consume profit.
Do not use it as a substitute for:
- Promising unlimited revisions or "anything needed" for a fixed price.
- Pricing from hours alone without accounting for risk, support, dependencies, and result value.
Before you change anything, collect: target buyer, qualifying problem, current alternative, and desired end state; standard inputs, dependencies, access, decisions, and client responsibilities; procedure, reusable assets, labor, provider cost, risk, support, and capacity; deliverables, acceptance tests, exclusions, revisions, change order, warranty, and support; deposit/milestone/final-payment terms, ownership/license, handoff, and actual margin evidence.
Understand the system before productizing it
- Terms must map to observable events. Scope, acceptance, payment, support, and ownership only work when each obligation has an owner, date, artifact, and pass/fail condition.
- Cash flow outranks informal assumptions. A promising conversation is not collected revenue, accepted work, transferable ownership, or permission to use data.
- Productize the boundary, not the illusion. The service can be repeatable while the work remains expert — standardize who it fits, required inputs, workflow, deliverables, and acceptance.
- Scope is a testable contract. A list of activities is not enough; define the client-visible result, environment, examples, exclusions, owner, and pass/fail evidence.
Evidence-to-decision map
| Evidence | Likely layer | First decisive check | What the result means |
|---|---|---|---|
| Project takes twice estimated effort | Qualification/scope | Compare actual work to standard inputs and exclusions | Offer accepts too much variation or hidden dependencies |
| Client expects extra feature | Acceptance/change | Map request to signed deliverable/test | Outcome or exclusion was ambiguous |
| High sales, low profit | Cost/pricing | Reconcile labor, rework, tools, support, collection | Price ignores variability and post-delivery burden |
| Delivery stalls waiting on client | Responsibilities | Inspect required input/decision deadlines | Offer lacks client prerequisites and a pause policy |
| Same work cannot be reused | Process/assets | Compare projects, extract stable stages | Service is still bespoke in workflow and artifacts |
Step-by-step procedure
- Choose one painful, frequent result. Define the target buyer, trigger, current cost/risk, concrete end state, and situations that do not fit, using past project evidence. *A prospect can self-identify fit in under a minute.*
- Standardize discovery and inputs. Create qualification questions, required files/access/decisions, a security boundary, an owner, and a readiness checklist. Price unresolved complexity separately.
- Define deliverables and acceptance. List artifacts, environment, examples, limitations, observable tests, review window, defect definition, and who accepts — avoid activity-only language. *Every deliverable maps to a pass/fail test.*
- Set scope, revisions, and change path. Declare excluded features, content/data volume, accounts, integrations, revisions, support, downtime, and third-party risk. Use a written change order with price/time impact.
- Price full delivery risk. Estimate standard labor, variance, tools/providers, payment fees, rework, support, risk reserve, tax/accounting needs, and target margin. Use deposit/milestones sized to exposure.
- Build the delivery system. Create templates, checklists, scripts, QA, status updates, an evidence package, handoff, access closure, and a support/warranty schedule. Track cycle time by stage.
- Pilot and tighten the offer. Sell to a small fit cohort; record objections, exceptions, cycle time, revisions, margin, defects, support, and outcomes. Narrow or reprice recurring exceptions.
Worked example
Starting problem: A $500 website package includes "custom integrations" and unlimited changes, causing six weeks of unpaid work.
Evidence collected: The offer lists pages but no acceptance tests; the client requests CRM, booking, and payment changes; revisions have no limit or review window; final payment is due only after subjective satisfaction.
Decision: The offer is not bounded. Convert integrations to named options or paid discovery, cap revisions, and bind payment to objective milestones.
Actions taken: Defined a standard five-page result and launch tests; created priced integration add-ons; limited revision rounds and response window; used deposit, staging acceptance, and final handoff milestones.
Proof of completion: A qualified client can launch the standard result inside target cycle time; extras follow change orders; collected margin matches the model.
Acceptance scoreboard
- Target buyer, problem, fit and non-fit conditions are explicit.
- Required inputs, access, decisions, owners, and deadlines gate start.
- Deliverables map to objective acceptance and limitations.
- Exclusions, revision limits, defects, changes, third parties, and support are classified.
- Price includes full cost, variance, risk, payment timing, and target margin.
- Pilot evidence measures cycle, exceptions, revisions, quality, margin, and outcome.
Decision rule: proceed only when every required acceptance check is supported by direct evidence, rollback is available, and remaining risk is explicitly owned. Unknown is not a pass.
For agents
Human-readable use of this guide is free; the paid product for agents/automation is this same body delivered as deterministic, versioned JSON. When applying this as a decision procedure, require a versioned target (the service/offer being scoped) and sanitized, timestamped evidence; respect declared constraints (authority, budget, reversibility); return a diagnosis, an ordered plan, and verification checks rather than an unqualified recommendation. Refuse requests requiring secrets/credentials in ordinary input; escalate rather than guess when evidence is missing, contradictory, or stale.
Official reference starting points
- U.S. SBA pricing guidance — https://www.sba.gov/business-guide/manage-your-business/set-prices
- NIST software quality resources — https://www.nist.gov/itl/ssd/software-quality-group
- FTC business guidance — https://www.ftc.gov/business-guidance
*This material is educational operational information, not legal, tax, accounting, or collection advice. Use qualified professionals for decisions requiring those licenses.*