Decide Whether a Service Request Is Ready to Start

Substantively revised October 20, 2026. Author interpretation, documented cases and hypothetical examples are distinguished below.

Direct answer

A submitted request is ready for delivery only when its essential inputs are accessible, interpretable and sufficient for the specific next step. Name that step, inspect the inputs and record the missing condition before promising a delivery date. A form marked complete proves that someone submitted fields. It does not prove that a designer can open the source file, that an analyst understands the column meanings or that the customer has permission to supply the material.

Use a short readiness decision: ready, clarification needed, discovery required or declined. Keep receipt time visible in every state. If your service excludes customer waiting time from a delivery target, state precisely which clock pauses, what caused the pause and what will restart it. Never turn an internal pause into an unexplained disappearance from the customer's view. This is an operating method for bounded service work, rather than advice about the legal effect of an agreement.

Key takeaways

Readiness belongs to a named work step. A request can be ready for diagnosis while remaining unready for implementation. Treating those as separate commitments lets a team investigate uncertainty without quietly promising a complete solution. The practical question is what the team can responsibly do with the evidence currently available.

Required fields, accessible artifacts and usable instructions are different checks. Start with the smallest information set that changes the next decision. Give missing inputs a named owner and an observable completion condition. Count clarification effort and waiting time even when the delivery timer is paused; otherwise an apparently efficient service can conceal a costly intake process.

All quantities in the worked examples below are illustrative choices, not industry benchmarks. The proposed Request Readiness Card is my synthesis. The cited sources document specific mechanisms and service practices; they do not validate this framework or report outcomes from using it.

Definitions and relationships

A request is a statement of desired work. An input is an artifact or fact needed to perform a specified step. A readiness condition is a test of whether that input supports the step. Acceptance is a later judgment about delivered work. Confusing readiness with acceptance causes friction: accepting a request for assessment should not imply accepting the finished output before it exists.

Receipt time records when a request arrived. Active handling time records the team's work. Elapsed time includes waiting. A service target defines which events and calendar govern a measurement. These quantities answer different questions. A customer deciding whether to pursue an alternative needs elapsed time even when the supplier's internal target excludes periods awaiting information.

The requester, intake reviewer and delivery owner may be different people. The requester supplies context; the reviewer checks whether the next step is possible; the owner commits resources. A small practice can combine these roles in one person, but the decisions should still be distinguishable. A conversation that feels encouraging should not silently allocate a production slot.

Observation: the request arrives before the work exists

A familiar service failure begins with a polite acknowledgment. A customer uploads a spreadsheet and asks for a report by Friday. The team says it has everything. On Thursday an analyst discovers that account identifiers have been rounded and that the file contains only the current month. The obstacle was present at receipt, but the promise was made before anyone inspected it.

The expensive mistake is not that the analyst encountered uncertainty. Service work contains uncertainty. The mistake is assigning the uncertainty to the delivery phase while describing the request as settled. Every later question then sounds like a delay, even when it is the first serious examination of the material. Trust falls because the customer's expectation and the team's actual knowledge diverged early.

Look for repeated requests whose first substantive action is asking for something obvious: an editable file, an error message, a target audience or access to the relevant environment. These are candidates for intake checks. Do not add every imaginable question to a universal questionnaire. A long form can postpone the same uncertainty while teaching customers to enter placeholders just to reach a human.

Root cause: completeness is being checked at the wrong layer

Field validation can establish whether a response exists or meets a format. It cannot establish every property needed for delivery. A URL may be syntactically valid yet inaccessible to the assigned worker. A description can be lengthy yet omit the decision the customer wants to make. A filename ending in CSV says little about whether its records represent the population the report requires.

The next layer is operational interpretation. Someone must connect the material to a concrete action: reproduce the fault, calculate the requested result or edit the specified document. The relationship matters more than the apparent polish of the submission. A rough screenshot may be sufficient for preliminary diagnosis while a beautifully organized archive remains inadequate for a specific reconstruction.

There is also a policy layer. A team may be able to open a file but should not handle its sensitive contents through that channel. Readiness must include permitted handling where relevant. Record the boundary and offer the approved alternative without copying unnecessary material into the readiness card. More data is not automatically better evidence, especially when the team cannot justify retaining it.

Framework: the Request Readiness Card

The card has five components: Next Step, Necessary Inputs, Inspection, Missing Condition and Commitment. Keep each component brief enough to review during an ordinary intake conversation. Its purpose is to make a start decision inspectable, not to create another document that no delivery worker reads.

Next Step names a bounded action and its output. Write “reproduce the reported sign-in failure on the test account” instead of “fix authentication.” Necessary Inputs lists only what that action requires: environment, reproduction sequence, expected behavior and an approved test account. If those are unavailable, a separate discovery task may still be possible. The card should make that option visible rather than classifying the whole relationship as impossible.

Inspection records what was actually checked, by whom and when. “Opened file” is weaker than “opened version 4 with the assigned account and verified the three referenced tabs.” Do not claim comprehensive verification after a sample. If only a sample was inspected, name its scope and the remaining uncertainty. The next worker should be able to understand both the finding and its limits without repeating the entire conversation.

Missing Condition identifies an observable obstacle and its owner. “Waiting on customer” is too vague. “Requester must supply the month-end extract containing the transaction identifier column” can be acted on. If the team cannot yet specify the needed artifact, assign a diagnostic question to the reviewer rather than asking the customer to guess what technical information would be useful.

Commitment states what starts now, what remains provisional and what will trigger a fresh decision. A ready card might authorize a two-hour diagnostic session without authorizing implementation. A clarification card might reserve no production capacity until the missing input is checked. Tell the customer which interpretation applies; a private board status cannot repair an ambiguous public promise.

Three documented examples and their limits

GitHub issue forms provide input types and validations, and convert submitted responses into an issue body. This is a concrete example of structured intake, with useful separation between form mechanics and later discussion. A required response can reduce omissions. The documentation does not establish that the submitted reproduction is correct or that the issue deserves implementation. Those remain review decisions. [S1]

Atlassian documents separate start, pause and finish conditions for Jira Service Management SLA measurements. Waiting for a customer response is an example of an optional pause condition. This illustrates how a measurement can depend on explicit events. Configuring a pause does not determine whether the customer has received a useful explanation or whether the underlying service promise permits excluding that time. [S2]

The UK Government Service Manual describes discovery as a phase for understanding a problem before committing to build. It explicitly treats stopping after discovery as a reasonable outcome when research supports it. That is a documented alternative to pretending that every request is implementation-ready. Its public-service context differs from a small commercial engagement; use the decision distinction without importing its process wholesale. [S3]

Together these examples expose separate control points: collecting information, measuring events and deciding whether delivery is justified. No single tool performs all three. A service can have an excellent request form and still make weak commitments if staff treat submission as approval. The card connects the decisions while leaving their evidence separate.

Case study: a report request with an unusable extract

Consider a hypothetical two-person analytics service. A customer requests a customer-retention report for a board meeting. The first file contains 240 rows. A reviewer opens it successfully but notices that the extract has no observation date. The customer has supplied a file; the service cannot yet determine which customers belong in the requested comparison. These numbers and events are invented to demonstrate the method.

The card names the next step as checking whether the available data supports the comparison, not producing the final report. The necessary inputs are the two period boundaries, stable customer identifiers and the meaning of the status field. Inspection finds that identifiers exist but period coverage is unresolved. The missing condition is a dated extract or an explanation of the export filter, owned by the requester.

Suppose the service spends 20 minutes inspecting the request, waits 18 elapsed hours for clarification and spends another 15 minutes checking the replacement. Handling time is 35 minutes; elapsed time is longer. Both belong in the operational record. The team should not describe the engagement as a 35-minute experience if the customer is deciding whether there is still time before the meeting.

After clarification, the owner accepts a narrow report describing the available periods and exclusions. The revised commitment names the deliverable and the actual start event. If the necessary comparison remains impossible, the team can offer an explicit feasibility note instead. That is a different output with a different price and acceptance decision, rather than an inferior report quietly presented as equivalent.

Application: design the handoff, then choose the form

Begin with three recent requests that caused avoidable clarification. Reconstruct the first action a competent worker attempted and the input that blocked it. If all three stalled because shared links were inaccessible, an access rehearsal is more useful than adding five background questions. Test the link with the role that will perform the work, without widening permissions beyond what the task requires.

Separate intake evidence from ongoing commentary. The card should point to the current authoritative artifact while the conversation retains the history. If a customer replaces a dataset, identify the new version and review the relevant readiness condition again. An earlier ready decision cannot automatically cover a changed input merely because the ticket number stayed the same.

For recurring services, publish a small example of a usable request. Explain which details are required for diagnosis and which become necessary only for production. A customer facing an unfamiliar technical problem may not know the correct vocabulary. Offer an assisted route that gathers the same decision evidence through conversation rather than making form fluency a prerequisite for receiving help.

Failure example: the pause that never restarts

A hypothetical studio pauses a ticket while waiting for brand files. The customer uploads them in a separate email, but nobody links the message to the ticket. The SLA dashboard stays green and the job remains idle. The failure is a broken event connection, not an irresponsible customer. A pause condition without a monitored restart path can conceal abandoned work.

Define where the missing input must arrive, who observes it and how the card returns to inspection. Review paused requests by elapsed age as well as by internal target. If the team accepts several channels, it owns the reconciliation cost. Telling customers to use a channel that the service itself continues to bypass will not create a reliable process.

Tradeoff and counterargument

An objection to readiness checks is that service professionals are paid to handle ambiguity. That is often true. The response should be a bounded discovery commitment, not a demand that the requester solve the problem first. A specialist can accept “investigate why this export fails” when accepting “deliver the complete migration tomorrow” would be irresponsible. The method distinguishes those promises.

Inspection also consumes time before revenue is certain. Use risk to size it. A low-consequence formatting task may need a quick opening check. An irreversible operation on important records needs stronger evidence and an explicit authorization boundary. Reject ceremonial completeness: if a field never changes a start decision or prevents a known failure, remove it and see whether intake improves.

Common mistakes

Do not treat a default dropdown value as a verified fact. Ask whether the requester deliberately chose the relevant environment. Do not require passwords or private keys as convenient intake fields. Use the approved access method and reference the authorization rather than reproducing secrets. Do not silently reinterpret a missing input as permission to make an assumption with consequential effects.

Avoid a single “ready” status for every department. A request can be ready for estimation while awaiting material for delivery. Label the transition that was approved. Avoid restarting the arrival clock each time a customer resubmits; preserve the original receipt and show the new inspection separately. Otherwise the dashboard rewards administrative resets while hiding the customer's actual wait.

Action plan

Today, choose one recurring service and write its first executable step in a sentence. Name the inputs that step actually needs. Inspect one current request with the delivery worker and record one concrete finding for each necessary input. If the request cannot proceed, send a specific missing condition and explain which commitment remains open.

During the next week, review every clarification loop for that service. Record the question, handling minutes and elapsed delay. Improve the single recurring omission that creates the most consequential confusion. Keep an assisted path for customers who cannot answer the form. Test receipt, pause, response arrival and restart using a harmless rehearsal request before relying on dashboard timing.

At the next review, ask whether any request labeled ready still required a basic opening check before useful work could begin. If so, move that check earlier or narrow what “ready” promises. Keep decisions small enough to change when evidence changes. A readiness system earns its cost when it prevents a false commitment without forcing a customer to complete a second project just to ask for help.

FAQ

Is a completed form enough to start?

Only if its contents satisfy the next step's actual conditions. Required fields establish presence. Access, meaning, scope and permitted handling may still require inspection by someone who understands the work.

Should we inspect every uploaded file?

Inspect what the immediate commitment depends on. If sampling is appropriate, record the sample and uncertainty. Do not promise complete coverage when the decision rests on a small selection of artifacts.

What if the customer does not know what is missing?

Offer a diagnostic step with a defined output. Ask for observable symptoms and available context. Do not make the customer invent a technical diagnosis merely to get the request through intake.

Does readiness mean the final scope is fixed?

No. It means a specified next action is justified. Estimation, diagnosis and production can have different readiness conditions and should be described as different commitments where uncertainty matters.

Can clarification time be excluded from a target?

That depends on the actual service arrangement. Operationally, identify the target, pause reason and restart event, and retain elapsed time so the customer's experience remains visible alongside internal timing.

Who decides whether an input is usable?

Assign that decision to a reviewer competent in the next action. The requester can confirm intent, but a delivery worker may need to verify access, format and interpretation before committing resources.

How many questions should intake contain?

Enough to resolve the consequential start decision. Review unused answers and repeated clarification loops. A shorter form with a real inspection can be more effective than an exhaustive questionnaire filled with guesses.

Should we reserve capacity while waiting?

State the policy explicitly. A reservation can be useful, but it has a cost and may expire. Do not let a friendly acknowledgment imply a guaranteed slot that nobody has allocated.

What happens when the input changes?

Identify the replacement and recheck the affected conditions. Preserve the earlier record rather than pretending the first assessment covered material that did not exist when the reviewer made it.

Can an emergency bypass the card?

Use an explicit emergency route with its own minimum evidence and authority. Record the uncertainty and the action authorized. Urgency changes the decision boundary; it does not make missing facts become known.

Is this useful for internal service teams?

Yes, when colleagues make consequential delivery promises from incomplete requests. Keep the method proportionate and avoid making internal customers perform administrative work that the receiving team can resolve more easily.

Where should sensitive information go?

Into the approved system with appropriate access and retention. The card can reference that system and record the check without copying confidential contents into a broadly visible queue or discussion thread.

What should a blocked-request message contain?

The missing artifact or answer, why it matters, who can provide it and what happens when it arrives. Include the current effect on timing so the requester can make a practical choice.

How do we detect an overstrict readiness rule?

Look for requests repeatedly rejected for details that delivery workers never use. Observe assisted intake and compare outcomes. Remove friction that does not improve the decision or prevent a consequential failure.

What is the smallest useful record?

One named next action, the critical input, an actual inspection finding and an explicit commitment. Add ownership and restart details whenever work must wait. A clear short record beats an untouched long template.

Recommended books

The Mom Test by Rob Fitzpatrick is useful for examining whether questions produce evidence or agreeable conversation. Read it when your request form elicits reassuring but unusable answers. It is not a technical specification for service intake or a substitute for inspecting artifacts.

The Checklist Manifesto by Atul Gawande offers a way to think about concise checks at consequential moments. Its medical and organizational examples should not be treated as measured results for your own service. Use it to challenge an overlong intake checklist that obscures the decisive conditions.

Good Services by Lou Downe is a practical companion for considering the whole experience rather than optimizing an isolated internal step. It is particularly relevant when a supplier's timing dashboard improves while customers still cannot tell what to do next or whether anyone owns their request.

Further exploration

Trace one request from first contact to the first useful delivery action. Mark every assumption that became a promise before inspection. Ask the receiving worker which fact would have changed the start decision. Then compare that answer with what your form currently requires. The difference is a concrete redesign opportunity, not a reason to add another universal questionnaire.

Primary evidence sources

• [S1] GitHub: Syntax for issue forms
• [S2] Atlassian: Set up SLA conditions
• [S3] GOV.UK: How the discovery phase works

Related concepts: systems thinking, wealth structure, and the survival loop. Read the editorial policy and citation guide.