Developing services

Customer self-service without losing personal service.

One customer wants to check an order after hours. Another prefers to call because a requested product change is difficult to explain. Both expect you to understand the order and help them move forward.

A portal can give the first customer freedom. It can frustrate the second if a sequence of forms stands between them and someone who can help. The design question is not how much contact can be automated away. It is which tasks customers want to handle themselves and where your attention makes the difference.

Illustration of a customer consulting information independently, with a staff member nearby for a substantive question.

Self-service where it works, personal contact where it adds value.

Start with a responsibility the customer actually wants

Checking delivery progress, uploading a drawing or repeating an earlier order can be useful self-service. But transferring an administrative task to the customer does not automatically make it convenient.

What does the customer gain: a reliable delivery date, access to the right product information or less repetition? If the main benefit is less data entry for your office, investigate whether the journey also makes sense from the customer’s side.

Speak with a few existing customers about when they contact you and what they need at that moment. That is a better starting point than a portal containing every possible menu.

Choose one of three approaches for each task:

Task What the customer needs to understand
Complete it directly, such as downloading an available document The result is available immediately; no review follows
Submit a request, such as asking for a non-standard product The request has arrived, who reviews it and what happens next
Discuss it together, such as an uncertain technical specification How to reach a specialist and which information they already have

Explain what each action commits the business to

“Submit” can create different expectations. Has the customer requested a quotation or placed an order? Is the displayed price an estimate or an agreed amount? Does a change to the specification need technical approval?

Make the distinction explicit. The confirmation must match what the business can deliver. Where a person needs to review the request, explain the next step.

This depends on clear information behind the interface too. A portal showing one delivery date while the warehouse sees another creates uncertainty for the customer and for the employee who receives the subsequent call.

Let a conversation continue the same story

Moving from self-service to a conversation is part of the product. With appropriate permissions, the employee should be able to see what the customer attempted, what information they supplied and which agreement is involved.

Avoid asking customers to start again because the digital channel is disconnected from the service team. Employees also need enough authority to act. Being able to view the portal offers limited help if a straightforward correction must still be passed to someone else.

Personal service and self-service are not competing models. They can use the same agreements and information while offering different kinds of support.

Build the service behind the portal

In Schoonmaakwoede, customer ordering connects with pricing, availability, partner scheduling and field delivery. The booking interface belongs to a wider service operation.

The same questions apply to another business considering a portal. Who maintains the available choices? What happens when an agreement changes? Who handles an exception? Can a colleague establish what the customer was promised?

Answer these questions before making a digital journey more persuasive than the operation behind it can support. A thoughtfully designed interface needs an equally thoughtful delivery model.

Also establish who the customer is acting for. In the digital healthcare platform, a user can start a consultation for themselves or a family member. We worked on the API, client application and integration with the external communications service. A business portal may raise a similar design question when a contact orders for several branches: access to an account does not automatically authorise every action.

Test the unsuccessful journey too

Try a repeat order, a request with an incomplete specification and a change outside the available options. Ask customers and employees to work through each situation. If the portal serves several markets, include the language and product information those customers actually use.

Can the customer understand what happened, identify the next step and reach a person when needed? Does the employee have enough context and authority to help?

Our customer and partner portal work includes that connection. If customer details, prices or statuses sit in different systems, also explore systems integration. The aim is a business that is easier to reach and deal with, with employees able to give their attention to the conversations where it matters.

Your next step

What do you want to make possible?

You do not need a software specification to start.

Talk about your next step