Could customers check their own updates online?

Which questions could customers answer themselves?

Look through a recent set of enquiries. Separate questions where the answer is already available from those where someone needs to investigate, explain a change, or make a decision.

Imagine an equipment-repair business. Customers ask whether their item has arrived, whether an estimate needs approval, and whether it is ready to collect. This is an invented example, not a business we have researched or a client result.

A clear received notice might answer the first question. A place to see the current estimate and its next step might help with the second. A customer worried about a changed price may still want to speak with someone.

Write down the task a customer could finish. “See whether I need to approve anything” gives you something more useful to test than “put our jobs online”. Also check whether clearer emails or a change to your existing process would solve enough of the problem.

What would a useful customer view show?

Keep the view close to what the customer needs to know or do. Internal notes may contain shorthand, tentative plans, or information that needs explaining before it is shared.

In the repair example, a customer could see a short description of the item, its current progress, any decision waiting for them, and how to contact the team. The following table is a planning example; its labels do not describe an existing product.

If you cannot give a reliable completion date, say what is known and when the customer should expect another update. Showing when information was last checked can help someone judge whether they need to contact you.

Would customers need another account?

Consider how often people would return. A repeat customer managing several jobs may have a different need from someone checking a single repair. Ask your software partner to explain the available ways to give each person access and the tradeoffs for your situation.

Whatever approach you choose, agree who should be able to see each job and document. A customer might want a colleague or family member to help, but that should be a deliberate choice. Ask what happens when a link is forwarded, an email address changes, or access needs to be removed.

During testing, use made-up customers to check that one person cannot open another person’s information. You can ask the developer to demonstrate that without learning how the software is built.

Keep a route to personal help. Someone who cannot get in still needs a way to check their job; access problems should not leave them without an answer.

Can your team keep the information current?

An attractive page will not help much if staff have to remember to update it separately after every conversation. Follow one ordinary job through your business and identify when the customer-facing information would change.

For the repair business, who confirms receipt? Who records that an estimate is awaiting a decision? Who is allowed to say the item is ready to collect? Agree those responsibilities before promising customers that they can rely on the page.

Ask whether the information can come from records your team already maintains. If it needs a separate update, include that work in your plan. A small number of dependable updates may be more useful than a detailed timeline nobody has time to maintain.

Also agree what happens when the information is wrong or unavailable. Staff need a way to correct it, and customers need an explanation that fits the situation. Avoid presenting an old expected date as a fresh promise.

How could you try it on a small scale?

Start with sample screens and a realistic task. Ask someone to find out whether a decision is waiting for them, locate the right document, or work out whom to contact. Use fictional details so no customer information is exposed during the demonstration.

Let them try without explaining every step. Notice unfamiliar words, missing details, and places where they would still pick up the phone. Those observations can change what you need before you commission a larger build.

If the idea still looks useful, agree a limited trial with a small group of willing customers. Explain what is available, how current the information will be, and how to get help. Keep your ordinary service available while you learn.

Choose one kind of job or one part of the process for that trial. You do not need to add online payment, appointment changes, messaging, and every historical document at the same time.

How will you decide whether it is worthwhile?

Look at whether customers can finish the task and whether the information stays dependable. A lower email count alone could mean people found the answer, gave up, or called instead.

For your trial, note which questions still reach the team, whether customers need help using the page, and whether staff are spending more time maintaining information. Include corrections and access problems in that account.

Ask customers what they still could not find. Ask staff whether the area helps them answer the remaining enquiries or creates another place to check. Keep the customer’s result and the team’s workload in the same discussion.

You may decide to expand, simplify, improve the underlying process, or stop. A useful software partner should help you choose a next step based on what the trial shows, rather than treating every extra feature as progress.