SAYLOR Turn custom technical work into a repeatable offer with a defined result, fit criteria, inputs, process, exclusions, revision limits, acceptance, price, and handoff.
The result you're 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 these items first. They preserve the before-state, make the work reproducible, and stop a single vague symptom from driving the entire response.
- 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/milestones/final payment, ownership/license, handoff, and actual margin evidence.
Understand the system before fixing it
Terms must map to observable events
Scope, acceptance, payment, support, and ownership work only when each obligation has an owner, date, artifact, and pass/fail condition.
Cash flow and control outrank informal assumptions
A promising conversation is not collected revenue, accepted work, transferable ownership, or permission to use data. Record the actual state.
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, and collection | Price ignores variability and post-delivery burden. |
| Delivery stalls waiting on client | Responsibilities | Inspect required input/decision deadlines | Offer lacks client prerequisites and pause policy. |
| Same work cannot be reused | Process/assets | Compare projects and extract stable stages | Service is still bespoke in workflow and artifacts. |
Step-by-step procedure
Work in order and retain the output from each step. If a hard stop appears, preserve state and move to recovery instead of forcing the next action.
Step 01 — Choose one painful, frequent result
Why: A precise boundary prevents a plausible fix from solving the wrong problem.
Do: Define the target buyer, trigger, current cost/risk, concrete end state, and situations that do not fit. Use past project evidence.
Read the result: A prospect can self-identify fit in under a minute.
Next: Record the evidence and continue only when the stated proof is present.
Step 02 — Standardize discovery and inputs
Why: Symptoms are not enough; a baseline preserves the evidence needed to isolate the failing layer.
Do: Create qualification questions, required files/access/decisions, security boundary, owner, and readiness checklist. Price unresolved complexity separately.
Read the result: Work starts only when prerequisites are complete or exception is approved.
Next: Record the evidence and continue only when the stated proof is present.
Step 03 — Define deliverables and acceptance
Why: Inconsistent inputs create false differences and make later comparisons unreliable.
Do: List artifacts, environment, examples, limitations, observable tests, review window, defect definition, and who accepts. Avoid activity-only language.
Read the result: Every deliverable maps to a pass/fail test.
Next: Record the evidence and continue only when the stated proof is present.
Step 04 — Set scope, revisions, and change path
Why: A decisive test reduces trial-and-error and limits unnecessary change.
Do: Declare excluded features, content/data volume, accounts, integrations, revisions, support, downtime, and third-party risk. Use written change order with price/time impact.
Read the result: New requests classify consistently as defect, included revision, or change.
Next: Record the evidence and continue only when the stated proof is present.
Step 05 — Price full delivery risk
Why: The smallest reversible correction lowers the blast radius while preserving a recovery path.
Do: Estimate standard labor, variance, tools/providers, payment fees, rework, support, risk reserve, tax/accounting needs, and target margin. Use deposit/milestones appropriate to exposure.
Read the result: Downside case remains economically survivable.
Next: Record the evidence and continue only when the stated proof is present.
Step 06 — Build the delivery system
Why: The happy path cannot expose replay, timeout, malformed-input, authority, or dependency failures.
Do: Create templates, checklists, scripts, QA, status updates, evidence package, handoff, access closure, and support/warranty schedule. Track cycle time by stage.
Read the result: Another qualified operator can follow the process without hidden knowledge.
Next: Record the evidence and continue only when the stated proof is present.
Step 07 — Pilot and tighten the offer
Why: A result is not complete until it remains observable and repeatable after the immediate fix.
Do: Sell to a small fit cohort, record objections, exceptions, cycle time, revisions, margin, defects, support, and outcomes. Narrow or reprice recurring exceptions.
Read the result: Version 2 of the offer reflects actual delivery evidence.
Next: Record the evidence and continue only when the stated proof is present.
Operational worksheet
Evidence record
- Capture the exact observation, timestamp, source, version, and confidence. Sanitize credentials and personal data before sharing the record.
- 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/milestones/final payment, ownership/license, handoff, and actual margin evidence.
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.
Minimum handoff record
- Versioned productized service scope and pricing scope, owner, exclusions, and success criteria.
- Sanitized evidence snapshot with source, time, version, and confidence.
- Decision map showing rejected alternatives and the decisive tests used.
- Ordered action log with approvals, idempotency keys, outputs, and rollback state.
- Acceptance results, remaining risks, review date, and escalation owner.
Worked example
Evidence collected
- The offer lists pages but no acceptance tests.
- 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 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.
Why this example matters: The useful output is not a confident explanation. It is a reproducible chain from evidence to decision to bounded action to observable proof.
Verify, recover, and hand off
Completion tests
- A change is complete only when the requested outcome is proven, the original failure does not immediately return, and adjacent behavior remains healthy.
- 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.
Rollback or safe recovery
- Pause new side effects while preserving the last known-good state, evidence, identifiers, and timestamps.
- Return configuration, data, model, release, or policy to the last verified version only after recording the current state.
- Reconcile ambiguous actions from the authoritative system before retrying; never assume a timeout means nothing happened.
- Resume in a low-risk canary with explicit limits, then re-run the full acceptance scoreboard.
If the expected result does not appear
| What happened | What it usually means | Next safe move |
|---|---|---|
| Project takes twice estimated effort | Offer accepts too much variation or hidden dependencies. | Compare actual work to standard inputs and exclusions |
| Client expects extra feature | Outcome or exclusion was ambiguous. | Map request to signed deliverable/test |
| High sales, low profit | Price ignores variability and post-delivery burden. | Reconcile labor, rework, tools, support, and collection |
| Delivery stalls waiting on client | Offer lacks client prerequisites and pause policy. | Inspect required input/decision deadlines |
Reusable handoff record
- Versioned productized service scope and pricing scope, owner, exclusions, and success criteria.
- Sanitized evidence snapshot with source, time, version, and confidence.
- Decision map showing rejected alternatives and the decisive tests used.
- Ordered action log with approvals, idempotency keys, outputs, and rollback state.
- Acceptance results, remaining risks, review date, and escalation owner.
Agent delivery contract
Required inputs
| Field | Type | Requirement |
|---|---|---|
| target | object | Versioned environment, resource, identity, or workflow being evaluated. |
| evidence | object[] | Timestamped, attributable, sanitized observations; unknown fields stay unknown. |
| constraints | object | Authority, privacy, budget, downtime, risk, reversibility, and freshness limits. |
| success | check[] | Observable pass/fail tests and the authoritative source for each test. |
Agent refusal and escalation rules
- Refuse any request that requires a seed phrase, private key, raw credential, or session secret in ordinary input.
- Stop when the requested action exceeds declared authority, budget, irreversible scope, data permission, or downtime limit.
- Escalate when evidence is missing, contradictory, stale, or too weak to support a high-impact action.
- Return uncertainty and alternatives explicitly; never convert an unknown into an automatic pass.
Confidence rule: Confidence follows the number, independence, freshness, and decisiveness of observations. Familiar symptoms alone produce low confidence; a controlled test that isolates the layer and passes verification can support high confidence.
Official reference starting points