A business technology roadmap: website, CRM, work systems and AI

Start with a recent enquiry or order. Trace what happened from first contact to completion, including the spreadsheets, conversations and manual checks. This gives you a practical basis for choosing the next system instead of buying a collection of tools that each solve a different fragment.

Ask the people doing the work to show an actual example. Where did information disappear? Which decision waited for someone? Which figure had to be entered twice? Separate a missing tool from an unclear responsibility or an inconsistent process.

The GOV.UK Service Standard on understanding users starts with people's needs and the wider problem they are trying to solve. For a business, that means looking beyond the screen requested by a manager to the task performed by the customer and staff.

A sales team might ask for an AI assistant because preparing a quotation takes too long. Investigation may show that product information lives in several files and nobody knows which version is current. Establishing the authoritative information and its owner is a dependency for a useful assistant.

Write the problem as an observable gap: enquiries arrive but nobody owns the next response; approved orders are retyped into a second system; staff cannot tell whether the customer has accepted a revision. These statements are specific enough to evaluate an intervention.

The following is a way to distinguish responsibilities, not a shopping list that every business must complete.

Salesforce's CRM introduction describes a shared view of customer relationships and interactions. That role is useful even without an AI feature. A CRM also does not automatically become the source of truth for every invoice, inventory item or project document.

Likewise, a website redesign may improve how an offer is understood but cannot assign an enquiry to a salesperson unless that handoff is designed. Define the boundary and the connection together.

Consider a business that supplies and installs office equipment. This is a planning example, not a reported customer result. A prospect asks whether a particular installation is possible and attaches a floor plan.

The website can explain the relevant service, request a concise description and acknowledge receipt. The CRM records the prospect and assigns someone to assess the request. A work system stores the agreed scope and installation tasks once the opportunity becomes a job.

The handoff should preserve the enquiry identifier, source documents and decisions. It should also distinguish a customer's request from an approved commitment. A requested installation date is not a confirmed schedule merely because it appears in a form.

Automation can notify the assigned person and create the next task according to a defined rule. AI might later extract requirements from the attachment and prepare clarification questions. Its proposed interpretation must remain linked to the source, with someone checking what will be promised to the customer.

If staff currently lose enquiries, build the ownership and follow-up mechanism first. If they already manage follow-up well but spend hours reading varied attachments, the AI step may be the more useful next investment. The sequence depends on evidence from the workflow.

For each proposed change, record the affected task, current method, expected improvement, dependencies and responsible owner. Include how you will know whether it worked. Avoid releases described only as installing a platform or connecting an API.

Microsoft's business-process management guidance includes examining and mapping a process before changing it. A practical roadmap can use that current-state view to decide what must be standardised and what should remain flexible.

One release might give every website enquiry an owner and a visible status. A later release might carry approved customer information into delivery without retyping. An AI pilot could then prepare a scoped response from the information those systems retain.

Each release should be useful on its own. Define what happens when an integration fails, who handles exceptions and how staff continue working. A plan that produces value only after every system is replaced is harder to validate and more disruptive to operate.

Check the capabilities already available in your existing tools. Sometimes the missing step is a configuration change or a better handoff. Sometimes a packaged product covers the routine work and only a small integration needs development.

Custom development is more plausible where a recurring, important workflow does not fit available software and the business can maintain clear requirements. AI adds another question: is the task variable enough to benefit from interpretation, and can the result be checked? A fixed calculation or simple routing rule may not need a model.

Compare options using the actual scenario, representative data and intended users. Include account ownership, access permissions, export options, support responsibilities and ongoing operation. A demonstration with ideal data does not show how staff will resolve incomplete records on a busy day.

The guide to buying software or building a custom system explores that choice in more detail. For the customer-facing starting point, see the B2B website enquiry checklist.

Talvyn Labs helps business owners turn scattered technology requests into a delivery plan covering websites, connected work systems and AI products. Bring one real workflow, the tools already in use and examples of where work stalls. Build a roadmap with clear priorities, dependencies and acceptance criteria before committing to the next system.