Other task
Scope a non-standard task before estimating it
You do not need the service name. Describe the current situation and the outcome you need.
- 01 · context
- NOW
- 02 · outcome
- GOAL
- 03 · stage
- SCOPE
- 04 · acceptance
- DONE
01 · Problem
When this service helps
A non-standard task cannot be estimated honestly from one paragraph: scope, data, dependencies and an acceptance criterion come first.
- No standard option fits
- An integration or research phase is needed
- Several disciplines must be coordinated
- A hypothesis needs a bounded test
02 · Diagnosis
How we find the cause
- 01
Record the current state
- 02
Separate mandatory and optional scope
- 03
Review dependencies and risks
- 04
Define the first acceptable result
In plain language
Three terms used in this service.
Acceptance criterion
In plain language: a pre-agreed testable condition used to accept completed work.
The term helps define the issue, agree the outcome and verify delivery.
Open in glossaryConversion
It is the visit outcome the business needs, such as an enquiry, call, purchase or another agreed action.
Without a defined conversion, website or advertising changes cannot be tied to a measurable outcome.
Open in glossaryA/B testing
Some users see variant A and others see variant B, then results are compared using a metric chosen in advance.
The test helps separate a real effect from random variation and subjective preference.
Open in glossary03 · Result
What changes and what you keep
- Clear first-stage boundary
- Named dependencies
- Estimate before work
- Verifiable result
- Task boundaries
- Recommended approach
- First-stage scope
- Timing, price and exclusions
- Acceptance criterion
04 · Process
What we actually do
- 01
Collect context
- 02
Separate outcome from implementation
- 03
Describe options and risks
- 04
Propose the first verifiable stage
- 05
Confirm the estimate before work
05 · Options
Scope, limit and price together
Task review
Clarify the outcome, data and constraints.
LimitAfter the brief
Individual estimateFull tier scope
- Context
- Outcome
- Risks
- Next step
First stage
A bounded stage with an independent result.
LimitScope after the brief
Individual estimateFull tier scope
- Scope
- Timing
- Price
- Acceptance
Project
Several stages with checkpoints.
LimitEstimated after the first stage
Individual estimateFull tier scope
- Stages
- Limits
- Checkpoints
- Handover
06 · Timing and limits
What we clarify upfront
Timing is included in the proposal after the short brief; we do not invent it without inputs.
- Work before estimate approval
- Purchasing services or licences
- Unagreed access to private systems
- Guaranteed business metrics
07 · Proof
Delivery can be accepted against evidence
- 01
We record the baseline and scope before work begins.
- 02
We hand over the completed changes and included materials.
- 03
We repeat applicable checks and state the remaining limits.
Nobody can promise a search position or number of sales in advance: demand, competitors, seasonality and the product all matter. We agree the work, timing and price upfront, then check everything again after the changes.
Result example
A non-standard task first receives boundaries and a definition of done
Instead of a premature estimate, the work starts with a verifiable first stage, known inputs and named dependencies.
Task-framing fragment
An example document used before estimation and delivery.
- Current state
- What works now, where the problem occurs and which data is available
- Required outcome
- What should become possible after the first independent stage
- Unknowns
- Questions that prevent an honest scope until answered
- Assumptions
- Conditions used to form a preliminary approach
- Boundaries
- What is included, excluded and dependent on external inputs
- Artefact
- A document, prototype, integration or another named state
- Acceptance
- Checks that confirm completion of the agreed stage
Before → after
The request describes a solution, not the problem
- The outcome is mixed with implementation
- Access and dependencies are unnamed
- Completion cannot be determined
The first stage can be estimated and accepted
- Current and required states are separated
- Unknowns and assumptions are recorded
- The artefact, boundaries and acceptance check are agreed
Why this option
- No standard service describes the task without substantial exceptions
- A hypothesis or dependency must be tested first
- The project can be separated into independent stages
Why KILENI
- We do not present an implementation preference as a confirmed task
- Unknowns, risks and dependencies are shown before estimation
- The first independent result includes explicit acceptance criteria
This example shows how a non-standard task is framed. Actual scope, timing and price appear only after input review and boundary agreement.
08 · Before ordering
11 answers for a buying decision
Scope, access, timing, acceptance and service boundaries — without hidden assumptions.
01What is wrong right now?
A non-standard task cannot be estimated honestly from one paragraph: scope, data, dependencies and an acceptance criterion come first.
02How will KILENI check it?
Record the current state; Separate mandatory and optional scope; Review dependencies and risks; Define the first acceptable result
03What exactly will be done?
Collect context; Separate outcome from implementation; Describe options and risks; Propose the first verifiable stage; Confirm the estimate before work
04What will I receive?
Task boundaries; Recommended approach; First-stage scope; Timing, price and exclusions; Acceptance criterion
05How do I accept the result?
Accept the result against the criteria agreed upfront: Clear first-stage boundary; Named dependencies; Estimate before work; Verifiable result.
06How long will it take?
Timing is included in the proposal after the short brief; we do not invent it without inputs.
07What does it cost?
Task review — Individual estimate (After the brief); First stage — Individual estimate (Scope after the brief); Project — Individual estimate (Estimated after the first stage)
08What is not included?
Work before estimate approval; Purchasing services or licences; Unagreed access to private systems; Guaranteed business metrics
09Why choose this option?
Task review: Clarify the outcome, data and constraints. First stage: A bounded stage with an independent result. Project: Several stages with checkpoints.
10Why KILENI?
Before starting, we record the baseline, scope, timing, price and acceptance criteria. For this service, the handover includes: Task boundaries; Recommended approach; First-stage scope.
11What happens next?
Complete the short brief for “Other task”. If the option is unclear, choose “Not sure” and we will start by defining the task boundaries.
Questions about the service
Can the exact solution be unknown?
Yes. Describe the situation and desired result; we will propose an approach after clarifying the constraints.
Can we start small?
Yes. The first stage should produce an independent result you can verify.
When is price confirmed?
After the short brief and a list of required inputs.
Next step
Describe the task — get a sensible scope
Before work starts, we state scope, timing, price and exclusions.