SAYLOR Determine whether a prospect, problem, budget, authority, timeline, and evidence fit the service before committing to a build or fixed quote.
The result you're building
A qualification record and paid discovery package that verifies identity and decision authority, defines the current problem and value, inventories constraints and dependencies, exposes risk, and produces a go/no-go proposal with testable scope.
Use this guide when
- A prospect requests custom software or automation with vague requirements.
- Identity, company, payment ability, decision authority, or technical feasibility is unclear.
- A fixed quote would require guessing.
Do not use it as a substitute for
- Providing a full custom solution design for free to an unverified lead.
- Treating urgency, enthusiasm, or a partial payment as proof of identity, authority, or reliable collection.
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.
- Verified person/company/contact, billing identity, jurisdiction, and decision authority.
- Problem statement, current workflow, users, impact, alternatives, and evidence.
- Budget range, payment path, deadline driver, stakeholders, and approval process.
- Systems, data, accounts, providers, constraints, security, and compliance needs.
- Discovery deliverables, exclusions, confidentiality, price, acceptance, and go/no-go criteria.
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.
Qualification protects both parties
A no-go can save the buyer from an unsuitable project and the seller from unpaid, unauthorized, or impossible work.
Discovery is a deliverable
When uncertainty materially affects architecture, scope, price, or risk, sell a bounded evidence package rather than hiding guesses inside a fixed estimate.
Evidence-to-decision map
| Evidence | Likely layer | First decisive check | What the result means |
|---|---|---|---|
| Prospect will not identify company | Identity/trust | Verify billing entity, domain, role, and references | Collection, authority, and dispute risk are high. |
| 'Simple' request has many integrations | Complexity | Map systems, owners, data, APIs, and acceptance | Hidden dependencies make fixed quote unreliable. |
| No one owns acceptance | Decision process | Identify signer, operator, and approver | Project may finish technically but never be accepted or paid. |
| Deadline has no event behind it | Priority | Ask what changes if date moves | Urgency may be negotiation pressure rather than operational constraint. |
| Budget far below required result | Fit/economics | Offer narrower result or discovery; compare alternatives | Proceeding would require unsafe scope cuts or unpaid work. |
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 — Verify the prospect and authority
Why: A precise boundary prevents a plausible fix from solving the wrong problem.
Do: Confirm legal/billing identity, domain/contact, role, decision power, payment method, jurisdiction, and who owns accounts/data. Use proportionate checks.
Read the result: You know who can sign, pay, grant access, and accept.
Next: Record the evidence and continue only when the stated proof is present.
Step 02 — Define the business problem
Why: Symptoms are not enough; a baseline preserves the evidence needed to isolate the failing layer.
Do: Document current process, users, frequency, pain, cost/risk, trigger, desired outcome, alternative, and what evidence would prove value.
Read the result: The problem is more specific than a requested technology.
Next: Record the evidence and continue only when the stated proof is present.
Step 03 — Map stakeholders and decisions
Why: Inconsistent inputs create false differences and make later comparisons unreliable.
Do: Identify economic buyer, operator, technical owner, security/privacy reviewer, approver, and blockers. Record decision timeline and communication path.
Read the result: Required decisions have named owners and dates.
Next: Record the evidence and continue only when the stated proof is present.
Step 04 — Inventory technical and data reality
Why: A decisive test reduces trial-and-error and limits unnecessary change.
Do: List systems, versions, APIs, credentials ownership, data volumes/classes, environments, providers, constraints, prior attempts, and access limitations.
Read the result: Major feasibility and authority risks are visible.
Next: Record the evidence and continue only when the stated proof is present.
Step 05 — Choose quote or paid discovery
Why: The smallest reversible correction lowers the blast radius while preserving a recovery path.
Do: Quote a standard product only when inputs and variation are bounded. Otherwise define discovery questions, methods, artifacts, time, price, exclusions, and acceptance.
Read the result: Discovery has a useful standalone result even if the build is no-go.
Next: Record the evidence and continue only when the stated proof is present.
Step 06 — Set commercial and access boundaries
Why: The happy path cannot expose replay, timeout, malformed-input, authority, or dependency failures.
Do: Use written scope, confidentiality, deposit/milestones, non-refundable discovery as lawful/appropriate, expiration, change path, and staged least-privileged access. Never accept secret material by chat.
Read the result: Work and access exposure match collected payment and verified need.
Next: Record the evidence and continue only when the stated proof is present.
Step 07 — Issue evidence-backed go/no-go
Why: A result is not complete until it remains observable and repeatable after the immediate fix.
Do: Deliver current-state map, requirements, risks, options, assumptions, acceptance tests, estimate range, dependencies, and next decision. State no-go honestly.
Read the result: Client can choose using evidence and neither party is trapped by hidden assumptions.
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.
- Verified person/company/contact, billing identity, jurisdiction, and decision authority.
- Problem statement, current workflow, users, impact, alternatives, and evidence.
- Budget range, payment path, deadline driver, stakeholders, and approval process.
- Systems, data, accounts, providers, constraints, security, and compliance needs.
- Discovery deliverables, exclusions, confidentiality, price, acceptance, and go/no-go criteria.
Acceptance scoreboard
- Legal/billing identity, contact, role, authority, jurisdiction, and payment path are verified proportionately.
- Problem, current process, value, alternatives, and success evidence are documented.
- Stakeholders, decisions, deadline driver, budget, and blockers have owners.
- Systems, data, access, providers, constraints, and prior attempts are inventoried.
- Quote versus paid discovery decision follows bounded uncertainty.
- Commercial terms, staged access, go/no-go, and next action are documented.
Minimum handoff record
- Versioned client qualification and paid discovery 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
- Only a first name and chat handle are known.
- No verified company or billing address is recorded.
- Ten percent is paid.
- Repository access may allow full download before final payment.
Decision: Commercial leverage and identity evidence are weak. Preserve records, stop expanding access, and move to written qualification, acceptance, invoice, and milestone conditions without sabotage or retaliation.
Actions taken
- Captured agreement, messages, payment, repo invitation, and release hash.
- Requested verified billing identity and acceptance owner.
- Defined demo, acceptance tests, final transfer, and payment deadline.
- Changed future process to deposit, milestones, and gated handoff.
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.
- Legal/billing identity, contact, role, authority, jurisdiction, and payment path are verified proportionately.
- Problem, current process, value, alternatives, and success evidence are documented.
- Stakeholders, decisions, deadline driver, budget, and blockers have owners.
- Systems, data, access, providers, constraints, and prior attempts are inventoried.
- Quote versus paid discovery decision follows bounded uncertainty.
- Commercial terms, staged access, go/no-go, and next action are documented.
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 |
|---|---|---|
| Prospect will not identify company | Collection, authority, and dispute risk are high. | Verify billing entity, domain, role, and references |
| 'Simple' request has many integrations | Hidden dependencies make fixed quote unreliable. | Map systems, owners, data, APIs, and acceptance |
| No one owns acceptance | Project may finish technically but never be accepted or paid. | Identify signer, operator, and approver |
| Deadline has no event behind it | Urgency may be negotiation pressure rather than operational constraint. | Ask what changes if date moves |
Reusable handoff record
- Versioned client qualification and paid discovery 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