From proof of concept to a service customers can use

What happens when the builder leaves the room?

The demonstration works. Its creator knows which settings to use and how to fix a problem quickly. Then the first customer asks how to get started, who to contact for help, and what happens if the service stops working.

A proof of concept shows that an idea can work under selected conditions. Turning it into a service means making the whole experience dependable: setup, everyday use, support, changes, and exit. The next step is to test whether your team can deliver that experience consistently.

Define the customer and the promise

Describe the intended customer, the problem you solve, and the result they can expect. Explain what is included, what the customer must provide, and which situations the service does not support. A clear offer helps customers decide whether it fits their needs.

Compare the service with the customer’s current approach, such as a manual process or another supplier. The improvement needs to justify the cost and effort of changing. More features will not resolve an unclear promise.

Map the customer journey and the work behind it

Write down what the customer does at each stage and what your team must do to make it work. Review the journey with the people responsible for delivery, support, and sales.

• Choosing the service: who is it suitable for, and what must be confirmed before accepting a customer?
• Getting started: what information, permissions, and setup are needed?
• Everyday use: how does the customer receive and recognize the promised result?
• Getting help: how do customers report problems, and who responds?
• Changes and exit: how are updates, cancellation, data handover, and access removal handled?

Give the delivery team clear responsibilities

Name an owner for each stage and allow time for the work. Decide who keeps instructions current, watches for problems, responds to customers, and approves changes. If routine delivery needs the builder’s constant attention, identify which instructions, tools, or training are missing.

Ask someone other than the builder to follow the setup and support instructions. Include a normal task and a failure scenario. Check that they can recognize a problem, reach the right person, and explain what happens next to the customer. Promise support hours and response times that the team can meet.

Check readiness before accepting customers

Agree what must be demonstrated before launch. Test the full customer journey, common errors, expected demand, and recovery from relevant failures within authorized systems and agreed conditions. Record the results and unresolved issues.

Google’s SRE guidance describes coordinated launch reviews and practical checklists across the teams involved. Apply that principle at a scale that fits your service: bring the responsible people together and review evidence for the promises you plan to make.

The table below is a starting point. Replace the example roles with named people and adapt the evidence to your service. One person may hold several roles, provided they have enough time and support.

Sources: Google SRE: Reliable Product Launches at Scale

Example: a customer joins a traffic-protection service

Imagine a website owner considering a service intended to filter unwanted traffic. A prototype demonstrates that it can block a selected request. The following journey describes proposed delivery steps and checks, not completed production validation or a proven protection level.

Joining: the delivery lead confirms the website is suitable, records the customer’s main user journeys, and agrees who may approve routing changes. Before any change, the team documents how to reverse it and how to contact the customer if problems occur.

Using the service: the team checks that legitimate visitors can browse, sign in, and submit forms where applicable. It measures added delay and verifies how alerts reach support. Filtering accuracy, performance under expected demand, and behavior during supplier failures remain unverified until the relevant tests produce evidence.

Getting help: if a legitimate visitor is blocked, the customer needs a clear reporting route. The support owner investigates, communicates progress, and follows an approved correction or reversal process. Test that handoff before launch, including what happens when the original builder is unavailable.

Check what the service costs to deliver

Estimate setup time per customer, hosting and license costs, monitoring, support, customer updates, and ongoing improvements. Include staff effort even if the builder currently handles it informally. Compare what happens with more customers, more support requests, or higher supplier charges.

Keep the offer within what the team can deliver. State the included setup and support, any customer responsibilities, and how additional work is agreed. Use the cost and workload estimates to decide how many customers you can support at the proposed price.

Make a clear launch decision

Review customer usefulness, test results, team capacity, and the offer together. Record the decision and who is responsible for it. An unresolved issue may call for a smaller pilot, a narrower service, or more testing before launch.

• The intended customer and service scope are clear.
• Agreed checks have results, and unresolved issues have owners and an explicit decision on whether they block launch.
• Setup, support, monitoring, and recovery procedures have been demonstrated.
• Costs and available staff support the offer and proposed customer numbers.
• Someone owns the launch, monitors early use, and has scheduled the next review.

Use the first month to improve delivery

Before launch, schedule an early check-in and a review at the end of the first month. Treat this as a starting cadence: review sooner when problems affect customers, and do not wait for a meeting to respond. Compare actual delivery with your assumptions.

Ask to see: A short first-month review with actual results, the three most important improvements, named owners, and a date to check progress.

• Getting started: where did customers stall, and how much staff help did setup require?
• Support: which problems repeated, how long did they take to resolve, and did customer updates match the promised process?
• Customer use: could customers complete the intended tasks, and what feedback shows whether the service helped?
• Delivery cost: what did setup, infrastructure, and support actually cost per customer compared with the estimate?
• Next changes: which fixes come first, who owns them, and should you expand, hold at the current size, or pause new onboarding?