A calmer operating system for a growing yacht business
Unifying fragmented enquiries, customer records and operational tasks into one accountable workflow.
The engagement is creating a shared operational backbone for a specialist sailing business. The immediate priority is visibility: one place to understand each customer journey, its current status, the next decision and the person accountable for action.
Situation
Demand had grown faster than the operating model around it. Customer information lived across inboxes, documents and individual knowledge. The team could deliver high-quality work, but maintaining a current view of every commitment required repeated manual coordination.
The issue was not a lack of tools. It was the absence of a clear system of record and a consistent progression from enquiry to delivery. Adding another point solution would have increased fragmentation.
Diagnostic
Discovery followed real customer journeys from first contact to post-project follow-up. We recorded each hand-off, decision, data field and exception. This separated genuine judgement from administrative movement and exposed where information was repeatedly recreated.
The analysis identified four connected requirements. The platform needed a dependable customer record, a visible project state, explicit next actions and a controlled automation layer. Each requirement had to support the way the team already served clients rather than impose a generic sales process.
- Create one owner for each next action
- Keep commercial context beside operational detail
- Make exceptions visible before automating routine work
Solution design
The proposed platform uses a lightweight event model. Important changes, such as a new enquiry, a confirmed brief or a delivery milestone, update the central record and trigger a defined next step. Staff remain responsible for judgement while the system handles reminders, data movement and routine preparation.
The interface is organised around the questions the team asks each morning: what changed, what needs attention and what is at risk. This reduces navigation and keeps system design anchored to operational decisions.
Delivery approach
Delivery is staged to establish trust before adding sophistication. The first release creates the shared record and workflow states. Later releases introduce document generation, management reporting and carefully bounded AI support.
Measures are being agreed before launch. They include time spent assembling status, incomplete records, overdue actions and the number of customer updates that require information from more than one system.
Current position
The work remains in progress, so no outcome claim is presented. The completed discovery and architecture phases have established a single operating model, an agreed data structure and a prioritised release plan. The next test is whether the first working release reduces coordination effort without weakening the personal service that differentiates the business.
From current operating friction to a controlled target state
The diagnostic tests the current state using observable work, then describes the controlled operating state the release is intended to create.
External evidence sharpens the engagement hypothesis
Findings are paraphrased from the linked original publications. Their scope and populations differ, so they inform the thesis rather than prove a universal outcome.
SME users most often report improved employee performance
The strongest pitch is better staff leverage inside core work, not technology adoption for its own sake.
Source: OECD, Generative AI and the SME Workforce, 2025Only a minority of UK AI users report integration with existing systems
A shared operational backbone addresses the gap between individual tool use and an accountable end-to-end workflow.
Source: UK Business Data Survey 2026Google DORA identifies organisational capabilities that amplify AI value
Clear workflows, user focus, data access and feedback loops should be designed with the application rather than added later.
Source: Google DORA, AI Capabilities Model, 2025Only a minority of businesses planning AI adoption report being ready to implement it
A focused diagnostic and delivery model can convert general intent into a governed first operating release.
Source: DSIT, AI Adoption Research, 2026The engagement is organised around four evidence-producing work packages
Each work package ends with an explicit decision and a tangible output. The sequence keeps delivery connected to operating evidence.
Journey and data model
- Decision
- What must the system know at each stage?
- Work
- Define entities, states, required fields, sources and retention.
- Output
- Approved operating and data model.
Shared operations workspace
- Decision
- What should each role see and change?
- Work
- Build customer, project, action and exception views with role permissions.
- Output
- Working first release for representative journeys.
Controlled automation
- Decision
- Which routine movements are stable enough to automate?
- Work
- Add reminders, field movement and drafts with visible rules and approvals.
- Output
- Versioned automations and exception routes.
Adoption and value
- Decision
- Has the release reduced coordination without weakening service?
- Work
- Train users, observe work, measure baselines and review feedback.
- Output
- Adoption evidence and prioritised second release.
Risks are designed into the operating model before launch
Risks become manageable when the early signal, control and accountable owner are agreed before release.
Acceptance links the release to observable operating performance
Measures are useful only when their definition is stable and their movement changes a management decision.
The diagnostic concentrates effort on coordination friction
Relative priority score from discovery workshops, normalised to 100.
Delivery follows a controlled progression from evidence to operation
Trace customer journeys, decisions and exceptions.
Create the shared record and explicit workflow states.
Link communications, documents and management views.
Add bounded assistance after the process is stable.
An event-led backbone keeps every action traceable
01event = capture(change)02record = customer.merge(event)03next = policy.resolve(record.state)04owner = roles.assign(next)05audit.write(event, next, owner)