The questions leaders ask us about AI.

Start with alignment: a half-day leadership workshop that explains what AI can and can't do and agrees a short, prioritised list of use cases. Then get your existing users trained properly, automate one or two high-value reporting or document tasks, put light governance in place, and deliver quick wins you can show the board. Small, visible steps beat a big programme that takes a year to report back.

No. Like waiting for next year's phone, you never buy. The capability is already good enough to save real time. The answer to rapid change is to design for it: start with a small test with your own people, keep your data in your hands and keep models swappable, so each improvement makes you better off rather than locked in.

Often it's both, and it pays to separate them. Some problems are solved by a clear procedure or a simple automation. Others need AI because they involve reading documents, judgement or unstructured data. In discovery we split the list into "fix the process", "automate it" and "apply AI", and we prioritise what should be done, not everything that could be done.

Not today, and you wouldn't want to. Start by augmenting individual steps such as reading the enquiry, drafting the quote and creating the order, with a person reviewing each one. As accuracy is proven, the human moves from checking everything to checking exceptions. Much more of the chain will be automated over the next few years, but trust is earned step by step.

Look at the whole flow first. Speeding up one department can create work for the next one if the hand-offs aren't designed. We map the process end to end, agree where the data lives at each step, and then automate in small pieces that fit that design.

For manufacturers the path is fairly clear: digitise paperwork and knowledge, connect machines and systems, then use the data for prediction, such as maintenance, demand and scheduling. Expect field technicians who diagnose from a photo or a sound, sales teams with instant answers about every product, and a business that learns from every quote and job. Nobody can give you the exact timetable, but the direction is not in doubt.

It's the right worry. Treat AI as a platform question, not a string of gadgets. Agree where tools live, how they connect to your core systems, who owns each one and how it's reviewed. A simple register of important tools and a target architecture let you add use case after use case on the same foundations.

You should see working quick wins within weeks: a first round of use cases in about 30–90 days, often dashboards on live data or document tools. Larger platforms such as a company knowledge assistant typically reach a usable beta in two to three months and wider rollout in four to six. The limit is usually organisational, not technical.

Less than people expect, but it's front-loaded. Typically a day or two of interviews with the people who do the work, an hour or two a week from reviewers during the build, and a training session at the end. Plan around your busy periods, because the project moves at the speed you can support it.

There are three parts: per-user licences for the AI tools staff use, usage charges ("tokens") for automated work, which grow with volume, and the time of the people who build and maintain your tools. Hosting and connectors are usually modest. People's time is the cost that gets underestimated. Give AI its own budget line and a simple spend dashboard, because it's easy to overspend when you push thousands of documents through a model. Good engineering keeps running costs down, for example by pre-processing documents once rather than re-reading them on every question.

Measure it from day one. We baseline the current process (hours, steps, turnaround) and then track the change: hours saved, documents processed, manual touches removed, extra leads. Add a simple AI scorecard covering how many people use AI and which workflows are in production. "Days to minutes" examples from your own staff are the most persuasive evidence there is.

A fair challenge. We don't set a finger-in-the-air target. We agree the metric up front (usually hours of effort on a defined task), measure it before we start and report it after, along the lines of "this task took X hours and now takes Y". The first outputs are reviewed closely, and the feedback is used to lift accuracy on the next round.

No. We work in stage-gated phases: a quick prototype to prove feasibility on your own material, then a deeper build, then optional ongoing support. Each phase has a clear deliverable and you decide whether to continue. The early phases are designed as "no-regrets" moves.

For most mid-sized companies a full in-house AI engineering team is expensive and hard to recruit, and the work is lumpy. A partner gives you senior architecture and build capacity when you need it, while we help you grow internal skills, often a fractional AI lead plus champions, so that you depend on us less over time.

The software and hardware are usually small items. The real cost is your people's time. Something a specialist would build in a week might take a capable non-specialist three, and longer if they're fitting it around the day job. So the question is rarely "do we have the talent?" but "do we have the time?" Budget the hours explicitly, and consider specialist help for the hard parts.

Data access and quality matter more than the choice of model: "lousy data in, lousy answers out". You don't need perfect data to start, but you do need secure access, clear permissions and one trusted source for each data set. We usually begin with use cases that run on data you already trust, and fix quality issues as they surface.

Usually not yet. AI doesn't make reliable storage obsolete, but most mid-sized companies can manage with what they have: SharePoint for files, read-only SQL views on the ERP for live data, and a small self-contained database (such as SQLite) inside each tool for anything the ERP has no place for. A bought warehouse platform is often overkill. Add one when there's a real trigger, such as joining several live sources, heavy history analysis, or ERP performance limits that view optimisation can't fix. As AI reporting spreads, track how much your older BI dashboards are still used: falling use tells you what has already been replaced.

Usually not. Replacing an ERP is slow, expensive and disruptive. The pattern we see working is "keep the core, wrap AI around it". Leave the system, its data and its permission structure exactly as they are, and add read-only views, a secure connector and AI tools on top. People who don't use AI carry on working just as they do today. Many companies are doing exactly this with ageing ERPs.

Yes, but carefully, and usually not on day one. One entry on an ERP screen can update several tables and trigger custom scripts, so anything that writes back must go through the same business-logic routes as the user interface: the vendor's import tools, APIs, integration middleware or the vendor's own AI connector when it exists. It should never write straight into the database. Until then, use "prepare and approve": the tool keeps its own data, prepares the change, works out who should enter it and sends them a clear request (or a prepared import for them to approve), so a named person stays responsible. These interim tools are building blocks for full write-back, and having a data architect on the team makes safe write-back possible much sooner.

An API is a door a system offers for other software to read or write data. An AI connector (often built on a standard called MCP) is a door designed for AI tools, so an assistant can ask your systems questions safely. A data warehouse is a separate store that copies data from several systems so you can analyse history across them. Most AI programmes use the first two early and the third later, if at all.

Decide this before you build. Agree one source of truth for each data set (usually finance for financials, the CRM for pipeline) and who arbitrates. AI tools should read from that source, and any figure that doesn't reconcile with it shouldn't be trusted.

Only with the right licence or an official API. Think of AI as a very fast, very diligent employee, not a hacker: it can work through public sources and anything you are entitled to access, and nothing more.

Capture it as you go: structured interviews with experts, their past decisions such as quotes and bid/no-bid reasons, manuals and meeting notes. That becomes a knowledge base the AI draws on and improves over time. This "knowledge engineering" step is often where the real value is.

It's the most important data question in any self-service programme. Make your views the place where business logic lives: expose only the defined fields, with plain-English documentation approved by the data owner. Use existing reports to fast-track a definitions "cheat sheet" for key metrics. Keep a rule that any KPI built on financial data goes through finance before it's published. Documentation helps, but responsibility stays with a person.

Free consumer versions may use your data for training; business and enterprise versions can be set so they don't, with retention and admin controls. Use company accounts on a business plan, check the data settings, and keep highly sensitive information out of any tool that isn't approved for it. We help you choose the plan and settings and explain the security layers in terms your stakeholders can sign off.

You're not alone: every organisation has "shadow AI", because staff can see it saves them time. Don't ban it; channel it. Provide an approved, protected tool, publish a short acceptable-use policy, and move useful work from personal accounts into company accounts so it is owned and backed up.

Rarely. There are three levels of control: a business plan from a major AI provider, the same models hosted in your own cloud account (for example through AWS Bedrock), or a fully offline model on your own hardware. Each adds control and overhead. Self-hosted models are weaker and need a specialist to run, and cloud-hosted ones lose the provider's collaboration features. For most companies the business plan, with your own credentials, secrets and connectors kept on your own infrastructure, gives better results and adequate protection. There are exceptions, such as defence or classified work, and we assess those case by case.

Use two layers. Instructions and shared "skills" hold best practice, but users can override them. Permissions tied to each person's role can't be overridden: the AI acts with the user's own credentials, read-only where no write is needed and limited to the right folders. Just telling the AI not to go somewhere is not a control; the permissions are. Don't give an AI tool unlimited rights "everywhere": there are well-publicised cases where a coding assistant deleted a company's production data and its backups after an innocent-sounding request. Keep it read-only by default, keep backups out of its reach, and keep a human sign-off for anything destructive.

Design it in. Every app and dashboard should return data according to the viewer's own system permissions, not the builder's. If a junior user opens a colleague's dashboard, sensitive fields should be masked or refused. Tools published inside your AI platform can do this automatically. Pages you host for people outside the platform need access control you build yourself. AI tools make sharing very easy, so check link settings and keep data such as HR and payroll out of general tools.

We host in the region that suits your data and legal position, and keep data processors there too. Regulation is mostly risk-based: the EU AI Act puts heavy obligations on "high-risk" uses such as hiring or biometric identification, and light ones on most business uses. We flag where a use case crosses into a regulated area. We are not lawyers, but we know when to bring them in.

Treat outputs as AI-assisted, not AI-finalised. Anything that matters, such as technical documents, payments, compliance certificates or financials, gets a named human reviewer and sign-off, with an approval log. We also suggest starting where the risk is lowest and extending as confidence grows.

It's a real risk, and you can use the same tools to monitor it: regularly ask the main AI assistants what they say about you and check for anything untrue. Existing protections against fake reviews still apply. Clear, accurate information on your own website is the best defence.

More than most companies expect, and much faster than before: AI can gather and digest everything you publish in minutes. That's not new information, but it is newly easy to use. Review what's publicly accessible, such as manuals, documents and old files, and decide what should stay public.

Hiring and other people decisions are the highest-risk area. AI can inherit bias from historical data, and in some jurisdictions these uses carry formal obligations such as regular audits. Use vetted vendors, keep humans making the decisions, and document how the system is checked for fairness.

It's still unsettled law, so be careful. Copyright usually turns on the amount of human input, so document your design process and the edits you make. Generating many more design options means checking more too: tools can automatically compare new designs against existing images. Take legal advice for anything commercially important.

Three things, and most of them you already have. Written policy: your AI policy plus the builders' skill file, which sets out how tools must be built. Access control: AI should reuse your existing system permissions rather than invent new ones. Logging: every query and change should be logged centrally (for example in your code repository or SharePoint), not on one person's machine. For legal and compliance questions, the major AI vendors publish trust centres with their certifications.

The underlying models are broadly comparable; the difference is in how they are deployed. Copilot is built into Office apps, which is convenient but can feel restrictive. ChatGPT and Claude are more flexible and stronger for building automations and connecting to your systems. Choose on data controls, connectors, automation and what your people will actually use. Most companies settle on one main platform, sometimes two.

Standardise. Shared company instructions, templates and "skills" bring consistency and spread good practice, and individuals can still tailor them to their role. Keep the important skills in a versioned, shared place (for builders, the code repository) so changes are tracked and anyone can see the current version. Have the right people review them: finance for financial skills, IT for security rules. It's an extension of what you already do with brand guidelines and document templates.

Generic output comes from generic prompts. Give the AI your brand context (colours, fonts, tone, customer personas, examples of good work), set once for the whole organisation or per project, and the output adapts. Then iterate: a first draft in 15 minutes still needs a human eye.

Both, but the core will consolidate. Most enterprises will choose among four or five major providers for their main AI platform, with specialist tools on top where they add something. That's why an architecture that lets you swap components matters.

They're good and improving: summaries and action lists save real time, and transcripts make a strong source for AI projects. Speaker labelling is harder with one room microphone. A simple habit helps: read the actions aloud with names at the end of the meeting. Check that your licences and IT settings allow the tool you choose.

Decide deliberately: start with the people who will use it in their daily work, then expand as champions spread the know-how. Licences without training and coaching are wasted, so budget for both.

Use the layers the platform gives you. Profile instructions say who you are, your role and who you report to: a few lines is enough, and answers improve noticeably. Project instructions and files set out how a team works and where its sources of truth are. Shared skills set the company-wide rules. One useful trick is to put your AI policy into the instructions, so the assistant checks requests against it.

Decide case by case against four tests: cost, including your people's time, which is usually the biggest cost; skills (can we build and maintain it?); criticality (if it must be 100% right, like payments, lean towards buying); and speed (building a wrapper around what you have is often much faster). Building also makes sense when no product integrates with your systems or fits how you work, and in-house tools are easier to change later. A common answer is "keep the core system, wrap AI around it, buy where accuracy is critical".

A real risk once vibe-coding takes off, and it's also why tools sometimes "just stop working". Every tool other people rely on should have a named owner and a backup, code stored in the company repository, an entry in a simple register, and a README that starts with a plain-English summary, so a colleague (or the AI) can pick it up. Run shared tools on company infrastructure, not on someone's laptop or personal account. A technical lead should review them before wider release. It doesn't need to be bureaucratic, but version one of a home-built tool is not production software.

Yes, it's possible, and we've seen sizeable companies run this way. You need clear roles: a stack owner who understands the whole set-up, builders for each tool, reviewers who check accuracy and usability, and an IT partner who provides the infrastructure (servers, secure web addresses, service accounts, email app registrations). Add expertise for the hard parts, often a fractional or retained AI and technology lead, especially for things like writing data back to your ERP. Whoever maintains the core connector shouldn't be doing it purely on the side. Over time, as more of the business runs on data, bring some of that capability in-house.

You get full rights to use what we build for your business. The knowledge built from your data (terminology, diagnostic logic, prompt libraries) is not reused for your competitors. Generic building blocks such as standard interfaces, pipelines and security patterns stay reusable, which keeps your costs down.

You shouldn't be. We build on standard, documented components, keep your knowledge in portable, exportable files, and hand over the code so any competent developer can run it. Ongoing support is flexible. We often recommend we run and tune the system for the first months while it's improving, and you can take it in-house whenever you choose.

Own your data end to end, connect components through standard connectors, and design so that the model can be swapped when a better or cheaper one arrives. People worry that what the AI has "learned" about them is a lock-in. It isn't, really. You can ask your current tool for a detailed, structured export of what it knows about you and give that to the new one, and if your code, skills and documentation live in your own repository, any model can pick them up. Models change often and new versions can behave differently, so a testing routine and a model-agnostic design protect you.

Either. Many clients start with us hosting and improving it, since a new AI system gets better quickly with feedback, then bring it in-house or move it to their own cloud later. Wherever it runs, it should integrate with the systems your people already use, such as the CRM, email and chat, so it doesn't become another screen nobody opens.

It won't be perfect the first time, but it gets better fast. We break the work into small, well-defined tasks, feed the AI only the relevant source material, make it cite where each answer came from, and build review steps into the tool. Early outputs are reviewed closely. As accuracy is proven, reviews lighten, and your feedback is used to improve the instructions.

We build a test set from real questions and tasks with known good answers, ideally scored by your own experts, and re-run it every time the system changes. Users also flag good and bad answers in the tool. That turns "does it feel right?" into a number you can track.

Ask for sources: good AI tools cite the document or system behind every answer, and you can always ask "how did you get this number?" When AI reads your systems, use documented, owner-approved views so it's clear where each figure comes from, and have the tool check that what came back matches what was asked. For tools staff build, a short review checklist before release (data source, accuracy, security, ownership) catches most problems. Anything that doesn't reconcile with your source of truth isn't ready.

That's "automation bias", and it's a management issue as much as a technical one. AI "can come up with rubbish that sounds good". Keep people accountable, review and audit regularly, and match the level of checking to the stakes. Managers become managers of AI: they direct it, review it and own the result.

A good system shows you the conflict rather than hiding it. That's a benefit: AI becomes a way to find out-of-date or inconsistent documents so you can fix them at the source.

It's dramatically faster: hours become minutes. But check the results, especially when cleaning data. Build the checks into the instructions: tell the AI which totals must tie out (for example, reconcile to the ledger or control total) and have it report the reconciliation with every run. At first, run it alongside your current method, ask it to show its working or write the code it used, and spot-check a few outputs yourself.

It will change jobs, and repetitive desk work will be affected first. But for the next several years the dominant pattern is people working with AI: less re-keying and drudgery, more time for judgement and customers. Experienced people become more valuable, because AI needs someone who knows the business to direct and check it. As we often say, it's not AI that replaces people, it's people using AI who replace those who don't.

Get them using it on their own work. The fear is mostly fear of the unknown: of looking stupid, of being left behind. A one-hour class and then nothing doesn't work. Continuous coaching, AI "buddies", champions in each team and showcases of colleagues' wins do. "People are scared of AI until they really start using it."

Easier than you think, and you learn by doing, like a musical instrument. Ask it things, tell it what you don't like, and try again. Nothing is a stupid question. Treat it like delegating to a capable new colleague. Forums where colleagues show what they've done speed everyone up.

Short hands-on sessions on your own tasks beat generic courses: prompting, using AI safely and building simple automations. Then keep it going with monthly check-ins, brown-bag lunches and walkthroughs of how tools were built, so your team builds its own muscle and can "ask intelligently for more".

Use the channels you already have: a champion per department, a monthly brown-bag lunch, a slot in all-hands meetings and a short newsletter. Once everyone is on company accounts, share projects, prompts and skills inside the AI platform so people can copy what works.

Yes: start with a personal-productivity starter kit, such as a daily email and calendar digest, meeting summaries and a writing assistant in your brand voice. Give it to everyone, with a short session to tailor it. It builds habits and confidence before the bigger projects arrive.

AI is a team sport. You need an executive sponsor, an AI lead who turns business needs into requirements, someone who connects systems securely, the builders, and champions in each function. None of these needs to be full-time at first. A short monthly steering meeting keeps priorities, risks and results visible.

Managers become managers of AI as well as of people: they decide what to delegate to it, review what it produces and stay accountable for the result. "Don't leave your brain out." The skills that matter most are judgement, domain expertise and knowing what good looks like.

Yes, but keep it short and practical: which tools are approved, what data can and can't go into them, always verify outputs, and who to ask. Then make it work in practice. Put the policy into the AI's own instructions so it checks requests against it, turn the technical rules into the builders' skill file, keep a register of important tools, and watch for shadow AI. A policy on its own doesn't change behaviour.

Match it to the risk. Low-stakes drafting needs a light touch. Payments, compliance certificates, financials and customer-facing outputs always need a named human reviewer. For each use case, decide up front whether a human is in the loop, on the loop or out of it.

Keep one simple register of AI initiatives and tools (owner, status, users, benefit) and a one-page scorecard reviewed at a monthly steering meeting. Tracking itself drives adoption: what gets measured gets done.

It's a legitimate concern: AI is energy-intensive, and data-centre growth is a real local issue in some regions. Use the right-sized model for the task rather than the biggest one, and avoid wasteful automated workloads. Good engineering is cheaper and greener at the same time.

It shouldn't, and the design should make finance stronger, not busier. Finance stays the gatekeeper of definitions: it approves the views and their documentation, and certifies key reports. Self-service then means people can answer their own questions from approved data, instead of sending finance more requests. If people start asking "why doesn't this number match?", that is a sign a view needs tightening, not that access should be withdrawn.

Before it, a short staff survey and one-to-one discovery calls with key people. On the day: what AI can and can't do (with live demos on your own material), a showcase of what your staff have already built, breakout groups that generate and rank use cases by value and ease, and a practical operating playbook. Afterwards you get the notes, the prioritised use cases and a 30/60/90-day plan.

The leadership team and functional heads for the roadmap session, with the people already building with AI showing their work. A follow-on technical session covers architecture and data with your builders, data owners and IT partner. Bring laptops and working AI accounts, because the hands-on parts matter.

On site works best for alignment and the breakout work. Remote is possible but usually shorter. Hybrid works for individual remote team members if the room is set up for it.

Yes. Owners want a credible AI story that shows in revenue and margin. Buyers increasingly examine the AI architecture and capabilities in due diligence, because "everyone's AI-washing". Real use cases with measured results, sound data foundations and clear governance are what stand up.

Yes: AI research agents can scan public sources daily for projects, tenders and signals that match your sweet spot, and score them against your capabilities and past wins. The value comes from fitting the leads into your sales workflow and CRM and qualifying them well. More leads alone won't help if they're the wrong ones.

Keep your core systems, and the permissions you already have, exactly as they are, and add thin layers on top. Those layers are read-only views of the data, a connector (an MCP server) that checks each user's own credentials, a shared "skill" file that tells the AI how to use it and how to build tools, and then your people on a business AI plan. The data stays where it is and stays the single source of truth. Each new dashboard, chat or agent reuses the same foundations instead of starting again.

ERP tables are cryptic: column names are codes, and the business logic (tax, freight, postings) is hidden. Asked to read them raw, an AI will often be confidently wrong. A read-only SQL view picks out the fields that matter, applies your business rules and presents the data in plain terms. Each view should come with documentation approved by someone who understands the data, so everyone knows which "revenue" or "date" they are looking at.

If the only guard is an instruction to the AI, yes: instructions can be "jailbroken" or overridden. That's why access control belongs in the authentication layer. Every request carries the user's own credentials, and the connector returns only what those credentials allow, however hard the AI tries. In our demos, a junior user who asks for a margin dashboard gets a polite refusal and an explanation, not a workaround.

Judge each option on three tests: does it respect each user's permissions, is it guaranteed read-only, and does it log every query? Open-source connectors often fail the permissions test. Giving the AI raw database access plus instructions is "just asking nicely". Some vendor APIs can change data and don't log queries. A small in-house connector that inherits each user's existing rights often passes all three, and you can swap in the vendor's own connector later if it meets the same bar.

Congratulations: that's the hard part done. Next, move it to a company server that runs 24/7 (often an existing virtual machine your IT partner manages). Give it a secure address the AI platform can reach, a dedicated service login and logs stored centrally. Put its code in the company repository with a named owner and a backup owner. Typically this takes days or weeks of work, not months.

It can, if you're careless. A view re-runs its query every time it is read, so it puts the same load on the database as a direct query. The safeguards are simple: cap the rows and run time of each query, optimise the few core views everyone relies on, and set refresh rules so heavy reports run on a schedule rather than on every click. Where speed really matters, bring in database expertise; Claude can also help optimise the SQL.

Less live than people think, and it varies by use. Many ERPs post transactions in daily batches, so refreshing a finance report every minute shows nothing new. A shop-floor scoreboard, on the other hand, may genuinely need up-to-the-minute data. Write the rule down in your build standards: "live and fast" for operational screens, scheduled snapshots for everything else. For the most demanding cases, event-driven updates (triggered when something is posted) beat constant polling.

A skill is a written-once set of instructions that the AI reads before it starts work. A builders' skill sets out your house rules: read-only access, the user's credentials decide what they see, naming and branding, where code is stored, how tools are deployed and registered, which steps only a human may do, and a final checklist. Without it, the AI does things right but slightly differently every time. Keep it versioned, have the relevant owners review it (finance for anything financial) and add company-specific rules, such as which set-ups are not allowed, because the AI can't know them otherwise.

Yes, once tools are used by more than one person. A shared repository is where code lives, gets reviewed and can be picked up by someone else later. Staff don't need to become GitHub experts: the AI does the commits, READMEs and register entries, following the skill file. The simplest set-up is that everyone in the company can see every tool's code, while access to the data still depends on each user's credentials. Whether to pay for enforced code review or put review rules in the skill file is a business decision.

No. Ask the AI to "standardise" an existing tool against your skill file, and it moves the tool into the shared repository with the same structure, documentation and register entry as everything else. The aim is to unify what you have, not to start again. Prioritise the tools other people rely on.

It can be. A tool that runs on the builder's credentials shows every user what the builder can see, and power users often see everything. Before you share it, move it to per-user authentication so that each person sees only what their own role allows. The same applies to AI tools signed in to one person's account on a shared machine: move them to company accounts.

Inside the company, the simplest route is to publish a dashboard within your AI platform: colleagues open a link and see the data their own permissions allow, with no server to run. People without a licence need either a page you host yourself (where you build the access control) or a scheduled snapshot that contains only what they may see. Choose deliberately, because sharing is now very easy. Check link settings before you publish anything with sensitive data behind it.

Chats are private unless you share them, and a shared chat is a read-only snapshot. Shared projects are the team space: common files, instructions and memory, plus the chats people choose to share. Start with one project per function (finance, sales, estimating, operations), each with a named lead. Anything people keep digging out of old emails belongs in the project or in SharePoint via a connector. Expect a little friction with sharing settings at first, so a one-page "how sharing works" guide is worth writing.

Anything that acts with some autonomy is agent-like. In practical terms, an agent is something that keeps working when you're on holiday, on a schedule or triggered by an event. Every agent needs a named owner, never a "headless" process nobody watches, because agents stop when something changes and can drift into odd behaviour. We have seen a note-taking agent start inventing far too many tasks. Supervise them like staff: beyond five or six per person, oversight gets hard.

Yes. Scheduled tasks run daily or when something happens, such as an email arriving or a button being pressed, with the same connectors as your chats (calendar, files, SharePoint, your ERP connector). You can set one up simply by describing it, and the AI walks you through any missing connections. A good first task is a morning email triage or a daily list of new orders. Expect it to ask what you mean, for example whether a "new" order is by order date or entry date. That's a useful prompt to pin down your definitions.

Reading, triaging, assigning by account or skill, spotting duplicates and tracking whether reps replied are all realistic. Sending is a separate permission: some ready-made email connectors are read-only, so sending or forwarding usually needs an app registration with Microsoft Graph, set up by whoever runs your Microsoft 365. Start with drafts that open in Outlook for a person to review, and go hands-off only once you trust it. Not everything needs AI: simple routing may just be a mail rule. Make the sales owner the agent's owner.

No. Keep Excel where it works: put your templates in an AI project, use the Excel add-in, and ask for new analyses "in the same format as this template". Do move the important files onto SharePoint so tools and colleagues can reach them, and build a dashboard on top if you need one. Watch that AI-built spreadsheets don't grow so complex that they create more work for the next person.

Yes, and you should. We build a mock copy of your ERP structure with made-up data, permissioned views and a test connector with sample roles, so people can build, test and try to break things safely. When you go live, use a "soft open": log the questions real users ask, build checked query "recipes" from the gaps, and only then switch on answers. Anything that needs the ERP can be prototyped on the mock while the production connector is being hosted.

Not automatically the most senior person. Choose the person technically closest to it, ideally whoever runs your connectors, so that requests to add or update them are handled by someone who understands them. Keys can sit in a role account or password vault so nothing is lost when someone leaves, but sign-off must always rest with a named person, never a shared or anonymous account. Activate your normal leaver process for AI and code accounts too.

Usually, yes, in one of two ways. A scheduled (for example nightly) export into a small database makes the data quick to query. And a "computer-use" agent can operate the application's screens in a sandboxed machine, the way a person would, to prepare documents or enter data. For example, a quote agent can read an emailed request, run the configurator, save the PDF to SharePoint and leave a draft reply for review, all without a data warehouse.