Solve today’s problem.
Explore tomorrow’s product.

Begin with a process that matters: evidence scattered across systems, staff repeatedly rekeying information, delayed responses, inconsistent follow-up or a dashboard that arrives too late to inform a decision. We map the process with the people who use it and identify the point at which a change could create measurable value.

Suitable projects can include quality management systems, compliance workflows, project controls, learning platforms, CRM, intelligent documents and AI assistants. A broad transformation ambition is translated into a specific initial workflow, an owner and an outcome that can be observed. The result may use automation, conventional software, AI or an appropriate combination.

The routes differ in who pays for development, who controls the product and whether wider commercialisation is part of the objective. A reduced initial fee is not assumed simply because an idea might be reusable. Any contribution, discount or participation must be supported by a workable commercial case and recorded in the agreement.

Discovery produces a shared picture of the current process, the intended improvement and the constraints. We identify users, decision owners, systems, data sources and dependencies. We also distinguish essential functions from later enhancements so that the first investment has a defined purpose.

The output is a delivery brief with a proposed pilot, acceptance measures, responsibilities, an indicative cost structure and the material assumptions still to resolve. The business can then choose whether to commission the next stage, refine the proposal or stop. Discovery is valuable when it improves that decision, even if the initial solution changes.

• A process map and a baseline for the problem being addressed.
• A prioritised use case and a defined group of pilot users.
• A view of data availability, permissions and integration needs.
• A delivery scope with exclusions and dependencies.
• An agreed evaluation approach and recommended next decision.

Your business supplies the operational context and designates a person who can make decisions. Relevant staff help test the workflow and explain the exceptions that a specification may miss. Access to data and systems must be authorised, and third-party constraints need to be identified early.

Kent’s contribution is defined in the proposal and can include product discovery, design, development, integrations, evaluation, documentation and ongoing support. A co-build also needs a commercial owner: someone responsible for testing wider demand, deciding the market offer and coordinating sales activity. These responsibilities should be visible before development becomes substantial.

A co-build agreement should distinguish existing intellectual property, newly developed software, reusable components, customer-specific configuration and the information belonging to your business. The right to commercialise a general product does not automatically include the right to reuse confidential records, customer information or proprietary material.

Licensing terms should identify permitted markets, use cases, users and any exclusivity. Where royalties or revenue participation are agreed, define the revenue base, exclusions, reporting period, payment process and relevant review rights. Address future improvements, third-party components, termination and the practical ability to keep using the system.

Commercial clarity protects both sides. Your organisation should understand whether it owns an output, receives a licence or participates in a separate venture. Kent should understand which parts of the solution it can maintain, reuse and sell. These are explicit contract choices, not assumptions created by a promising conversation.

An AI business case should start with the current operation. Identify the time, spending, delays or error-handling effort associated with the process, then agree how any improvement will be measured. Time released is not automatically a cash saving: the plan should explain whether capacity is redeployed, additional work becomes possible or an actual cost is removed.

The cost model includes discovery, development, integration, data preparation, model usage, hosting, review, training and support where applicable. For a reusable product, it also needs the cost of selling to and onboarding another customer. This helps distinguish an attractive internal tool from a product that can be delivered profitably to others.

Milestones should be linked to usable outputs and acceptance criteria. A pilot is reviewed with the intended users against agreed quality, response and operational measures. Exceptions, failures and escalation needs are recorded so the production plan reflects real working conditions.

Before wider rollout, agree access permissions, the handling of AI uncertainty, monitoring, support ownership and a route to recover or correct a failed process. Identify which actions need a person’s approval and how people can challenge an output. The support arrangement then explains what is covered, how changes are requested and how recurring costs are reviewed.

All training is delivered by Kent Business College, UK. Each module provides 14 weekly two-hour sessions, totalling 28 live learning hours. Appropriate training can strengthen your team’s capability; project-specific handover, operating documentation and support are defined separately in the delivery agreement.