A request is ready, but nobody knows who should take it next. That moment is a better starting point for a workflow business than an enormous list of automation features. A product built around one difficult handoff can have a clear user, a visible outcome and a first demonstration that takes a few minutes. NV2 could be the company identity above that focused first product and the wider platform that follows.
Pick a handoff with a visible finish
Imagine a maintenance supplier receiving installation information from a customer’s site manager. The coordinator needs to check that the location, equipment and access details are complete before scheduling a technician. Requests currently arrive through several channels. Missing information triggers another exchange, while a complete request can wait in the same queue as an incomplete one. This is an illustrative operating problem with enough detail to investigate.
Start by defining the finish: a request that the coordinator can schedule without asking for another essential detail. Then identify the person who decides it is ready. That gives the first product a concrete responsibility. It can collect the necessary information, show what is missing and deliver a record that the next person can act on. An ambitious company can begin by doing this one job clearly.
Observe the work before drawing the screen
The public service design guidance on contextual observation recommends watching tasks in their actual setting. For this concept, use that method to examine recent requests with the people who handled them. Ask what happened, where they looked and which details were needed at each step. The research should reveal the work that the product will have to carry.
Keep a small record for each example: the trigger, the person sending it, the recipient, the missing information and the next action. Record ordinary examples as well as awkward ones. A founder who sees only the difficult request may design an elaborate exception tool instead of a useful everyday service. After several observations, draw the shortest sequence that explains a request moving from arrival to ready.
Give every state an owner
A workflow interface can show many colored statuses and still leave the team unsure what to do. Use states that correspond to a decision someone can make. In the installation example, the sequence could be received, awaiting customer information, ready for scheduling and scheduled. Each state has a named owner and a clear condition for leaving it. The product then supports a conversation the team already understands.
Write down what happens when someone is absent. Can another coordinator take the request? Does the customer see the current owner or a shared team name? Who gets notified when the same detail is corrected twice? These decisions shape permissions, notifications and the support burden. They are easier to resolve with one initial team than after several departments have adopted different habits.
Make the exception path part of the offer
The normal route is only half the product. A customer may upload the wrong equipment image, a technician may reject the access plan, or a request may be canceled after scheduling. Define a small set of exceptions with explicit recovery steps. The operator needs a way to return the request for correction while preserving the useful information already provided.
A simple activity record can show what changed and who made the change. Keep its language understandable to the people doing the work. An entry such as “access contact updated” helps a coordinator investigate a problem more quickly than an internal event identifier. Decide which entries are visible to the customer and which are for the operating team, then test the distinction using real examples.
Charge for a repeatable responsibility
The commercial unit should match the job the customer recognizes. A founder could investigate a team subscription, a location-based arrangement or a charge tied to completed requests. Begin by understanding who owns the budget and what makes usage predictable for them. A trial conversation should cover the request volume, the people involved and the support the team will need to adopt the product.
Avoid packaging every possible integration into the first offer. Choose one input path and one useful output, then establish who maintains each connection. A shared export might be enough to begin. The first customer should be able to describe the boundary: what NV2 handles, what their existing system handles and where a human makes the final decision. That description becomes the basis of a repeatable offer.
Launch with a working operating routine
A release plan needs more than a completed interface. Name the person who answers support questions, establish how a customer reports a broken request and decide how the team will recover a record that stalled. Keep a short onboarding session focused on one complete request. The new user should practice the handoff they will perform tomorrow, rather than tour every menu in the product.
Experience mapping offers a useful way to connect these steps; the GOV.UK mapping guide describes representing a user’s journey over time. A founder can adapt that perspective to the customer’s entire request, including activity outside the software. The immediate next step is to map one recent handoff with a prospective customer and choose the point where a first NV2 product would take responsibility.