Specifying a digital service: what happens after the customer hits send?

To specify a digital service, define the promise customers receive and the work required behind the screen to keep it. A form available at any hour does not promise service at every hour. Before commissioning development, decide when a request counts as received, who owns the next step, what customers see while waiting and how completion is measured. These product and operational decisions determine the system the development team needs to build.

Start with the promise before designing the screen

According to HSBC’s archive, Midland Bank launched First Direct at midnight on 1 October 1989 as a telephone bank, offering access around the clock throughout the year. This is the bank’s historical story, not a Julius project. Our interpretation is that when the service channel is the product, its availability promise must also shape the work behind it.

For a software buyer, the starting point is the sentence the customer hears. “You can leave a request at any time,” “an agent will respond the next working day” and “your request is handled immediately” require different processes. If that sentence stays vague, a designer may build a success message, a developer may save a record and a customer may understand that the matter has already been resolved. Each participant completed their task, but the service is still not defined in a way anyone can test.

Separate receipt, handling and completion

Write down the states a request passes through, even if people update some of them manually at first. An example process might distinguish a request sent from the browser, a request stored in the business system, a request assigned to an agent and a request closed after handling. This is a proposed structure, not a mandatory list for every business. For each transition, define who may perform it and what evidence proves it happened.

A successful technical response, for example, does not always prove that an actionable enquiry exists. Ask for a demonstration in which an agent finds the request in their working system and understands the next action. If there is a delay between receipt and visibility to the agent, decide how it is represented and who detects an unexpectedly long delay. Also plan for what did not happen: does the customer know submission failed, and do their entered details remain on screen so they can try again?

What we verified in the Julius website’s enquiry integration

During the Julius website release check on 15 October 2026, we verified that the Hebrew and English service forms saved test enquiries in CodeManage. The records were read back from the system, and with analytics consent present, an enquiry-save event was also observed in Umami. This is a documented integration check on our own website, not a business conversion rate or a client outcome.

The important distinction is that a saved enquiry is not yet a booked call. Measurement therefore describes the action that was demonstrated: saving to the CRM. Measuring meetings requires another event based on an appointment actually being booked. Similarly, a booking product should distinguish a booking request from a confirmed reservation. Interface labels, reports and tests should describe the same reality; otherwise, the team may improve a metric that does not represent its promise to customers.

Define a service target that can be measured

Choose one action the user wants to complete and describe what successful completion means. Google’s guide to service objectives explains the distinction between a service indicator and a target for it. Use that distinction when talking to developers: what is being measured, what target is desired and over which time window? Avoid copying a provider’s number without understanding the action it measures and what its calculation includes.

In a hypothetical enquiry system, you could measure the proportion of valid requests successfully stored and delivered to the handling queue. Separately, you could measure time to a human response. Duplicate submissions, incomplete enquiries and test messages need clear definitions so they do not distort the report. Write down who investigates a missed target and what they can do about it. A chart with no owner responsible for acting on it cannot replace a service process.

Plan for the night shift and the busy day

Walk through a day when the service agent is unavailable with your software partner. Does the system simply collect requests, offer an alternative or escalate an urgent request to someone on call? That decision must match actual staffing. If immediate handling is not promised, the text beside the button should explain what happens after submission. Check the backlog after a weekend as well: how are long-waiting requests found, and how do you prevent the latest arrival from hiding older requests?

If you add an AI agent, define which actions it may finish independently and when it must hand off to a person. An automatically generated answer does not prove that a request was handled, especially if the action needs business approval. Our guide to choosing AI developers expands on defining boundaries and success criteria. Start with the service decision, then choose the appropriate way to automate it.

What should you bring to the specification meeting?

Bring a real request, an example exception, the message customers currently see and the identity of the person who continues handling it. Ask the team to walk from submission to closure and mark points that lack either an owner or evidence of success. During technology product specification, that journey can become acceptance criteria: what appears, what is stored and how the service team checks the outcome.

Before approving development, run a short tabletop exercise with a business representative and the development team. Give them a request that fails halfway through and ask who can see it and how they continue without losing the customer. Through Julius development services, you can start with this process and choose a scope that fits your business. The useful outcome of that conversation is a clear promise you can deliver and test, together with the system that supports it.