AI Job Status: Accepted Is Only the First Step

A customer uploads a recording for an AI transcription service. The page immediately shows a green tick and says the request was successful. Ten minutes later there is still no transcript. The customer tries again, creating a second request, and contacts support. The service may have recorded the first upload correctly. The problem is what its confirmation led the customer to believe.

For a small business, the fix starts with a question: what can the customer do now? If the answer is ‘wait’, the screen should tell them the request was received, where to check progress and what to do if it stalls. Save ‘ready’ for the point at which they can actually open the result.

A receipt and a result are separate promises

The internet standard HTTP Semantics (RFC 9110, June 2022) gives a precise example. A response of 202 Accepted means a request was accepted for processing and that processing is still incomplete. The request might ultimately be acted on or might not. The standard recommends that the response describe the current state and point to a way to monitor it. This is about the meaning of a specific response code; a particular supplier’s API documentation still determines what it returns and how to check the result.

The distinction can exist even where the integration never uses that code. For example, the AWS Step Functions documentation for DescribeExecution shows that a request for details can succeed while the workflow it describes has its own status. That separation helps explain why a green integration log alone tells a support team very little about what the customer received. Look at the status of the work itself, and then check the handoff.

Decide what ‘ready’ means from the customer’s side

Suppose the transcription service creates a file successfully, but the customer’s download link points to an old location. The processing team may reasonably count the job as complete. The customer still cannot use it. If the product has a review step for proper names or confidential details, the transcript may also exist before anyone is willing to release it. Those are two different gaps, and a useful status model preserves both.

Write the definition of ‘ready’ using an action: the customer can open the transcript for this recording from their account. That gives the team something to verify after a change. It also helps decide how to display a notification failure. If the file can already be opened from the account, a failed email is a communication problem. If the link is the only way to access the file, the same failure blocks delivery.

Apply the same logic to a creator’s private workflow. A captioning tool might finish generating a draft, but the job you care about is publishing captions on the intended video. Call the intermediate result ‘draft available’. Doing so lets a collaborator distinguish between the model’s work and the action they are expected to take.

Tell people what to do while they wait

A progress view does not need to expose every worker and queue. A customer usually needs to know whether the request exists, whether they have to intervene, and where they can find the result later. Provide a reference or a stable place to check. If the system cannot estimate the remaining time reliably, give an honest status and a point at which the customer can ask for help. A precise countdown without supporting information can create another promise you cannot keep.

Think through recovery before adding a retry button. If a customer returns after a network interruption, can they see the original request? If it failed, can support distinguish an upload problem from a failed transcript or a broken download? When a retry is appropriate, make clear whether it resumes the existing job or starts another. The label should match what the system actually does.

Test the stages that a success screen can hide

• Acceptance: Submit a request and check that the acknowledgement gives the customer a useful place to return.
• Processing: Simulate a delay and a failure. Confirm that the status stays accurate and the customer can tell whether any action is required.
• Delivery: Open the finished output as the intended customer. Verify that it belongs to the right request and is actually accessible.
• Recovery: Try closing the page and returning later. Check whether the customer can pick up where they left off without submitting again.

Keep the counts separate in an internal review. For a defined group of requests, ask how many were accepted, how many finished processing and how many reached a state the customer could use. Show how many are still waiting. Otherwise a batch that has only just arrived can make the delivery figures look worse than they are. Our article on counting jobs and attempts separately explains why retries also need their own measure.

Start with one status message in one workflow. Read it as if you were the customer and had no access to the logs. Then follow the next action it suggests. If the page says the work is ready, you should be able to use it. If you cannot, the message is describing a milestone the customer was never waiting for.

Sources

• IETF, RFC 9110: HTTP Semantics, §15.3.3 (June 2022).
• Amazon Web Services, Step Functions DescribeExecution API reference.