A group website should help a visitor identify the right business and understand who owns the next conversation. For a leadership team, the useful question is whether that responsibility stays clear when the visitor moves from the parent website to a company, or arrives without knowing which company to choose.

Vinove's public pages offer a concrete starting point. A review on 28 October 2026 found two different entry paths: the companies page starts with business outcomes, while the contact page separates group enquiries from direct service and software routes. That is an observable design choice. It does not, by itself, establish what happens to a message after submission.

Read the two paths together

The companies page groups the portfolio around Build, Reach, Run, Transact and Automate. It lets someone begin with a business need rather than an existing knowledge of company names. Company profiles and onward links then provide more specific destinations.

The contact page takes a different approach. It offers a group enquiry route and directs service and software enquiries to the companies. Careers has its own route. Read together, these pages distinguish finding a business from contacting the group.

This distinction matters when deciding what a parent website should own. A portfolio explanation can help a visitor orient themselves without becoming a second sales catalogue for every company. A group contact route can serve people whose request concerns the group without making it the compulsory first stop for a product question.

The observation is limited to the public interface. No form was submitted for this review, no private enquiry was examined and no response-time measurement was made. The pages establish the offered routes, not the delivery results.

Give every route a clear end point

For a group reviewing its own website, make a small route record before changing the forms. Write down the visitor's question, the destination offered and the team expected to answer. Add the evidence that would demonstrate the route works.

  • Finding a company: check the portfolio explanation and company profile. The destination should still describe the capability implied by the link.
  • Choosing a known service or product: follow the direct company route and check that the next action is relevant to that need.
  • Discussing a group partnership: check the group enquiry route. Ask the responsible team for an authorised test receipt showing the intended recipient.
  • Applying for a role: examine the Careers route. An authorised recruitment test should reach recruitment independently of business enquiries.
  • Describing a need across companies: identify the route for uncertainty and the person responsible for deciding the next step.

This is a proposed review worksheet, not a report of Vinove delivery tests. Its purpose is to keep the visible promise and the evidence requirement beside each other. It also exposes missing decisions: if nobody can name the recipient or explain the fallback, changing the button label will not settle responsibility.

Handle uncertainty without making the visitor reorganise the group

Some visitors know their problem but cannot name the relevant company. Give them a way to describe the intended outcome and any important constraint. The first person receiving that request needs a defined responsibility for clarifying it.

For example, a hypothetical organisation may want both a new customer application and a better way to manage billing. The first conversation should establish whether these are connected requirements, separate purchases or an unclear brief. A portfolio page cannot settle that question on its own.

The practical decision is who takes responsibility while the destination is uncertain. Record that decision internally and make the visitor-facing next step understandable. Avoid implying that every enquiry will automatically involve multiple companies, or that the parent offers every service itself.

Test the promise at the point of handover

A useful review follows a small set of routes from the page to the receiving team. Begin with the public experience: is the link understandable, does it reach the intended destination, and can the visitor see what to do next?

Then have the responsible team run an authorised delivery test where a form is involved. Use synthetic details and preserve the receipt. Check the actual recipient and the context received. A successful browser message is only one part of that evidence.

Keep recruitment checks separate from business enquiries. A routing review should not circulate real applicant information or customer messages simply to demonstrate that a process exists.

Finally, distinguish a working route from a measured service outcome. Receipt evidence can establish arrival. A response-time claim needs its own defined measurement. Neither should be inferred from a screenshot of a contact page.

Keep a handover record small enough to use

A practical handover record can fit in a short note. Record the visitor's stated need, the source route, the proposed destination, the reason for that destination and the person responsible for the next action. Include only the information that person needs to continue the conversation.

The stated need and the proposed destination deserve separate fields. A visitor may have reached a software page while describing a requirement for custom development. Keeping the original wording prevents the arrival page from silently becoming the qualification decision. The receiving team can see both the context and the reason for the recommendation.

Use a clear internal state for an unresolved destination. "Sent onwards" tells the first team what it did; "accepted by the receiving team" tells it something different. Agree which state ends the first team's responsibility. This is a proposed control for the reader's organisation, not a claim about Vinove's internal workflow.

Avoid promising a deadline simply because a template has a field for one. The receiving team should agree the expectation before it becomes a visitor-facing commitment. If a request needs further clarification, record who will ask and how the conversation will stay connected to its original context.

Review a difficult example before adding automation

Use a hypothetical request with two plausible destinations during an internal walkthrough. Have the first team explain its choice, then ask the receiving team what it would need to proceed. If the teams disagree, capture the decision that is missing rather than building an automatic rule around the disagreement.

For instance, the billing and customer-application example may need separate discovery conversations. The record should explain that choice and who coordinates the next step. It should not imply that a shared parent automatically means shared scope, access to information or a combined commercial commitment.

Once the responsibility is understood, an organisation can decide which steps merit automation. Keep the purpose concrete: preserve context, deliver to the agreed destination or highlight an unresolved handover. The operating decision comes first. The public website is one entry point into that decision, not evidence that all of its consequences have been resolved.

Review responsibility when the portfolio changes

Revisit the route record when a company changes its offer, a destination moves or the receiving team changes. Update the explanation and the handover together so that an accurate company directory does not point to an outdated next step.

For Vinove, the public distinction between outcome-led company discovery and group contact provides the starting evidence. The broader operating lesson is to keep discovery, destination and receipt separate in the review, and connect them through a named owner. Explore the Vinove companies to see the public discovery path; use the worksheet to examine the responsibilities behind your own.