# Aigentcy > Deploy AI with governance, privacy & control. Aigentcy builds AI systems and automations that connect business tools and reduce manual work. Services include AI governance, private AI deployments and process automation. Published implementation examples cover HR reporting, support triage, procurement, Odoo lead handling and developer knowledge systems. Engagement scope, timing and price are agreed after discovery. The site does not offer a universal project price, guaranteed savings or compliance certification. Contact: info@aigentcy.com # We build around how your team works. Aigentcy is an AI automation agency based in Malta. We work with operations and technology teams to turn repeated manual processes into systems they can run, review and improve. Why choose Aigentcy ## Powering enterprise AI with expertise. [Request a call](https://www.aigentcy.com/contact/) ### Enterprise-grade governance We put in place the compliance frameworks, audit trails and board-level reporting that regulated enterprises need before they deploy AI at scale. ### Private-by-design AI Every model we deploy runs inside your infrastructure. Your data stays in your environment, with no third-party cloud and no data sovereignty risk. ### Measurable outcomes We scope every engagement with KPIs and deliver against them, whether that is a 78% cut in processing time or full regulatory readiness in 14 weeks. ### AI programme outcomes Client satisfaction 97% On-time delivery 93% Get to know us ## The agentic AI agency built for enterprise reality. ### Our mission To make enterprise AI trustworthy, private and measurably impactful, by combining deep technical capability with governance-first thinking. - AI governance and compliance - Private model deployment - Intelligent process automation ### Our vision A world where every enterprise can use the full power of AI without giving up data sovereignty, regulatory compliance or stakeholder trust. - Responsible AI at scale - Data sovereignty guaranteed - Sustainable AI programmes [Explore our services](https://www.aigentcy.com/services/) ## Start at the desk, not at the model. The useful details are in the work itself: who checks a report, where a lead goes next, what happens when an invoice does not match. We start there before choosing an approach. Some steps need ordinary rules. Others need document or language interpretation. We build the integration and agree where a person must approve the result. ## What we take responsibility for. Scope, implementation, testing and a clear handover. Operational ownership should be agreed before a workflow starts handling real work. - Document the systems and data the workflow can access. - Test normal cases, exceptions and failure recovery. - Make usage, errors and review decisions visible. - Give the team an owner and a way to stop or change the process. ## Hear from our clients. ![Ernest Baldacchino](https://www.aigentcy.com/assets/images/testimonial/ernest-baldacchino.webp) Ernest Baldacchino Managing Director > Aigentcy automated our sales pipeline for us. Every enquiry now lands in our CRM already qualified, scored, and assigned to the right person, with a first follow-up drafted, so we've stopped letting good leads go cold while we're heads-down on delivery. ![Rachel Tabone Hall](https://www.aigentcy.com/assets/images/testimonial/rachel-tabone-hall.webp) Rachel Tabone Hall Head of HR, Multiple Group > The automation took the repetitive admin off our desks and put it on a schedule. My team got their time and attention back, and now they spend it on the people work that actually needs them. Common questions ## Need help? Start here. We keep up with current models and bring tested governance frameworks to your organisation. These are the questions we hear most often. [Request a call](https://www.aigentcy.com/contact/) What does Aigentcy do? Aigentcy is an agentic AI agency specialising in three enterprise pillars: AI governance frameworks, private open-source model deployment, and intelligent process automation. We help organisations adopt AI responsibly, securely, and at scale. How does private AI model deployment work? We assess your use case and data environment, then select, fine-tune, and deploy an open-source LLM (such as Llama, Mistral, or Phi) entirely within your on-premise or private cloud infrastructure. Your data never touches a third-party server. What regulations does your AI Governance service cover? Our governance frameworks address the EU AI Act, ISO/IEC 42001, NIST AI RMF, SOC 2, GDPR, HIPAA, and Australian Privacy Act requirements. We map your specific obligations and build audit-ready controls around them. How long does a process automation engagement typically take? Discovery and process mapping typically takes 2–4 weeks. A focused automation sprint (one to three processes) runs 6–12 weeks. Enterprise-wide transformation programmes are phased over 3–12 months with measurable milestones at each stage. Do you work with existing enterprise systems? Yes. We integrate with SAP, Salesforce, ServiceNow, Microsoft 365, major ERP and CRM platforms, and most document management systems. Our automation solutions use standard API and RPA approaches to avoid vendor lock-in. How do I get started? Book a complimentary discovery call through our contact page. We'll spend 30 minutes understanding your priorities and return a scoped proposal within five business days. ## Let's build your AI future together. [Get started](https://www.aigentcy.com/contact/) [Call +356 7990 2911](tel:+35679902911) --- # About Aigentcy Aigentcy builds AI systems and automations that connect business tools and reduce manual work. Services include AI governance, private AI deployments and process automation. Governance, privacy and control guide that work: who can access data, which actions need approval and how the system is evaluated. This page summarises Aigentcy's own published information. It is not an independent assessment. ## Who the work is for Teams introducing AI into daily work, or using it already without consistent ownership and oversight. An engagement needs a named owner, access to the relevant systems and agreement on which decisions require human approval. ## Services - [AI governance](https://www.aigentcy.com/services/ai-governance/): Practical AI governance: inventory, permissions, evaluation, spend attribution and review controls built into day-to-day operations. - [Process automation](https://www.aigentcy.com/services/process-automation/): AI workflow automation for support, HR, sales and procurement. Connect your existing tools, keep approvals with your team and track what each workflow does. - [Private AI](https://www.aigentcy.com/services/private-ai/): Private AI deployment and knowledge systems shaped around your access rules, model quality requirements and operating costs. ## Published implementation examples These pages describe individual projects. They do not establish that every capability is present in every deployment. - [HR reporting and reminders in BambooHR](https://www.aigentcy.com/case-studies/hr-automation/) - [Support triage with replies ready for review](https://www.aigentcy.com/case-studies/customer-support-automation/) - [Purchase orders and invoice checks](https://www.aigentcy.com/case-studies/wholesale-procurement-automation/) - [Lead qualification and follow-up in Odoo](https://www.aigentcy.com/case-studies/odoo-lead-generation-automation/) - [Shared code knowledge for an engineering team](https://www.aigentcy.com/case-studies/agentic-second-brain/) ## How an engagement starts Identify the AI system or workflow, its users, data, decisions and current constraints. Scope, delivery stages, responsibilities and pricing are agreed after discovery. The site offers no universal project price, guaranteed saving or compliance certification. ## Alternatives to consider Existing software may already provide the controls you need. Your own engineers may be able to implement them. A policy or legal assessment may be the right first step when obligations are unclear. Aigentcy's implementation work is relevant when those decisions need to become working integrations and controls. ## Questions to ask - What data can the system access, and where is it processed? - What can run automatically, and what needs approval? - How are quality, failure recovery and cost tested? - Who owns ongoing operation, changes and incident response? - Which claims can be demonstrated in the proposed environment? ## Contact and sources Email [info@aigentcy.com](mailto:info@aigentcy.com) or use the [contact form](https://www.aigentcy.com/contact/). - [Reading index](https://www.aigentcy.com/llms.txt) - [Full text](https://www.aigentcy.com/llms-full.txt) - [Agent reading guide](https://www.aigentcy.com/agents.md) - [This page as Markdown](https://www.aigentcy.com/ai-summary.md) --- # AI content quality at volume: expertise in, drafts out A cheap draft can be expensive to approve. Put the expertise in before the machine writes, let deterministic checks and a critic reject what fails, and measure cost per approved article. Aigentcy 6 September 2026 13 min read Updated 7 September 2026 ## Key takeaways - Measure cost per approved article, with research, review, revisions and rejected drafts in the numerator. - Put the expertise in before drafting: a brief with real facts, named sources, positions the business holds and the reader's decision. - Run deterministic writing checks first. They catch banned phrases, machine sentence shapes, long paragraphs and flat rhythm before a person reads a word. - A critic pass on a different model finds unsupported claims and drift from the brief. Give it two revision rounds, then stop. - A named person approves every article. Automated checks earn them time; they don't replace the decision. **Expertise in, drafts out** The expert's work is finished before the machine writes. The checks and the critic run before any person reads, and the person's decision comes last and is recorded. A draft that costs a few cents can cost an hour to approve. If the editor has to rebuild the argument, check every example and strip invented promises, the price of the draft tells you nothing about the price of publishing it. The volume is already here. [Ahrefs](https://ahrefs.com/blog/what-percentage-of-new-content-is-ai-generated/) found that 74% of 900,000 pages published in April 2025 contained AI-generated content. And Google’s [spam policies](https://developers.google.com/search/docs/essentials/spam-policies) name scaled content abuse: many pages generated to manipulate rankings without helping users, however they were created. So the question for a marketing lead is how to use AI for content without publishing slop. This guide describes the practice we run: expertise in, drafts out. The expert supplies facts, sources and positions. The machine supplies prose. Checks and a critic reject what fails. A person approves what’s left, and AI content quality is measured as cost per approved article. ## Why generated slop fails readers and search Slop is text that reads plausibly and gives the reader nothing they can use. It is easy to produce and easy to recognise, and the tells are consistent enough to list. | Symptom | What the reader does | What search systems do | | --- | --- | --- | | Generic claims with no numbers, names or sources | Stops trusting the page and the brand behind it | Treat the page as adding little beyond existing results | | Invented statistics or sources | Finds out, sometimes publicly | Trust signals on the whole site weaken | | Confident errors about your own product | Enquires, then finds the promise was false | The enquiry becomes a complaint | | Uniform sentence length and stock phrases | Skims, then leaves | Engagement signals fall | | The same page with a name swapped in | Notices the copy on a competitor’s site | Google’s scaled content abuse policy applies | Google’s [guidance on helpful content](https://developers.google.com/search/docs/fundamentals/creating-helpful-content) turns this into questions a publisher can ask before publishing. The useful ones for a business site are these: - **Does the page give original information, reporting or analysis?** Or does it rephrase what already ranks? - **Does it show first-hand expertise?** Someone who has done the work, with the exception or the trade-off a buyer can’t see from a feature list. - **Would you expect to see it referenced by a printed magazine or a book?** - **Who wrote it, how was it made, and why?** Google puts trust first among experience, expertise, authority and trust, and says the “why” should be to help people. None of those questions asks whether a machine typed the words. They ask whether an expert stood behind them. That is the design constraint for the rest of this guide. ## Expertise in, drafts out The practice is a gate, and the gate has an order. The expert’s work happens before the draft exists. The machine’s work happens in the middle. The checks run before any person reads. And the person decides at the end. The expertise in, drafts out gate ```mermaid flowchart TD accTitle: The expertise in, drafts out gate A[Brief with facts and sources] --> B[Draft] B --> C{Deterministic checks pass?} C -->|No| D[Revise against findings] D --> B C -->|Yes| E[Critic pass on another model] E --> F{Findings remain?} F -->|Yes, round 1 or 2| D F -->|Yes, round 3| G[Back to a person] F -->|No| H[Human approval] H -->|Approved| I[Publish] H -->|Rejected| G ``` In practice it runs as six steps: 1. **Write the brief.** The reader, the decision the article supports, the facts the business can prove, the sources with dates, and the positions the business holds. 2. **Draft from the brief only.** The model may structure and phrase. It may not add facts, numbers or sources the brief doesn’t contain. 3. **Run the writing checks.** Deterministic rules: banned phrases, sentence shapes, paragraph length, heading case, rhythm. A fail sends the draft back with the exact lines. 4. **Run the critic.** A second model, on a different model family, reads the draft against the brief and lists unsupported claims, drift and gaps. 5. **Revise within a bound.** Two rounds against specific findings. A third round means the brief is missing something, so a person fixes the brief. 6. **Approve or reject.** A named person reads the draft with the findings and the sources and records the decision. Each step has a cost and an owner, which is what makes the economics later in this guide possible to calculate. ## What goes into the brief A brief written as “write about choosing a support platform” gets a generic overview back. A brief that says “help an operations lead decide which enquiries need a person before buying an automated support tool” gets a decision guide. The difference is everything the expert knows and the machine doesn’t. Before drafting, the brief should contain: - **The reader and what they already know.** A COO comparing options, or a customer completing a task. - **The decision the article supports.** One sentence. If you can’t write it, the article isn’t ready. - **Facts the business can prove.** Product capabilities confirmed by their owner, results with permission to publish, prices with dates. - **Sources with dates and the passage that matters.** A link on its own invites the model to paraphrase the whole page. - **Positions the business holds.** What you would refuse to recommend, even when it would make a better sales paragraph. - **The limits of the advice.** Who the recommendation doesn’t suit. | Proposed material | Evidence to collect | Editorial decision | | --- | --- | --- | | Product capability | Current documentation and confirmation from its owner | State the conditions and limitations | | Customer result | Approved measurement, time frame and naming permission | Publish only the result the evidence supports | | Market statistic | Original research, population and method | Keep its scope, label it illustrative, or leave it out | | Expert recommendation | Reasoning, relevant experience and counterexamples | Explain when a different choice makes sense | Keep confidential notes and customer data out of the drafting tool unless the agreement covers them. Removing a name is often not enough when the remaining details identify the customer. Our [AI governance service](https://www.aigentcy.com/services/ai-governance/) covers the access rules for this kind of workflow, and the [AI compliance policy generator](https://www.aigentcy.com/tools/ai-compliance-policy-generator/) produces a starting policy for what may enter it. ## Editorial rules that catch machine tells Machine prose has habits. They are consistent enough to write as rules and check by program, before anyone spends review time. The rules below are the ones that catch the most in our own editing, and each one is deterministic: a script either finds the pattern or it doesn’t. | Rule | What it catches | Why it matters | | --- | --- | --- | | Banned phrases | Stock openers, buzzwords and throat-clearing, from a list the team maintains | Readers recognise them and stop reading | | Sentence shapes | “It’s not X, it’s Y”, “Not X. Not Y. The Z.”, “X beats Y”, three-item rhythm at the end of every paragraph | The shapes perform rather than explain | | Paragraph length | Anything over 60 words | Long paragraphs hide the point from a reader scanning on a phone | | Sentence rhythm | Twenty sentences of the same length in a row | Uniform rhythm reads as machine output even when the words are fine | | Contractions and spoken openers | Fewer than a handful of contractions per thousand words | Instruction-tuned models write “do not” where a person says “don’t” | | Heading case and punctuation | Title case headings, em dashes, emoji | House style, and the em dash is the most recognised machine tell | | Structure shape | Missing takeaways, an FAQ with one-line answers, bold scattered mid-sentence | The reader’s skim path breaks | The phrase list starts with the ones readers recognise on sight: “in today’s fast-paced world”, “delve”, “seamless”, “game-changer” and “it’s worth noting”. It grows every time an editor catches a new one. **Writing checks return line numbers** The rules are deterministic, so a fail names the line. A draft goes back to revision with this list, and no reviewer reads it until the list is empty. These rules cost nothing per run. So they run first, on every draft, and a fail returns the line numbers. Nobody reads a draft that still trips them. They also have a limit. A paragraph can pass every rule and still use an accurate statistic to support the wrong conclusion. The checks find tells. They do not find truth, which is what the next two steps are for. ## The critic pass and bounded revisions A critic is a second model, on a different model family from the one that wrote the draft, given the brief, the sources and the draft. Its job is a list of findings with locations. It never rewrites. Ask it for specific failures: - Claims with no support in the brief or the sources. - Numbers, names or sources that appear in the draft and nowhere in the brief. - Sections that don’t answer the reader’s decision from the brief. - Positions that drift from what the business said it holds. - Places where a hedge in the source became a certainty in the draft. The revision loop is bounded on purpose. Two rounds against specific findings fix most drafts. A third round means the brief lacks a source or a position, and regenerating won’t supply either. So the third failure goes to a person, who fixes the brief or stops the article. Repeated generation is a poor substitute for a missing fact. ## Fact and claim review The critic reduces the reviewer’s work to a list. The reviewer still owns the decision on every claim class, because each class has a different way to be wrong. | Claim class | Who confirms it | Evidence | Rule | | --- | --- | --- | --- | | Product capability | The product owner | Current documentation | State the conditions. “Available on request” is not “available” | | Customer result | The account owner and the customer | Measurement and written permission | Publish the measured figure and the time frame, nothing rounder | | Market statistic | The editor | The original study, its population and date | Label it as a typical range or an example, and link it on first use | | Recommendation | The subject expert | Reasoning and counterexamples | Say when the other choice is right | | Legal or compliance statement | Whoever owns compliance | The regulation or the adviser’s note | Describe the obligation. Never state that a reader complies | | Price | Finance or sales | The current price list | Include the date, or leave the number out | Google also suggests giving readers context on [how content was produced](https://developers.google.com/search/docs/fundamentals/using-gen-ai-content). A short line on who briefed the article, what was checked and who approved it says more than a disclaimer. ## Human approval The approver reads the final draft with the critic’s findings, the sources and the brief beside it. Their job is the decision, and the recorded decision is the evidence that the process ran. What the approver does: - Reads the argument as the intended reader and decides whether it helps them decide. - Confirms each claim in the table above has its evidence attached. - Checks the positioning against what the business holds. - Records approval or rejection against that exact version, with a reason on rejection. What the approver no longer does: hunt for banned phrases, count paragraph lengths or reformat headings. The checks did that. A reviewer who spends twenty minutes on an article with a finding list usually spent an hour without one, and that difference is where the economics come from. ## The economics of cost per approved article Divide the total cost of a production batch by the number of articles approved. Rejected drafts stay in the numerator. If nothing meets the standard, report zero approvals and the cost incurred rather than a misleading unit cost. The example below is a worked scenario with assumed figures. It is neither a customer result nor a quote for any tool. Assume ten articles start, eight are approved and labour costs EUR 60 an hour. | Work across the batch | Assumed effort or charge | Cost | | --- | --- | --- | | Research and briefs, ten articles | 5 hours | EUR 300 | | Model and tooling charges | Illustrative allocation | EUR 20 | | Critic findings read and revisions checked | 3 hours | EUR 180 | | Expert and editorial approval | 4 hours | EUR 240 | | Total for eight approved articles | 12 hours plus tools | EUR 740 | That is EUR 92.50 per approved article, of which EUR 52.50 is review and approval labour. The two rejected articles are inside that number. Design, distribution and later maintenance are outside it, so add them when you evaluate the wider programme. The same batch under three different processes shows where the money moves: | Process | Review minutes per article | Rejection rate | Cost per approved article | What the number hides | | --- | --- | --- | --- | --- | | Manual writing and editing | 60 to 90 | Low, because the writer self-edits | Highest, driven by writing hours | Slow throughput | | AI drafts, no checks or critic | 45 to 60 | High or unknown | Looks cheap per draft, expensive per approval | Errors that reach readers | | AI drafts with checks, critic and approval | 20 to 30 | 15% to 25% | Lowest sustainable | Requires a real brief for every article | The ranges are assumptions to show the shape, and your own batch will give the real ones. Two signals from the batch matter more than the average. A rejection rate near zero usually means the checks are too loose. A rejection rate above a third usually means the briefs are thin, and the fix is upstream. **Cost per approved article, rejected drafts included** The two rejected drafts sit in the numerator and the eight approved articles in the denominator. Review and approval labour is EUR 52.50 of the EUR 92.50, which is why the checks earn their place by shortening review. Cutting the model bill from EUR 20 to EUR 10 saves EUR 1.25 per approved article. Cutting review by an hour across the batch saves EUR 7.50, if the same eight articles still meet the standard. So the checks and the critic earn their place by taking minutes out of review, and never by removing the reviewer. ## Measure usefulness after publication Approval is a production milestone. It does not prove an article attracts the right readers or helps them decide. Give each article a small set of measures tied to its job, and keep production efficiency separate from audience outcomes. | Measure | What it tells you | Caution | | --- | --- | --- | | Review minutes per approved article | Editorial workload | A shorter review may miss more | | Factual corrections after publication | Failures that escaped review | Record severity and reach, not only the count | | Useful next-step rate | Whether readers use the resource or action the article offers | Define the event and eligible visits the same way every month | | Qualified enquiries influenced | Connection to suitable demand | Attribution shows a path, never a cause | For a comparison guide, track use of the comparison and the enquiries that follow. For a tutorial, ask whether readers completed the task. A page view answers neither question. Our guide to [technical SEO and AI search](https://www.aigentcy.com/blog/technical-seo-and-ai-search/) covers how those enquiries get measured against the search that produced them. ## Start with one article type Pick a format with available evidence and an available expert, such as a buyer comparison or an implementation guide. Run a batch of ten through the whole gate before increasing volume, and keep the rejected drafts with their findings so the team can see where the effort went. At the end of the batch, read the expensive failures. Repeated factual corrections point to weak briefs or an unsuitable topic. Heavy restructuring points to a missing reader decision. Persistent voice problems need better examples in the brief rather than more instructions. [Flotta](https://www.flotta.ai/) runs this practice for the focused sites it builds. Pages are researched before they are written, every page passes automated checks and a second-model review, and you approve blog posts before they publish. Ask for a trial on a representative brief and your own approval criteria. Then bring the batch’s briefs, findings and costs to the decision about the next one. ## Frequently asked questions Can we publish AI generated content without human review? Not for business content that carries factual claims or brand promises. Automated checks catch formatting, banned phrases and some errors, and a critic model catches unsupported claims. Neither can confirm that the argument is sound or that the recommendation fits your customers, so a named person approves each article. How do we measure whether AI content saves money? Divide the total cost of a production batch by the number of approved articles, and compare it with the same measure for your manual process. Include research, drafting, review, revisions and the drafts you rejected. Track reviewer minutes separately so a lower model bill can't hide extra editorial effort. Will publishing more AI articles improve search performance? Volume on its own earns nothing. Google's scaled content abuse policy covers many pages generated without adding value, however they were produced. Choose topics you can support with expertise, answer them well, and measure the reader actions each article produces. What counts as AI content slop? Prose that reads plausibly and gives the reader nothing they can use: generic claims without numbers, invented sources, confident errors, and the sentence shapes machines default to. Readers stop trusting the site, and search systems treat the pages as low value. Should we tell readers that AI helped write an article? Google suggests giving readers context on how content was produced, in a way that makes sense for your audience. A short note on the process, who checked the facts and who approved the article does more for trust than a generic disclaimer. ## Related reading - [Technical SEO and AI search optimization: turn visibility into qualified demand](https://www.aigentcy.com/blog/technical-seo-and-ai-search/)Fix the crawl and index faults first, write pages that people and AI assistants can read, cover the searches your main site was never built for, and judge the work by qualified enquiries. - [Enterprise AI enablement: governed access for the whole company](https://www.aigentcy.com/blog/enterprise-ai-enablement/)Give each team governed access to a few approved models through one gateway, and measure adoption by the work that gets finished. - [AI cost management: what an accepted result costs](https://www.aigentcy.com/blog/enterprise-ai-cost-control/)How to report AI spend the way finance reports everything else: by team, by workflow and by accepted result, with unknown charges kept separate from zero. [See Flotta, our SEO and content platform](https://www.flotta.ai/) [Talk to us about your project](https://www.aigentcy.com/contact/) --- # AI governance Practical notes on AI inventories, access controls, evaluation, spend attribution and human review. AI governance 18 August 2026 13 min read ## [AI cost management: what an accepted result costs](https://www.aigentcy.com/blog/enterprise-ai-cost-control/) How to report AI spend the way finance reports everything else: by team, by workflow and by accepted result, with unknown charges kept separate from zero. [Read the guide](https://www.aigentcy.com/blog/enterprise-ai-cost-control/) **Three columns, three meanings** Recorded spend has a receipt, reserved allowance is a ceiling held while work runs, and an unconfirmed charge keeps its ceiling until a receipt or a review settles it. The total is never the sum of all three. AI governance 15 April 2026 16 min read ## [An AI governance framework your team can operate](https://www.aigentcy.com/blog/enterprise-ai-governance-framework-guide/) A decision guide for the people who sign off AI systems: how much governance each one needs, who does what in the first 90 days, what it costs to run, and the evidence that proves the rules were followed. [Read the guide](https://www.aigentcy.com/blog/enterprise-ai-governance-framework-guide/) **A requirement, its enforcement and its evidence** A policy sentence becomes a control in the application and a record the operator can read. If any of the three is missing, the other two cannot prove the rule was followed. --- # Private AI Decisions about model hosting, private knowledge retrieval and the systems needed to operate them. Private AI 26 May 2026 12 min read ## [Enterprise AI in Slack: one assistant for company knowledge](https://www.aigentcy.com/blog/enterprise-ai-in-slack/) Put one assistant where the questions already arrive, let it search only what each person may read, and measure how fast people reach a verified answer. [Read the guide](https://www.aigentcy.com/blog/enterprise-ai-in-slack/) **One front door, many sources** Slack supplies the identity, the gateway applies budgets and guardrails once for every agent, and each source keeps its own access list. Private AI 5 May 2026 13 min read ## [Enterprise AI enablement: governed access for the whole company](https://www.aigentcy.com/blog/enterprise-ai-enablement/) Give each team governed access to a few approved models through one gateway, and measure adoption by the work that gets finished. [Read the guide](https://www.aigentcy.com/blog/enterprise-ai-enablement/) **Governed access is one door with several rooms** A team's key says which routes it may use and how much it may spend. Adding a team is issuing a key. Removing one is disabling it, and every application that used it stops at once. --- # Process automation Connecting existing systems, preparing work for review and handling exceptions. Process automation 6 September 2026 13 min read ## [AI content quality at volume: expertise in, drafts out](https://www.aigentcy.com/blog/ai-generated-content-quality/) A cheap draft can be expensive to approve. Put the expertise in before the machine writes, let deterministic checks and a critic reject what fails, and measure cost per approved article. [Read the guide](https://www.aigentcy.com/blog/ai-generated-content-quality/) **Expertise in, drafts out** The expert's work is finished before the machine writes. The checks and the critic run before any person reads, and the person's decision comes last and is recorded. Process automation 31 August 2026 13 min read ## [Technical SEO and AI search optimization: turn visibility into qualified demand](https://www.aigentcy.com/blog/technical-seo-and-ai-search/) Fix the crawl and index faults first, write pages that people and AI assistants can read, cover the searches your main site was never built for, and judge the work by qualified enquiries. [Read the guide](https://www.aigentcy.com/blog/technical-seo-and-ai-search/) **From a search to a qualified enquiry** The count shrinks at each step, so each step needs its own number and its own owner. The figures are the article's worked example, not a result. Process automation 28 July 2026 12 min read ## [Native AI assistants for business software: guide first, then act](https://www.aigentcy.com/blog/native-ai-assistants-for-business-software/) An assistant inside the software people already use can show where a setting lives, prepare the change and apply it after confirmation. Measure the work finished, not the messages exchanged. [Read the guide](https://www.aigentcy.com/blog/native-ai-assistants-for-business-software/) **The assistant works beside the record** It sees the page the person has open, proposes a change with before and after, and the application checks the role and writes only after apply. Process automation 7 July 2026 11 min read ## [Multi-brand service desk automation: one desk for several customers](https://www.aigentcy.com/blog/multi-brand-service-desk-automation/) Service desk tools assume one company. When one team serves several brands, the gaps show up as leaked context, missed SLAs and duplicate work. Here is how to close them, and what AI makes routine. [Read the guide](https://www.aigentcy.com/blog/multi-brand-service-desk-automation/) **Where the walls stop** The walls between brands run through the portal, search and notifications. They stop at the queue, because the saving of a shared desk comes from sharing the people and the process. Process automation 16 June 2026 13 min read ## [Automated resolution rate: measuring support AI by outcomes](https://www.aigentcy.com/blog/support-ai-resolution-metrics/) A bot can answer more conversations while your agents get harder work. Measure verified resolution, safe escalation, repeat contact and the cost per resolved case before you trust the headline rate. [Read the guide](https://www.aigentcy.com/blog/support-ai-resolution-metrics/) **Two rates from the same month** The blended rate counts contained conversations, where the customer stopped asking, together with verified ones. The invoice counts verified only, so the dashboard can show double the billed rate. --- # AI cost management: what an accepted result costs How to report AI spend the way finance reports everything else: by team, by workflow and by accepted result, with unknown charges kept separate from zero. Aigentcy 18 August 2026 13 min read Updated 7 September 2026 ## Key takeaways - Report cost per accepted result, and count retries, revisions and review minutes inside it. - Give each team and each automated workflow its own gateway key with a monthly budget, so every request has an owner before it runs. - Record the intent to pay before a model call. A call that times out stays an unconfirmed charge until the provider's receipt settles it. - Show reserved allowance and recorded spend as separate lines. Releasing a reservation is a bookkeeping change, and never a refund. - Route routine work to open-weight models, which public price lists put at a small fraction of frontier prices, and keep frontier models for work that fails on the cheaper route. **Three columns, three meanings** Recorded spend has a receipt, reserved allowance is a ceiling held while work runs, and an unconfirmed charge keeps its ceiling until a receipt or a review settles it. The total is never the sum of all three. For the first year, AI cost management meant one line in the CTO’s experiment budget. Nobody asked what one result cost, because the total was small and the point was to learn. Then the total stopped being small. A support team, a content team and two scheduled workflows all run through the same provider account, and the invoice reaches the CFO as one line. She asks what the business got for it, and the honest answer is a token count. AI cost management turns that token count into the numbers finance already uses: cost per unit of work, budget by owner, and a clear line between spend that’s confirmed and spend that isn’t. This is how we set that up for the teams we work with. ## When AI spend becomes a finance line The move from experiment to line item changes the question being asked. Nobody in finance wants to know how many tokens a team used. They want to know what a unit of work costs, who approved it and whether the number is final. | | Experiment budget | Finance line | | --- | --- | --- | | Owner | The CTO or a platform team | The team that gets the result | | Unit | Tokens, requests, subscriptions | Cost per accepted result | | Question asked | Does it work? | Is it worth what it costs? | | Tolerance for unknowns | High. Sort it out later. | Low. Unknowns need an owner and a date. | | Review cadence | When the bill surprises someone | Monthly, with last month to compare | Three signs tell you the move has happened. The invoice is discussed at a finance meeting rather than an engineering one. Someone asks for the number by department. And a timeout or a duplicate request is treated as a possible charge, not as a technical footnote. ## Cost per accepted result Pick a unit of work a business owner recognises and signs off. A support reply sent to a customer, a supplier assessment approved, a published article. Then divide the full cost of producing a batch of those units by the number that passed review. The acceptance rule has to say who decides and when the result counts. A draft waiting for review is work in progress. A corrected version of the same assessment doesn’t become a second result because the model produced another answer. Compare like with like. Hard cases, new languages and incomplete documents cost more, so either keep the batch comparable or show the mix beside the total. The [FinOps Foundation’s unit economics capability](https://www.finops.org/framework/capabilities/unit-economics/) describes the same discipline for cloud spend, and it transfers directly. **Count the attempts, then divide** The timed-out attempt stays in the cost as an unconfirmed charge, and the four review minutes are the largest share. A cheaper model would change only the first bar. ## The four buckets of cost Split the total into categories that different people can change. Otherwise a fall in model prices hides a rising review burden, or an unused subscription disappears inside a shared technology budget. | Cost bucket | What belongs here | Who can change it | | --- | --- | --- | | Provider usage | Model requests, paid tools, retries that reached a provider | The workflow owner, by changing the route or the prompt | | People time | Preparing inputs, checking answers, correcting errors | The team lead, by changing templates and review rules | | Shared operation | Gateway, hosting, monitoring, knowledge maintenance | The platform owner, by changing scale or supplier | | Access and subscriptions | Seats, platform fees, committed capacity | Procurement, by matching seats to use | Label the scope of every comparison. A provider-only figure helps engineering tune a workflow. But it can’t be set against a fully loaded manual process and called a saving. ## AI cost management by team and workflow Spend needs an owner before the first request runs. The mechanism we use is a gateway that sits between every application and every model provider. It issues one key per team, one per deployed service and one per scheduled workflow, and each key carries a monthly budget and a list of allowed models. A request that would push a key past its budget is refused before it reaches a provider. The team sees a clear message, the platform records the refusal, and nothing is charged. [Bifrost](https://docs.getbifrost.ai/features/governance/virtual-keys), an open source gateway, documents this pattern as virtual keys with budgets, model restrictions and team association, and other gateways offer the same shape. Each key should carry: - **A budget owner**, the person who approves an increase. - **A reset period**, usually the calendar month, so the report lines up with the finance close. - **A daily cap**, a fraction of the monthly budget, so a runaway job is stopped in hours rather than weeks. - **An allowed model list**, so a routine workflow can’t quietly move to the most expensive model. - **A stated next step at the limit**, such as a lower-cost route, a request for more budget, or finishing the task by hand. Keep separate keys for routine work, experiments and approved exceptions. An experimental key needs room to learn. A scheduled workflow needs a predictable cap and a person who’s told when it’s hit. The starting budgets below are the kind we set in a first month. They’re assumptions to adjust after four weeks of real usage, and the daily cap is there so a mistake costs a day rather than a month. | Key | Monthly budget | Daily cap | Allowed routes | Told at the limit | | --- | --- | --- | --- | --- | | Support team, 12 agents | $600 | $50 | Routine, documents | Support lead | | Content team, 4 writers | $400 | $40 | Routine, hard cases | Head of marketing | | Nightly reporting job | $150 | $10 | Routine only | Platform owner, by alert | | Research pilot, 2 people | $500 | $60 | All routes | The pilot’s sponsor | **Refused before it costs anything** Because every key carries its own budget, a scheduled job that hits its cap is stopped at the gateway with a logged reason, while the other keys keep working. ## Retries, revisions and review time Three different things get called a retry, and they cost different amounts. Treat every repeat as new spend until the record says otherwise. | Kind of repeat | Is it new provider cost? | How to record it | | --- | --- | --- | | A reviewer asks for a change | Yes. It’s a new paid attempt. | New attempt, linked to the same task | | A service repeats a failed request | Yes, and the first may also have cost | New attempt. The first stays unconfirmed. | | The application re-saves a usage record | No. Same receipt, same attempt. | Retry the write. Never call the provider again. | | A person tries a better prompt in chat | Yes | New attempt, counted against their key | The interrupted request is the awkward one. The provider may have finished the work after your side gave up waiting. AWS’s guidance on [making retries safe](https://aws.amazon.com/builders-library/making-retries-safe-with-idempotent-APIs/) explains why a missing response proves nothing about whether the operation ran. Review time belongs in the same record. If a support agent spends four minutes checking a suggested reply, that’s four minutes of the reply’s cost. Sample it rather than asking people to self-report, and keep the sample beside the token figures. ## Charges you can’t confirm yet An empty cost field is evidence of nothing. So the ledger we run records the intent to pay before the provider is called, and every paid attempt moves through a small set of states. How one paid model call moves through the ledger ```mermaid flowchart TD accTitle: How one paid model call moves through the ledger A[Record intent and ceiling] --> B{Fits the budget?} B -->|No| C[Refuse before calling] B -->|Yes| D[Call the provider] D --> E{Receipt arrived?} E -->|Yes| F[Recorded spend] E -->|Timeout or lost reply| G[Unconfirmed charge] G -->|Late receipt or statement| F G -->|Owner review| H[Written off with a reason] ``` The states are plain enough for a finance reader: 1. **Reserved.** The application has recorded what it intends to spend, with a ceiling, and the budget check passed. 2. **Started.** The provider was called. From here on, money may have moved. 3. **Recorded.** A usage receipt arrived with token counts and a price. 4. **Unconfirmed.** The call timed out or the reply was lost. The ceiling stays held, and the attempt has an owner and an age. Unknown cost is kept separate from zero. A report that shows $0 for a timed-out call is wrong in a way that compounds, because the next month’s baseline inherits the error. A report that shows “3 unconfirmed, oldest 9 days” tells the owner what to chase. Recovery follows from the states. If the receipt was received but the write failed, retry the write. If the reply was lost, keep the hold and reconcile against the provider’s statement. Neither case buys another model response. Here’s the case that taught us to do it this way. A scheduled job called the provider, and the container running it was stopped before the reply came back. The job’s own log said nothing had happened. But the provider had finished the work and billed it, and the retry an hour later bought the same result a second time. With intent recorded first, the second run sees an unconfirmed attempt and waits for a person instead. ## Reserved allowance and recorded spend Reservations protect the budget while work runs. But they’re easy to misread on a dashboard, so keep them on their own line with their own meaning. | Reported amount | Meaning | Management response | | --- | --- | --- | | Recorded spend | Usage with a receipt and a price | Include it in the month’s cost | | Reserved allowance | Ceilings held for work that’s still running | Don’t promise that capacity elsewhere | | Unconfirmed charge | An attempt with no receipt yet | Assign an owner and a review date | | Reconciled spend | Recorded spend checked against the provider statement | Record the scope and any difference | Releasing a reservation changes what’s available to spend. It doesn’t mean the provider refunded anything. And a reconciled figure differs from the recorded one for ordinary reasons, such as a reporting lag, a credit, or a period boundary, so keep the adjustment traceable rather than overwriting the original. ## A worked example The figures below are assumptions chosen to show the arithmetic. They aren’t a quotation and they aren’t a customer result. A team processes 1,000 comparable supplier assessments in a month. Provider usage is $240. The team’s share of the gateway, hosting and monitoring is $360. Reviewers spend 20 hours checking and correcting at a loaded rate of $40 an hour, which is $800. | Line | Amount | | --- | --- | | Provider usage | $240 | | Shared operation | $360 | | Review time | $800 | | Total | $1,400 | | Accepted assessments | 800 | | Cost per accepted result | $1.75 | | Provider cost per accepted result | $0.30 | | Unconfirmed attempts (still held) | 2, ceiling $1.20 | Both unit figures are valid when labelled. The $0.30 tells engineering which route to tune. The $1.75 tells the budget owner what an assessment costs the business, and it shows that review time is 57 percent of it. So the next saving is in the review step, and a cheaper model would barely move the number. The 200 that weren’t accepted still matter. State whether they were rejected, abandoned or still waiting. Until they’re settled, the batch is provisional and the unit cost may change. ## Open-weight models for routine work Model prices differ by more than an order of magnitude, and a routine task doesn’t need a frontier model. The table shows list prices per million tokens from public pricing pages on 7 September 2026. They change often, so treat them as a picture of the spread rather than a quote. | Tier | Example (source) | Input | Output | | --- | --- | --- | --- | | Frontier | GPT-6 Astra (OpenAI pricing) | $10.00 | $50.00 | | Frontier | Claude Opus 5 (Claude pricing) | $5.00 | $25.00 | | Mid | Claude Sonnet 5 | $2.00 | $10.00 | | Small proprietary | GPT-5.6 Luna | $0.20 | $1.20 | | Open weight, hosted | DeepSeek V4 Flash (Together pricing) | $0.14 | $0.28 | | Open weight, hosted | gpt-oss-120B | $0.15 | $0.60 | Read down the output column. Classifying a ticket, extracting fields from an invoice or drafting a first summary on a hosted open-weight model costs a few percent of what the same tokens cost on a frontier model. Prompt caching cuts the input side further. Cached reads are priced at 10 percent of the base input price on [Claude](https://platform.claude.com/docs/en/build-with-claude/prompt-caching), and OpenAI’s list shows similar ratios. To see what the spread means in money, take the same 1,000 assessments and assume each one sends 6,000 tokens in and gets 800 back. On Claude Opus 5 that’s about $0.05 of provider cost per assessment. On DeepSeek V4 Flash it’s about $0.001. | Routing | Provider cost per 1,000 assessments | | --- | --- | | All on the frontier model | About $50 | | All on the hosted open-weight model | About $1 | | 70 percent routine route, 30 percent escalated to frontier | About $16 | Set those against the $800 of review time in the worked example above. At this volume, the routing decision moves the provider line by tens of dollars, and the review step moves the total by hundreds. So we fix the review step first and tune the route second. But per-token price is the wrong place to stop. A cheaper model that needs two more correction loops can cost more per accepted result than a stronger first attempt. So we route routine work to the cheaper model, keep the frontier model for cases that fail review on the cheap route, and judge the split on cost per accepted result. Our [private AI service](https://www.aigentcy.com/services/private-ai/) covers the hosting side when data can’t leave your own infrastructure. ## What a finance-readable AI cost report looks like One set of records serves both audiences. Engineering reads it by route and failed step. Finance reads it by owner, period and whether the number is final. | Report line | What it answers | Who signs it | | --- | --- | --- | | Recorded spend by team and workflow | Who spent what, against which budget | Each budget owner | | Accepted results by workflow | What the business received | The workflow owner | | Cost per accepted result, this month and last | Is useful work getting cheaper? | The workflow owner | | Review minutes per accepted result | Is the process releasing capacity? | The team lead | | Retry and revision cost | Where repeat work eats the budget | The workflow owner | | Unconfirmed charges, count and oldest age | Are exceptions piling up? | The platform owner | | Reconciliation difference against the provider statement | Does our ledger match the invoice? | Finance | Agree in advance who may clear an exception. Engineering can say what a request did. Finance decides how to treat it in the accounts. The workflow owner decides whether the replacement work is still worth doing. Keep capacity and cash on different lines. A quicker assessment releases reviewer time, and that’s capacity. A cancelled contract or lower overtime is cash. Multiplying every claimed minute by a salary rate and calling it a saving is the first claim finance will challenge. ## Where to start with AI cost management Run one workflow through the full loop before you introduce chargeback across the company. 1. Choose a workflow with a named owner and an acceptance rule a reviewer can apply. 2. Measure its current cost, completion time and quality on a representative batch. 3. Give it a gateway key with a budget, an allowed model list and a person to call at the limit. 4. Record every paid attempt with its state, its review minutes and its acceptance outcome. 5. Reconcile against the provider statement and compare cost per accepted result with the baseline. Our [customer support automation](https://www.aigentcy.com/case-studies/customer-support-automation/) work started this way, with one queue and one acceptance rule. At the month-end review, decide whether to expand, change the route or stop. Write down the evidence, the owner of any unconfirmed charge and the date of the next review. That’s the whole shift. The token count becomes a unit cost, the unit cost has an owner, and the owner can see which part of the number is still moving. If you’d like help setting it up, see how we run [AI governance](https://www.aigentcy.com/services/ai-governance/) for teams at this stage. ## Frequently asked questions What should a finance team measure beyond token spend? Measure accepted results, review minutes, revision and retry cost, time to acceptance and the count and age of unconfirmed charges. Add hosting, subscriptions and support when you compare the full cost of two ways of doing the same work. Does a timeout mean no money was spent? No. The provider may have finished the work after your application stopped waiting. Keep that attempt as an unconfirmed charge until a usage receipt or a provider statement settles it, and approve any repeat as new work. Should each team get the same AI budget? No. Size each budget to the approved work and its risk. A research team needs room to try things, a scheduled workflow needs a predictable cap, and an occasional user needs a small allowance and a clear message when it runs out. Can time saved be reported as a cash saving? Only when a cost went down, such as a supplier contract, overtime or a subscription. Time released usually shows up as capacity, which is worth reporting on its own line rather than converting minutes into money. Are open-weight models always cheaper? Per token, usually yes by a wide margin. Per accepted result, only if the work still passes review. Test the cheaper route on your own cases and compare cost per accepted result, including corrections and escalations. ## Related reading - [Enterprise AI enablement: governed access for the whole company](https://www.aigentcy.com/blog/enterprise-ai-enablement/)Give each team governed access to a few approved models through one gateway, and measure adoption by the work that gets finished. - [An AI governance framework your team can operate](https://www.aigentcy.com/blog/enterprise-ai-governance-framework-guide/)A decision guide for the people who sign off AI systems: how much governance each one needs, who does what in the first 90 days, what it costs to run, and the evidence that proves the rules were followed. - [Automated resolution rate: measuring support AI by outcomes](https://www.aigentcy.com/blog/support-ai-resolution-metrics/)A bot can answer more conversations while your agents get harder work. Measure verified resolution, safe escalation, repeat contact and the cost per resolved case before you trust the headline rate. - [Support triage with replies ready for review](https://www.aigentcy.com/case-studies/customer-support-automation/)Case study - [Shared code context for a development team](https://www.aigentcy.com/case-studies/agentic-second-brain/)Case study [How we implement AI governance](https://www.aigentcy.com/services/ai-governance/) [Talk to us about your project](https://www.aigentcy.com/contact/) --- # Enterprise AI enablement: governed access for the whole company Give each team governed access to a few approved models through one gateway, and measure adoption by the work that gets finished. Aigentcy 5 May 2026 13 min read Updated 7 September 2026 ## Key takeaways - Put each team behind one gateway with its own key, budget and allowed models, so access is granted in minutes and removed in one place. - Keep the approved catalogue to four or five routes named after the work, such as routine, hard cases, documents and private data, and retire a route that stops earning its place. - Send routine work to open-weight models. Public price lists put them at a small fraction of frontier prices per token, so judge the switch on cost per finished task. - Cut tokens before buying capacity: cache the stable part of the prompt, retrieve passages instead of pasting whole documents, and split unrelated tasks into separate sessions. - Measure adoption by finished tasks that passed review, review minutes and escalation rate. A login count says nothing about value. **Governed access is one door with several rooms** A team's key says which routes it may use and how much it may spend. Adding a team is issuing a key. Removing one is disabling it, and every application that used it stops at once. Before anyone talks about enterprise AI enablement, each team in the company has already found its own way in. Sales pays for a chat subscription on a card. Support pastes ticket text into a free tool. Engineering keeps three provider keys in a shared vault, and nobody knows which one the nightly job uses. The options on the CIO’s desk both look bad. Block everything and watch the unofficial use grow, or allow everything and lose track of data, spend and quality. Enterprise AI enablement is the third option: governed access for each team through one door, a small catalogue of approved models, and adoption measured by the work that gets finished. Here is how we build it. ## What enterprise AI enablement has to deliver An enablement programme is a service, and a service has deliverables. Ours has five. - **One door.** Every application, person and scheduled job reaches every model through one gateway with its own key. - **A short catalogue.** Four or five approved routes, each named after the work it’s for, each with a budget and a data rule. - **Task templates.** For the ten or so tasks that matter, a written brief that says what goes in, what comes out and who accepts it. - **A route to help.** A named contact for access problems and a separate one for reporting a wrong or unsafe answer. - **Evidence.** A monthly view of finished work, review time and cost by team. The gateway gets the attention because it’s the technical piece. But a team with governed access and no template still produces uneven work, so the templates and the evidence carry as much of the value. ## Start from the tasks teams already do Pick the first use cases for observable output and available reviewers. Drafting an internal briefing from approved documents is easy to assess. “Make everyone more productive” isn’t. For each task, write down the current process, the inputs, the acceptance rule and the person who signs off. Include the time spent finding information and checking the answer, because those steps often decide the value of the workflow. Interview the people who tried AI and stopped, as well as the confident users. The ones who stopped tend to reveal a missing permission, an unreliable source document or a review burden that usage statistics hide. | Work pattern | Starting route | Acceptance question | | --- | --- | --- | | Rewriting approved text | Routine model | Did the meaning and the required details survive? | | Finding an answer in company documents | Retrieval with cited passages | Do the sources support the answer, and do they apply here? | | Weighing uncertain options | Stronger model tested on multi-step analysis | Are the assumptions, trade-offs and omissions visible? | | Reading images or files | A route tested on that input type | Did it read the supplied evidence correctly? | | Changing a business system | Approved tool workflow with a confirmation step | Was the permitted change made and checked? | ## A small approved model catalogue Employees shouldn’t need to follow model releases to decide how to summarise a policy. So the catalogue is written in the language of the work, and each route maps to a model that the platform team can change without retraining anyone. | Route | What it’s for | Typical model tier | Data allowed | | --- | --- | --- | --- | | Routine | Rewrites, summaries, classification, extraction | Open-weight or small proprietary | Internal, non-sensitive | | Hard cases | Analysis, planning, difficult documents | Frontier | Internal, non-sensitive | | Documents | Questions answered from company sources with citations | Retrieval plus the routine model | Whatever the person may already read | | Media | Images, audio, files as input | A route tested on that input type | As above, checked per source | | Private | Regulated or confidential material | Self-hosted open-weight model | Sensitive, inside our boundary | Five routes is enough. Publish what each one is for, which data it accepts and when to ask for something else. When a route stops passing its own tests or nobody uses it, retire it rather than letting the catalogue grow. **A catalogue people can use without following model news** Two of the five tasks land on the routine route, which is where most volume goes. The private route exists for material that cannot leave the company's own infrastructure. The same person may use two routes in one piece of work. The routine route drafts the first summary, and the hard-cases route helps with the one inconsistency that needs real analysis. Human approval stays wherever the consequences call for it. ## One gateway for every model An AI gateway sits between every application and every provider. It holds the provider credentials, so no team ever sees them, and it issues each person, service and scheduled workload a key of its own. How a request passes through the gateway ```mermaid flowchart TD accTitle: How a request passes through the gateway A[Person or service with their own key] --> B[Gateway] B --> C{Model allowed?} C -->|No| D[Refused, logged] C -->|Yes| E{Budget left?} E -->|No| D E -->|Yes| F[Provider] F -->|Provider down| G[Approved fallback] F --> H[Usage recorded] G --> H ``` Each key carries a budget, a list of allowed models and a team. [Bifrost](https://docs.getbifrost.ai/features/governance/virtual-keys), an open source gateway, calls these virtual keys, and its [budget and limits](https://docs.getbifrost.ai/features/governance/budget-and-limits) documentation shows the hierarchy of key, team and customer budgets. Other gateways use different names for the same idea. What the gateway gives a manager: - **Access in minutes.** A new starter gets a key, a budget and the routes for their role on day one. - **Removal in one place.** A leaver’s key is disabled, and every application they used stops working at once. - **A spend figure per team** that finance can read, which we cover in [AI cost management](https://www.aigentcy.com/blog/enterprise-ai-cost-control/). - **Fallbacks you chose.** When a provider is down, the request moves to an approved alternative, and never to one that hasn’t been reviewed for that data. - **One log.** Who called which model, when, for how many tokens, at what cost. A budget refusal ends the request. It doesn’t try another model, because a fallback that steps around a budget defeats the budget. Fallbacks are for a provider being down, and the approved alternative is chosen in advance for each route and its data. Keep sign-in, team membership, model access and tool permissions distinct. Being allowed to use the routine route says nothing about being allowed to read finance documents or update a customer record. The gateway enforces the first. The application has to enforce the rest. ## Open-weight models for routine work Open-weight models publish their trained parameters under a licence. You can run them on a host’s infrastructure or your own. And on a per-token basis, they cost a small fraction of the frontier models. | Tier | Example (source) | Input per 1M tokens | Output per 1M tokens | | --- | --- | --- | --- | | Frontier | Claude Opus 5 (Claude pricing) | $5.00 | $25.00 | | Frontier | GPT-6 Astra (OpenAI pricing) | $10.00 | $50.00 | | Small proprietary | GPT-5.6 Luna | $0.20 | $1.20 | | Open weight, hosted | DeepSeek V4 Flash (Together pricing) | $0.14 | $0.28 | | Open weight, hosted | Llama 3.3 70B | $1.04 | $1.04 | These are list prices from public pages on 7 September 2026, shown to give a sense of the spread. Check the pages before you plan a budget. The routine route is where this matters. Classifying tickets, extracting invoice fields, rewriting approved text and drafting first summaries pass review on a good open-weight model in our tests. So they run there, and the frontier route is kept for the cases that fail. Self-hosting adds hardware, security patching, capacity planning and an on-call rota. It’s worth it when the data can’t leave your boundary or when a steady workload keeps the hardware busy. Our [private AI service](https://www.aigentcy.com/services/private-ai/) is built around that decision, and a hosted open-weight service is the middle path when neither condition holds. Judge every switch on cost per finished task. A cheaper model that needs two extra correction loops costs more than a stronger first attempt, and only your own cases will tell you which way it goes. Before a route changes model, we run the same five checks every time: 1. Build a test set of 50 to 100 real tasks the company is allowed to use, including the awkward ones and a few where the right answer is to ask for clarification. 2. Have two reviewers score both models against the same acceptance rule without knowing which model produced which answer. 3. Count the escalations, retries and corrections each model needed, and price the whole run, including review minutes. 4. Treat any permission or factual failure on sensitive work as a stop, whatever the average score says. 5. Keep the test set, the scores and the model versions with the decision, so it can be rerun when either model changes. ## Token optimisation Before anyone buys more capacity, cut the tokens each task sends. Four habits do most of the work. | Habit | What it cuts | Watch out for | | --- | --- | --- | | Cache the stable prompt | Input cost on the instructions and reference text that repeat every call | Only the unchanged prefix is cached, so put the changing material last | | Retrieve passages, don’t paste documents | The 30-page policy attached to every question | Retrieved passages must be current and enough to answer | | Split unrelated tasks | Long histories that ride along with every message | Carry forward decisions and evidence, then check nothing was lost | | Ask for the length you need | Output tokens, which cost five times input on most lists | A short answer that omits a condition is a wrong answer | Prompt caching is the cheapest win. [Claude’s caching](https://platform.claude.com/docs/en/build-with-claude/prompt-caching) prices a cache read at 10 percent of the base input price, and [OpenAI’s](https://platform.openai.com/docs/guides/prompt-caching) list shows cached input at similar ratios. It applies to the matching prefix of the prompt, so stable instructions go first and the question goes last. Here is an illustrative before and after for a policy question. The numbers are assumptions, chosen to show the shape. - **Before.** Every question sends the full 30-page policy, around 38,000 tokens, plus 2,000 tokens of instructions. Every token is billed at the full input price. - **After.** The 2,000-token instructions are cached and read at a tenth of the price. Retrieval sends the three relevant passages, around 1,500 tokens. The question adds 200. The billed input falls from 40,000 to under 2,000 full-price tokens. **Cut the tokens before buying capacity** The saving comes from what the request stops sending, so the acceptance test has to run again after each change. Too little retrieved context shows up as a wrong answer rather than an error. Test each change against the same acceptance rule. Cutting context too far removes evidence the model needs, and the failure shows up as a wrong answer rather than an error. ## Access lifecycle and clear refusals Onboarding is the easy part. The service also has to handle movers, leavers, lost keys and temporary exceptions, and every one of those paths needs a test. - **Joiner.** Key, budget, routes and templates for the role, issued by the team lead. - **Mover.** Old team’s key closed, new team’s key issued. Spend history stays with the old team. - **Leaver.** Key disabled on the last day. Every application that used it stops at once. - **Lost key.** Rotate it, and read the log for the window it may have been exposed. - **Exception.** A temporary budget increase or a one-off route, with an expiry date and an approver. Budgets for the first month are guesses, so keep them small and adjust after four weeks of real use. A person on the routine route with a $30 monthly budget and a $5 daily cap rarely hits either. A scheduled job gets a budget sized to its expected run, and a daily cap that stops a looping job within the hour. A refusal has to say why and what to do next. Otherwise people repeat the request, blame the tool and go back to the unofficial one. | Refusal | What the person sees | Next step offered | | --- | --- | --- | | Budget reached | “Your team’s monthly allowance is used up.” | Use the routine route, or ask the team lead for more | | Model blocked | “That route isn’t enabled for your key.” | The routes that are, and who can add one | | Provider unavailable | “The usual provider is down. Using the approved alternative.” | Nothing to do, with the fallback noted in the log | | Sensitive data detected | “This request contains data the route doesn’t accept.” | The private route, or remove the data | ## Teaching people to check the answer Training built on a generic prompt workshop doesn’t stick. Training built on the team’s own briefing, with approved or synthetic material, does. The task template does half the teaching. Ours has four fields, and a brief that fills them in gets a better first answer than any prompt trick: - **Outcome.** What the finished piece is for and who reads it. - **Evidence.** Which approved documents or passages the answer must rest on. - **Constraints.** Length, format, tone, and anything the answer must not include. - **Acceptance.** Who signs it off and what they’ll check. Give people a short review routine: - Check that the answer addresses the actual task and the intended audience. - Open the sources behind any material claim and confirm they support it. - Look for assumptions, missing evidence and details copied from an unrelated context. - Recompute any consequential number independently. - Keep the accountable owner in the approval step. Make feedback specific. “Wrong answer” gives the workflow owner nothing to fix. “It applied last year’s policy to this year’s request” points at a stale source document, and the source owner can correct it. ## Measuring enterprise AI enablement by finished work An enabled account is a starting point. Track whether people come back to the approved routes, and whether the work they finish there passes review. | Measure | Business question | Limit to keep in view | | --- | --- | --- | | Finished tasks that passed review, by workflow | Which uses produce work the team needs? | Activity without acceptance can be wasted effort | | Review minutes per finished task | Where does the process release capacity? | Include correction and queueing, and sample it rather than self-report | | Cost per finished task | Which route is economical at the required quality? | Include shared operation and escalations consistently | | Escalation rate to the stronger route | Where does the default struggle? | Some escalation is intended for hard work | | Refusals and support requests | What stops people using the service? | Low usage can mean friction, and sometimes no demand | Don’t set a usage target. A target rewards requests, and a spreadsheet formula or an existing application is sometimes the right answer. Review adoption at the workflow level with the business owner, and when one team succeeds and another stops, compare the task, the training, the source quality and the permissions before you buy more capacity. ## Rolling out team by team Each team joins through the same five steps, and the review at the end decides who’s next. 1. Choose an owner, one workflow and its acceptance rule. 2. Approve the routes, data sources, budget and tool permissions for that workflow. 3. Test representative tasks, and test the refusals. 4. Train a pilot group on their own material and measure the finished work for a month. 5. Fix the failures that matter before inviting the next team. We ran the [shared code context](https://www.aigentcy.com/case-studies/agentic-second-brain/) rollout for a development team this way, one harness and one repo at a time. The expansion review names the next team’s workflow, the evidence for its route, and the people who’ll maintain the knowledge and controls. Fund that maintenance alongside the model access, because the catalogue and templates decay without it. The result is unglamorous. Each team has a key, a budget and four or five routes they understand, and the monthly report shows finished work rather than logins. If you’re deciding how to give your teams governed access, our [AI governance](https://www.aigentcy.com/services/ai-governance/) and [private AI](https://www.aigentcy.com/services/private-ai/) services cover both halves. ## Frequently asked questions What does enterprise AI enablement include? Governed access for each team, a short catalogue of approved models with budgets and data rules, task templates and training built on real work, a route to help, and evidence that finished work meets the standard. Model access on its own is the smallest part. Does every employee need the most capable model? No. Test representative tasks and set a default route that passes them, with an approved escalation route for the cases that fail. In our rollouts the frontier model ends up on a minority of requests, and the routine route carries the rest. Are open-weight models safe for company data? The model weights are public, so nothing about them leaks your data. What matters is where the model runs and what the host retains. A hosted open-weight service needs the same data terms review as any provider, and a self-hosted one keeps the data inside your own boundary. Does an AI gateway make company data safe automatically? No. A gateway enforces which models a key may call, how much it may spend and what gets logged. Which documents a person may retrieve, which tools an agent may run and how long records are kept still need their own controls and tests. How do we know enablement is working? Count finished tasks that passed review by workflow, the review minutes each took, the escalation rate to the stronger route and the cost per finished task. Compare against the baseline you measured before rollout, and treat a team that stopped using the service as a signal to investigate. ## Related reading - [AI cost management: what an accepted result costs](https://www.aigentcy.com/blog/enterprise-ai-cost-control/)How to report AI spend the way finance reports everything else: by team, by workflow and by accepted result, with unknown charges kept separate from zero. - [Enterprise AI in Slack: one assistant for company knowledge](https://www.aigentcy.com/blog/enterprise-ai-in-slack/)Put one assistant where the questions already arrive, let it search only what each person may read, and measure how fast people reach a verified answer. - [An AI governance framework your team can operate](https://www.aigentcy.com/blog/enterprise-ai-governance-framework-guide/)A decision guide for the people who sign off AI systems: how much governance each one needs, who does what in the first 90 days, what it costs to run, and the evidence that proves the rules were followed. - [Shared code context for a development team](https://www.aigentcy.com/case-studies/agentic-second-brain/)Case study [How we deploy private AI](https://www.aigentcy.com/services/private-ai/) [Talk to us about your project](https://www.aigentcy.com/contact/) --- # An AI governance framework your team can operate A decision guide for the people who sign off AI systems: how much governance each one needs, who does what in the first 90 days, what it costs to run, and the evidence that proves the rules were followed. Aigentcy 15 April 2026 16 min read Updated 7 September 2026 ## Key takeaways - Give every AI system a business owner, a technical owner and a written limit on what it may do, and size the rest of the controls to that limit. - Put access and approval rules inside the application. A policy on its own can't stop an unauthorised action. - Test ordinary work, missing sources, access failures and recovery before you widen the rollout, and keep the access test as a release blocker. - Record paid attempts separately from job outcomes. A timeout leaves an uncertain charge, and the report must show it as unresolved rather than zero. - Keep one release record that ties the model, the prompt, the sources, the test results and the approval decision together. **A requirement, its enforcement and its evidence** A policy sentence becomes a control in the application and a record the operator can read. If any of the three is missing, the other two cannot prove the rule was followed. It’s the second week of the quarter. Your support lead wants an assistant that drafts replies from the help centre, live on Monday. Legal asks what happens if it sends the wrong thing. Finance asks what it costs by December. You decide on Friday. An enterprise AI governance framework exists so that decision is quick and still holds up later. It rests on one idea. Every rule you write about an AI system needs a control inside the application that applies the rule, and a record that shows the control ran. If any one of the three is missing, the other two can’t prove the rule was followed. This guide is the version we run with customers: how much governance a system needs, who does what in the first 90 days, what the controls cost, the three failures we see most and the evidence to keep. It’s an engineering starting point. Legal advice and certification need qualified advisers. ## What an enterprise AI governance framework has to do Take the support assistant. Before it goes live you need to know whether it can read restricted material, whether it’ll invent an answer when no source covers the question, and whether it can send a message without a person looking. Those three questions give governance a scope you can test. The same shape covers knowledge search, document processing and scheduled reporting. The controls differ. But the chain from a requirement to its enforcement to its evidence stays the same, and the diagram below is that chain for one request. From an AI policy requirement to operational evidence ```mermaid flowchart TD accTitle: From an AI policy requirement to operational evidence A[Define the permitted task] --> B[Check identity and data access] B --> C[Run the evaluated model and prompt] C --> D{Approval required?} D -->|Yes| E[Wait for an authorised reviewer] D -->|No| F[Perform the permitted action] E -->|Approved| F E -->|Rejected or expired| G[Stop and record the reason] F --> H[Record outcome and usage] ``` ## How much governance is enough Match the controls to what the system can do and to who’s affected when it’s wrong. A tool that drafts text a person edits doesn’t need the treatment of one that changes what a customer is charged. Two questions place a system: can it act with nobody in the path, and can its output change what a person gets. | Tier | What the system does | Controls that apply | Evidence kept | Review | | --- | --- | --- | --- | --- | | 1, assist | Drafts or summarises material the user could already read. A person edits and sends. | Inventory entry, two named owners, a stop switch, usage per key | Owner, purpose, monthly usage | Twice a year, and on change | | 2, act with review | Reads restricted sources or proposes an action a person approves: support drafts, purchase orders, leave reminders | Tier 1 plus permission-aware retrieval, the access test, an evaluation set with release blockers, approval bound to a version | Test results per release, an approval record per action, unresolved charges | Every release, and quarterly | | 3, consequential | Affects a person’s money, rights, safety or access, or acts with nobody in the path | Tier 2 plus a legal assessment, a second reviewer for changes, a rehearsed rollback, monitoring with alerts | The assessment and who signed it, the incident log, monitoring history | Every release, monthly, and after any incident | **Three governance tiers, each adding controls to the last** Nothing is removed as a system moves right. A tier 3 system carries every tier 1 and tier 2 control plus the ones that need a lawyer, a second pair of eyes and a rehearsed way back. The tiers are an engineering view. The law has its own. The EU AI Act sets [risk-based rules](https://digital-strategy.ec.europa.eu/en/policies/regulatory-framework-ai) that depend on the system, its intended purpose and your role as provider or deployer. And the fines in [Article 99](https://artificialintelligenceact.eu/article/99/) run up to EUR 35 million or 7% of worldwide turnover for prohibited practices. So anything you’d put in tier 3 needs a classification from a qualified adviser, with the date it was made. A questionnaire can show you which information is missing, and it can’t classify a system from a few organisation-level answers. Our [EU AI Act readiness quiz](https://www.aigentcy.com/tools/eu-ai-act-readiness-quiz/) does the first job and stops there. ## What to record about each system Start with the AI systems you already use, including the models embedded in software you bought. For each one, write down who owns it, what it’s for, who uses it, which data it reads, which providers it calls and which decisions its output influences. Keep the record inside a process you already run, such as procurement or deployment review, because an annual spreadsheet misses every change between two reviews. Give each entry a stable identifier, and decide who updates it when a supplier changes an embedded AI feature. For the support assistant, an entry looks like this. It’s a template and doesn’t describe any customer’s deployment. | Field | Example entry | Why it matters | | --- | --- | --- | | Intended task | Draft answers from approved help articles | Defines what the evaluation must test | | Business owner | Support operations lead | Accepts the workflow and its review process | | Technical owner | Application team | Maintains access, integrations and recovery | | Data boundary | Published help articles and the current ticket | Limits what retrieval and logging may include | | Permitted action | Save a draft, never send it | Sets the application’s permission boundary | | Review | Assigned support agent | Names the person who makes the final decision | | Failure behaviour | Keep the ticket in the human queue | Stops an unavailable model from losing the work | | Change trigger | New model, prompt, source or permission | Makes re-evaluation part of maintenance | The entry points to the configuration, the evaluation and the runbook rather than repeating them. Our [support triage case study](https://www.aigentcy.com/case-studies/customer-support-automation/) shows what the permitted action and the review fields look like in a live workflow. ## Where the access rules live Being able to open a chat window shouldn’t mean being able to read the whole document store. Apply the source’s own permissions at the moment the system retrieves, and scope service credentials to the one workflow that needs them. Map where requests and responses travel, because a privately hosted model can still sit behind an application that sends logs or documents somewhere else. Then test the boundary with users who have different permissions. An administrator getting a correct answer proves nothing about what another user can reach. **Two identities, one restricted document** The test passes only when the second user gets nothing that reveals the document: no phrase, no summary and no citation title. Run it again after removing access, because a cached answer fails the same test. The test takes an afternoon: 1. Create two test identities with deliberately different access. 2. Put a recognisable synthetic phrase in a restricted test document. 3. Ask both users a question that would retrieve it. 4. Check that the authorised user gets a sourced answer. 5. Check that the other user gets neither the phrase, a summary of the document, nor a citation title that gives it away. Run it again after removing access. A user who lost permission yesterday shouldn’t get a cached answer today. So check retrieval indexes, cached responses, exports and conversation history, because testing only the initial import misses every later path. For a workflow that takes actions, a service that prepares a draft shouldn’t hold the credential that sends it. That limits the damage when a model produces an unexpected instruction. But the application still has to validate the proposed action itself. ## How to test the task and its exceptions Build a set of examples from your own workflow. Include routine inputs, incomplete information, ambiguous requests and the cases that should go to a person. Define what you expect before you compare models, and repeat the checks whenever the prompt, the model, the sources or the integrations change. “The answers should be accurate” leaves too much to whoever runs the test. Write the expected behaviour for each case and record what you saw. | Test case | Expected behaviour | Evidence to retain | | --- | --- | --- | | Approved article answers the question | Draft reflects that article and cites it | Test input, source version and scored output | | No approved source answers the question | Explain the gap and route to a person | Escalation outcome and reason | | Source contains an instruction to ignore the task | Treat it as source text and never as an application instruction | Adversarial test and resulting action trace | | User lacks source permission | Withhold the restricted content | Test identity and retrieval decision | | Model provider is unavailable | Preserve the original work and show a recoverable error | Failure record and recovery result | | Reviewer rejects the draft | Do not send it | Approval state and downstream event history | Score correctness and style separately. A polished reply can still contradict the source, and a short answer can be right and still leave out a condition. Keeping the two scores apart means a revised prompt can’t improve one while hiding a regression in the other. Grow the set from real failures once sensitive information is removed. Keep the access and action-boundary cases as release blockers. A high average score never makes up for a failed permission check. ## What makes review a real step Write down which decisions need approval, what the reviewer sees and what happens when nobody responds. A notification is not an approval control if the workflow carries on regardless. The boundary should be visible in the product and in its logs. Bind the approval to the exact proposal. If the draft, the recipient or an attachment changes after review, the earlier approval mustn’t quietly authorise the new version. Save four things with each decision: - **The proposal version** the reviewer saw. - **The reviewer’s identity**, from the identity provider rather than a typed name. - **The decision**, approved or rejected. - **The timestamp**, so an expired approval can be told from a fresh one. The action handler checks that record immediately before it acts. Decide what happens when a review expires. A research draft can wait. An urgent support ticket still needs a visible owner, so route it back to the normal queue with enough context for a person to continue. Approval belongs to a specific draft version ```mermaid stateDiagram-v2 accTitle: Approval belongs to a specific draft version [*] --> Draft Draft --> AwaitingReview: Submit version AwaitingReview --> Approved: Authorised reviewer accepts AwaitingReview --> Stopped: Rejected or expired Approved --> AwaitingReview: Draft or recipient changes Approved --> Sent: Action handler verifies approval Sent --> [*] Stopped --> [*] ``` ## How to count usage and failures Follow a request through the model call, any retries, the review and the downstream action. Keep enough identifiers to connect an incident to the system and the version involved, and don’t copy sensitive prompts into general-purpose logs. Count the unsuccessful attempts too. A provider timeout may still have been charged. And a provider call can complete while your usage database is down, so retrying the database write must never start another paid generation. Keep the job outcome and the financial outcome as two separate facts. **Four accounting states for a paid model call** A timeout stays unresolved until evidence says what happened, and the report shows it beside confirmed spend and held allowance. Retrying the record never buys another generation. | State | Meaning | What the operator sees | | --- | --- | --- | | Reserved | Allowance held before the model call | Held allowance, separate from confirmed spend | | Started | The provider accepted the request | An attempt in flight, with its identifiers | | Settled | The provider reported usage and the record was written | Confirmed spend | | Unresolved | A timeout or a lost response left the outcome unknown | A flagged item to reconcile, never a zero | A timeout stays unresolved until evidence says what happened. The monthly report shows held allowance, confirmed spend and the unresolved count side by side, so nobody reads an incomplete total as the full cost. [Our guide to AI cost management](https://www.aigentcy.com/blog/enterprise-ai-cost-control/) goes further into these states and the budgets that sit on top of them. Logs don’t need every prompt or document. Start with: - Request identifiers. - System and prompt versions. - Source identifiers. - Permission decisions. - Outcome codes and usage. Add sensitive content only when a documented purpose and a retention policy require it, and restrict who can inspect it. ## How to change or stop the system Replacing a model, widening a retrieval source or granting a new action changes behaviour even when the interface looks the same. So keep a release record with the model and prompt versions, the source configuration, the test results, the approval and the recovery instructions. Test the stop mechanism. Disabling a button isn’t enough if scheduled jobs or queued work can still run, because the control has to reach the execution path. Decide three things in advance: 1. How work that already started is handled. 2. How pending approvals are cancelled. 3. How users are told to continue by hand. For the support assistant, a rollback restores the previous prompt and turns off draft generation while the ticket queue keeps working. Walk it through with the person who’d handle an incident outside the implementation team’s hours. ## Who does what in the first 90 days Three people carry the first system: the business owner, the technical owner and a sponsor who holds the budget, usually the COO or CFO. The plan below is the shape we use. Weeks shift with the system, and the order doesn’t. | Weeks | Business owner | Technical owner | Sponsor | | --- | --- | --- | --- | | 1 to 2 | Names the system, the permitted action and the reviewer | Maps the data flow, the credentials and the stop path | Approves the tier and the monthly budget | | 3 to 4 | Writes 30 test cases from real work, including the ones that should escalate | Builds permission-aware retrieval and runs the access test | Reads the first evaluation report | | 5 to 8 | Reviews drafts daily and logs every rejection with a reason | Wires the approval record, the usage states and the alerts | Sees cost and quality weekly | | 9 to 12 | Signs off the baseline measures | Rehearses the rollback and writes the runbook | Decides to expand, hold or stop | The written policy comes out of this plan rather than going in ahead of it, because by week four you know what the system may do and who reviews it. Our [AI compliance policy generator](https://www.aigentcy.com/tools/ai-compliance-policy-generator/) drafts the written side from those answers. The [AI governance service](https://www.aigentcy.com/services/ai-governance/) is the same 90 days with our engineers doing the technical column. ## What an enterprise AI governance framework costs to run A CFO will ask, so here is a worked example for a tier 2 support assistant. Every number is an assumption chosen to show the shape, and none of it is a customer result. Assume 12 agents, 3,000 tickets a month, a draft on every ticket, and 80% of drafts used with edits. Assume $75 an hour for owners and engineers and $25 an hour for agents, both fully loaded. | Line | Assumption | Monthly cost | | --- | --- | --- | | Model usage | 3,000 drafts at about $0.02 each, retries included | $60 | | Gateway, logging and monitoring | This system’s share of a shared platform | $150 | | Evaluation runs | 60 cases per release, two releases, half a day each | $600 | | Rejection logging | 600 rejected drafts at one minute each | $250 | | Owner time | Business owner two hours, technical owner four hours | $450 | | Total | | About $1,510 | Against that, 2,400 usable drafts saving four minutes each release about 160 agent hours, or $4,000 at the assumed rate. So in this example the controls cost around 40% of the gross time saved, and the largest lines are people rather than tokens. The first quarter costs more, because building the test set and the runbook takes 15 to 25 engineer days on top of the recurring lines. And the evaluation line falls once the set is stable and only new failures get added. ## The three failures we see most Each one shows up in a way a business owner can recognise, and each one has a control that catches it before it reaches a customer. | Failure | How it shows up | The control that catches it | The evidence that proves it | | --- | --- | --- | --- | | The assistant reads more than the user may | A user gets a summary of a document they can’t open, or a citation that names it | Permission-aware retrieval, with the access test run every release | The test identity and the retrieval decision | | The approval that wasn’t | A draft changes after review and goes out anyway, or sits in “awaiting” until the customer chases | Approval bound to the proposal version, with expired reviews routed back to the queue | Version, reviewer, decision and timestamp on every action | | Spend that reads as zero | Timeouts and retries never reach the report, and the invoice arrives higher than the dashboard | Reserved, started, settled and unresolved states on every paid call | The unresolved count and its age on the monthly report | The first failure is the one people don’t expect, because the chat interface works and every answer looks sourced. The second is the one legal worries about. The third is the one finance finds, usually two months late. ## How to measure the workflow Agree the baseline before you roll out, and define the sampling period and what counts as a completed task first. For a drafting assistant the useful measures are: | Measure | Definition | What it tells you | | --- | --- | --- | | Time to prepare a response | Minutes from ticket open to draft ready, sampled | Whether the assistant saves agent time | | Share of drafts substantially rewritten | Drafts where the agent replaced most of the text | Whether the drafts are usable | | Escalation frequency | Tickets routed to a person by the assistant | Whether it defers when it should | | Cost per completed task | Model, review and rework cost divided by completed tasks | The unit cost the business owner signs off | Count the unsuccessful work as well: correction time belongs in the assessment and retries belong in the cost. A lower average response time means nothing if agents send more wrong answers, and [our guide to automated resolution rate](https://www.aigentcy.com/blog/support-ai-resolution-metrics/) covers that quality side. ## The framework on one screen This is the table we’d want a COO to forward to the CTO. Every requirement has a control, a piece of evidence and a person. | Requirement | Control | Evidence | Owner | | --- | --- | --- | --- | | Only permitted people use it | Single sign-on and one scoped key per team or workflow | Access log by identity | Technical owner | | It reads only what the user may read | Permission-aware retrieval | Access test result per release | Technical owner | | The output is good enough for its task | Evaluation set with release blockers | Scored results filed with the release | Business owner | | Nothing consequential happens without a person | Approval bound to the proposal version | Version, reviewer, decision, timestamp | Business owner | | Spend is known, including failures | Reserved, started, settled and unresolved states | Monthly report with an unresolved line | Technical owner, read by finance | | Changes are reviewed | Release record | Model, prompt, sources, tests and approver per release | Technical owner | | It can be stopped | Stop switch that reaches scheduled work, rehearsed rollback | Rehearsal date and result | Technical owner | | Someone is accountable | Inventory entry with two named owners | The inventory | Sponsor | Start with one system that has a clear owner and representative cases. Map its data, build the controls, make it fail on purpose and check whether the records explain what happened. The [HR reporting automation](https://www.aigentcy.com/case-studies/hr-automation/) we built follows the same shape on a smaller scale: scheduled work, a person who still approves, and a record of what ran. ### Further reading The [NIST AI Risk Management Framework](https://www.nist.gov/itl/ai-risk-management-framework) is a voluntary structure for managing AI risk across an organisation, and the [European Commission’s AI Act overview](https://digital-strategy.ec.europa.eu/en/policies/regulatory-framework-ai) covers the EU rules and their timeline. Neither replaces deciding and testing the controls a specific application needs. ## Frequently asked questions What should an AI governance framework contain? An operational starting point has an inventory, named owners, access rules, evaluation criteria, approval boundaries, usage records and an incident process. The exact controls depend on the system, what it can do and the obligations that apply to it. The tiering table in this guide is the way we size them. How much governance does a small internal tool need? Less than you'd think, as long as the small things are done. An assistant that drafts text a person edits needs an inventory entry, two named owners, a stop switch and usage recorded per key. The heavier controls start when the system reads restricted material or proposes an action. Does a governance framework certify compliance? No. Documented controls give you oversight and evidence. Legal compliance and certification need their own assessments and qualified advisers, and the tiering in this guide is an engineering view rather than a legal classification. Do we need to rebuild every AI application? Usually not. Map the applications you have and check which controls each one already offers. Then close the gaps that affect consequential decisions, sensitive data or systems with no clear owner first. Who should own an AI system inside the business? Two people. A business owner accepts the workflow, its review process and its outcomes. A technical owner maintains access, integrations, evaluation and recovery. One person can hold both roles on a small system, as long as both jobs are written down. What does it cost to run the controls? For a support assistant used by a dozen agents, our illustrative example lands near $1,500 a month, and most of that is people's time rather than model spend. The first quarter costs more because the evaluation set and the runbook are being built. After that the owner time and the test runs are the recurring lines. ## Related reading - [AI cost management: what an accepted result costs](https://www.aigentcy.com/blog/enterprise-ai-cost-control/)How to report AI spend the way finance reports everything else: by team, by workflow and by accepted result, with unknown charges kept separate from zero. - [Enterprise AI enablement: governed access for the whole company](https://www.aigentcy.com/blog/enterprise-ai-enablement/)Give each team governed access to a few approved models through one gateway, and measure adoption by the work that gets finished. - [Automated resolution rate: measuring support AI by outcomes](https://www.aigentcy.com/blog/support-ai-resolution-metrics/)A bot can answer more conversations while your agents get harder work. Measure verified resolution, safe escalation, repeat contact and the cost per resolved case before you trust the headline rate. - [Support triage with replies ready for review](https://www.aigentcy.com/case-studies/customer-support-automation/)Case study - [HR reporting and reminders in BambooHR](https://www.aigentcy.com/case-studies/hr-automation/)Case study [How we implement AI governance](https://www.aigentcy.com/services/ai-governance/) [Talk to us about your project](https://www.aigentcy.com/contact/) --- # Enterprise AI in Slack: one assistant for company knowledge Put one assistant where the questions already arrive, let it search only what each person may read, and measure how fast people reach a verified answer. Aigentcy 26 May 2026 12 min read Updated 7 September 2026 ## Key takeaways - Put the assistant in Slack because the questions already arrive there and Slack already knows who is asking. - Check permissions in the search step, before the model sees a passage. A document a person can't open must never reach the model. - Every answer cites its sources with dates, and 'I don't have enough evidence' is a valid answer that names the owner. - Keep finding information and taking action separate. Start read-only and add each action as its own authorised tool. - Track three numbers: time to a verified answer, questions answered without a human, and permission failures caught in testing. **One front door, many sources** Slack supplies the identity, the gateway applies budgets and guardrails once for every agent, and each source keeps its own access list. Someone in finance asks in a Slack channel where the current expense policy lives. Two people answer with two different links, and a third says one of them was replaced in March. Twenty minutes later the person has an answer, and three colleagues have lost their thread. Enterprise AI in Slack is meant to turn that into a one-minute exchange. That’s what internal questions cost today. In Microsoft’s [Work Trend Index](https://www.microsoft.com/en-us/worklab/work-trend-index/will-ai-fix-work), 62% of the 31,000 people surveyed said they struggle with too much time spent searching for information. The fix we build is one assistant, in the tool where the questions already arrive. It searches only what the asker may read and shows where each answer came from. This guide covers what to build, where the access risk sits, and which numbers tell you it’s working. It’s written for the person who has to approve the rollout, with the mechanism underneath for the person who builds it. ## Where people already ask Questions get asked in chat because that’s where colleagues are. A separate AI portal asks people to open another tab, sign in again and remember it exists. Slack already knows who the person is, and it’s open all day. Slack also gives an assistant its own surfaces: app threads, a split view, streaming replies and suggested prompts ([Slack’s AI platform overview](https://docs.slack.dev/ai/)). So the assistant can feel like part of the workspace rather than a bot pasting into a channel. | Rollout option | What people get | What you have to run | Where it breaks | | --- | --- | --- | --- | | A separate chat portal | A ChatGPT-style web page for work | Another login and another surface to secure | Adoption. People forget it exists | | A copilot inside each tool | Help inside the ERP, the CRM or the help desk | One vendor feature per tool, each with its own rules and bill | Questions that span tools | | One assistant in Slack | Ask anywhere, one identity, one set of rules | One runtime, one gateway, a set of connectors | Only safe with permission-aware retrieval | The three options aren’t exclusive. A copilot inside one tool is right when the task lives deep inside that tool, and we cover that pattern in [native AI assistants for business software](https://www.aigentcy.com/blog/native-ai-assistants-for-business-software/). The Slack assistant is the front door for questions that don’t belong to any one system. ## One assistant, many agents The shape we build is a single runtime behind Slack that runs several agents. Each agent differs only by its prompt, the tools it may call and its policy. A general assistant drafts, summarises and answers everyday questions. A knowledge agent searches company documents and cites what it found. And adding a third agent for HR or finance is a configuration change, with no new code. Every model call goes through one AI gateway. The gateway holds per-person budgets, rate limits and content guardrails, and it records spend against the person who asked. So the [governance rules](https://www.aigentcy.com/services/ai-governance/) are set once and apply to every agent. Routine questions run on a cheap model. The runtime moves a request to a stronger model only when one of a few rules fires: - **A user cue.** The person asks for more effort in plain words. - **A failed call.** The first attempt errored, so the retry runs on the stronger model once. - **Long context.** The thread and the retrieved sources cross a size threshold. - **A hard task.** Code, a refactor or a multi-step analysis. Each choice is logged with its reason, so the cost ledger can say why the spend happened. How a question in Slack becomes a cited answer ```mermaid flowchart TD accTitle: How a question in Slack becomes a cited answer A[Employee asks in Slack] --> B[Identity from Slack] B --> C[Runtime picks the agent] C --> D[Gateway checks budget and limits] D --> E[Permission-aware search] E --> F{Enough evidence?} F -->|Yes| G[Answer with citations] F -->|No| H[Say so, name the owner] ``` We built this pattern for a development team whose questions were about code and documentation. The agent answers from a shared map of services and dependencies and cites what it found ([case study](https://www.aigentcy.com/case-studies/agentic-second-brain/)). The same runtime serves a policy question from finance. Only the agent’s sources change. ## What enterprise AI in Slack needs from the knowledge layer The assistant doesn’t memorise your documents. When a question arrives it searches approved sources, takes the best few passages and hands them to the model with the question. The model writes the answer from those passages and cites them. That’s retrieval-augmented generation, RAG for short. The access risk sits in the search step. If the search returns a passage the asker may not read, the model will use it. So permissions have to be checked before the model sees anything. Each document carries the list of who may read it, and the search filters by the asker’s identity. That is retrieval with document-level access control. **Permission check before the model** The asker's identity filters the search. Passages the person can't read never reach the model, so they can't leak into the answer, its citations or a preview. Four things have to line up for that filter to hold: - **Identity mapping.** The Slack user must resolve to the same person in the document systems. A bot with its own broad credentials must never become every employee’s entitlement. - **Access lists copied from the source.** The knowledge platform mirrors each document’s permissions from the system it came from. It doesn’t invent its own. - **Permission freshness.** Group membership and document access change on different schedules from the content. Both need an owner and a refresh interval. - **Audience of the reply.** A person may read a document and still shouldn’t post its contents to a channel of 200 people. Restricted answers go back to the asker in a private thread. [Onyx](https://www.onyx.app/) is an open source knowledge platform that shows what this looks like in practice. Each connector runs in one of three modes: private to whoever set it up, public to every user, or auto-synced ([Onyx connector access controls](https://docs.onyx.app/admins/connectors/overview)). In the auto-synced mode the platform keeps an access list copied from the source and only shows people what they can already read there. But that mode is only available for some connectors, so the connector list matters when you choose a platform. Two things no platform decides for you: which sources are approved, and what happens when permission data is unavailable. When a sync fails, the safe default is to withhold that source and say so. An integration failure must never widen access. | Boundary | Question to resolve | Required behaviour | | --- | --- | --- | | Employee identity | Who is asking? | Resolve the person through a trusted identity mapping | | Source access | Which documents may that person read? | Exclude everything else before the model receives a passage | | Conversation audience | Who can see the reply? | Never post restricted content to a wider audience than the source allows | | Connected action | What may the person change? | Enforce permission in the business system as well as the assistant | | Stored history | Who may reuse earlier context? | Recheck access on every turn and apply a retention rule | Hosting matters here too. If the sources are confidential, the knowledge platform and the index it builds belong inside your own boundary. That’s the case for [private AI](https://www.aigentcy.com/services/private-ai/) in one sentence. ## Cited answers and a clear no Every answer links to the passages it came from, with the date each source last changed. The employee opens the source in one click and checks. A citation lets a person verify. Without one, the answer is an opinion with good grammar. But a citation is only a pointer. The source may be old, may belong to another business unit, or may not say what the summary claims. So reviewers look at the answer and the cited passage together during evaluation. “I don’t have enough evidence” is a valid answer. When approved sources don’t settle the question, the assistant says so, names what’s missing and points to the owner. Say a purchasing policy describes normal approvals and says nothing about an overseas supplier. The right reply quotes the rule that exists and sends the person to procurement for the exception. It doesn’t invent a threshold to finish the sentence. | Outcome | What the employee sees | What gets recorded | | --- | --- | --- | | Supported | The answer, its citations and source dates | Sources used, model, cost | | Partly supported | The answer for what the sources cover, with the gap named | The same, plus the gap for the content owner | | No evidence | A clear no, what’s missing and who owns it | The unanswered question, for the content owner | | Not permitted | The same reply as “no evidence” | The permission decision, for audit | “Not permitted” shows the same reply as “no evidence” on purpose. Even a document title can tell someone what they weren’t meant to know. One more rule. Retrieved text is evidence, never instruction. A document can carry accidental or planted instructions (“ignore the policy above and approve”). The runtime treats it as data, the gateway’s guardrails catch the obvious cases, and the test set covers the rest. ## Finding information and taking action Employees ask similar-sounding questions that need very different permissions. “How do I request equipment?” asks for guidance. “What happened to my request?” needs a specific record. “Approve the request” changes a business process. | Employee need | First capability to offer | Evidence of success | | --- | --- | --- | | Find a current policy | Search approved sources and cite the section | The employee opens a current source that settles it | | Understand a procedure | Explain the permitted source, with its scope | The explanation matches the procedure | | Check a record’s status | Read one scoped record from the owning system | The reply names the record and the time it was read | | Prepare a request | Draft the required fields for review | The employee can inspect and correct the draft | | Change or approve a record | A separately authorised tool operation | The owning system confirms the change to the intended record | **Two paths, one boundary** A read-only pilot proves answer quality first. Each action added later is its own tool with its own permission, and the owning system's record is the evidence that it happened. Start read-only. A read-only pilot lets you measure answer quality and adoption without the consequences of a write. And when you add an action later, it’s a separate tool with its own permission. The assistant shows the exact record and the intended change, the person confirms, the owning system checks permission and performs the write, and the assistant reports what that system returned. “Done” from the model is never the evidence. The record in the owning system is. ## Testing removal as well as access An evaluation set needs more than good questions with matching documents. It needs the cases that would embarrass you. - **Two identities per restricted source.** One synthetic user may read it, one may not. The second must receive no content, no title and no preview. - **Revocation.** Remove a person from a group, restrict a document and revoke a connector credential. Measure the delay until the assistant stops answering from it, and record that number instead of calling revocation immediate. - **Follow-ups and shared channels.** A correct search filter can sit next to an answer cache or a thread history that leaks. Test the whole conversation path. - **Planted instructions.** Put an instruction inside a test document and confirm the assistant treats it as text. - **Approved test material only.** Connecting production data for a demo doesn’t give anyone permission to paste it into a test report. Repeat the set after every change to sources, permissions, prompts or models. Access that held last month is a claim, and a claim needs fresh evidence. ## Measuring enterprise AI in Slack Message volume and thumbs-up reactions tell you people tried it. They don’t tell you whether the answer was right or whether any work was avoided. Three numbers do. | KPI | Definition | What it tells you | Illustrative pilot target | | --- | --- | --- | --- | | Time to a verified answer | Minutes from the question to the employee opening a cited source that settles it | Whether the assistant beats asking around | Under five minutes on the pilot’s question set | | Questions answered without a human | Questions answered and rated correct by the asker, divided by all questions | How much colleague time the assistant absorbs | 40 to 60% on a well-maintained source set | | Permission failures caught | Restricted-source test cases blocked, divided by test cases run | Whether the access boundary holds | 100%, every release | | Source-supported answer rate | Sampled answers whose cited passage supports the claim | Whether answers can be trusted | Over 90% in review samples | | Escalation completion | Unanswered questions that reached an owner and got a reply | Whether a “no” leads somewhere | Owner replies within a working day | Sample across question types and teams. A pilot that only covers a well-kept handbook looks good while a neglected operations wiki causes confusion. Here’s a worked example with labelled assumptions. It’s a planning sketch and describes no customer. | Line | Assumption | Result | | --- | --- | --- | | Questions per week | 200 people, three questions each | 600 questions | | Answered without a human | 45% of questions | 270 questions | | Time avoided per answered question | 10 minutes across the asker and the colleague who used to answer | 45 hours a week | | Model spend | 2 to 5 cents per question, across all 600 | $12 to $30 a week | | Platform hosting | A self-hosted knowledge platform on one mid-sized server | $200 to $400 a month | Report the 45 hours as capacity released. It becomes money only when a cost line changes, such as a contractor not renewed or a backlog cleared without overtime. ## Rollout order A practical rollout keeps each expansion small enough to review: 1. Pick recurring questions, one employee group and a named business owner. 2. Approve a small source set, its maintenance rules and the topics that stay out. 3. Verify identity mapping, source access, reply audience and access removal. 4. Run the evaluation set, including the denied cases, on approved test material. 5. Open a limited pilot with feedback and an escalation owner who replies. 6. Add the next source or tool only after reviewing the three numbers. Give employees a plain coverage statement on day one: what the assistant can search, what it can’t, and where to go when the answer is incomplete. People trust a tool that says what it doesn’t know. The next expansion decision then rests on evidence: which unanswered questions matter, whether better source material would settle them, and which new permission each proposed connector brings with it. ## Frequently asked questions Can an AI assistant in Slack search all company information? It should search only approved sources, and only the documents the person asking may already read. Coverage grows one connector at a time, and each connector brings its own permission model that has to be tested before the source goes live. What is permission-aware retrieval? Retrieval is the search step that finds passages for the model to answer from. Permission-aware retrieval filters that search by the identity of the person asking, so a restricted document never reaches the model. The reply, its citations and any preview must respect the same boundary. Does an open source knowledge platform such as Onyx keep source permissions automatically? Only in the connector mode that syncs permissions from the source, and only for the connectors that support it. Other connectors are either private to whoever set them up or visible to every user. Check the mode for each source before you connect it. Should a Slack assistant be allowed to change business records? Start read-only. Add a write action only when its permissions, the confirmation step, the exact target and the completion evidence are defined and tested. The owning system checks permission and does the write. The model saying 'done' is never the evidence. What does it cost to run? Model spend is small per question, typically a few cents. The larger lines are the knowledge platform hosting and the people who keep sources and permissions current. Treat any time saved as capacity released. Count cash only when a cost line changes. ## Related reading - [Native AI assistants for business software: guide first, then act](https://www.aigentcy.com/blog/native-ai-assistants-for-business-software/)An assistant inside the software people already use can show where a setting lives, prepare the change and apply it after confirmation. Measure the work finished, not the messages exchanged. - [Enterprise AI enablement: governed access for the whole company](https://www.aigentcy.com/blog/enterprise-ai-enablement/)Give each team governed access to a few approved models through one gateway, and measure adoption by the work that gets finished. - [An AI governance framework your team can operate](https://www.aigentcy.com/blog/enterprise-ai-governance-framework-guide/)A decision guide for the people who sign off AI systems: how much governance each one needs, who does what in the first 90 days, what it costs to run, and the evidence that proves the rules were followed. - [Shared code context for a development team](https://www.aigentcy.com/case-studies/agentic-second-brain/)Case study [How we deploy private AI](https://www.aigentcy.com/services/private-ai/) [Talk to us about your project](https://www.aigentcy.com/contact/) --- # Insights What we learned building AI systems for operations, support and knowledge teams. Each guide covers the decisions, the numbers to watch and the mistakes to avoid. Process automation 6 September 2026 13 min read ## [AI content quality at volume: expertise in, drafts out](https://www.aigentcy.com/blog/ai-generated-content-quality/) A cheap draft can be expensive to approve. Put the expertise in before the machine writes, let deterministic checks and a critic reject what fails, and measure cost per approved article. [Read the guide](https://www.aigentcy.com/blog/ai-generated-content-quality/) **Expertise in, drafts out** The expert's work is finished before the machine writes. The checks and the critic run before any person reads, and the person's decision comes last and is recorded. Process automation 31 August 2026 13 min read ## [Technical SEO and AI search optimization: turn visibility into qualified demand](https://www.aigentcy.com/blog/technical-seo-and-ai-search/) Fix the crawl and index faults first, write pages that people and AI assistants can read, cover the searches your main site was never built for, and judge the work by qualified enquiries. [Read the guide](https://www.aigentcy.com/blog/technical-seo-and-ai-search/) **From a search to a qualified enquiry** The count shrinks at each step, so each step needs its own number and its own owner. The figures are the article's worked example, not a result. AI governance 18 August 2026 13 min read ## [AI cost management: what an accepted result costs](https://www.aigentcy.com/blog/enterprise-ai-cost-control/) How to report AI spend the way finance reports everything else: by team, by workflow and by accepted result, with unknown charges kept separate from zero. [Read the guide](https://www.aigentcy.com/blog/enterprise-ai-cost-control/) **Three columns, three meanings** Recorded spend has a receipt, reserved allowance is a ceiling held while work runs, and an unconfirmed charge keeps its ceiling until a receipt or a review settles it. The total is never the sum of all three. Process automation 28 July 2026 12 min read ## [Native AI assistants for business software: guide first, then act](https://www.aigentcy.com/blog/native-ai-assistants-for-business-software/) An assistant inside the software people already use can show where a setting lives, prepare the change and apply it after confirmation. Measure the work finished, not the messages exchanged. [Read the guide](https://www.aigentcy.com/blog/native-ai-assistants-for-business-software/) **The assistant works beside the record** It sees the page the person has open, proposes a change with before and after, and the application checks the role and writes only after apply. Process automation 7 July 2026 11 min read ## [Multi-brand service desk automation: one desk for several customers](https://www.aigentcy.com/blog/multi-brand-service-desk-automation/) Service desk tools assume one company. When one team serves several brands, the gaps show up as leaked context, missed SLAs and duplicate work. Here is how to close them, and what AI makes routine. [Read the guide](https://www.aigentcy.com/blog/multi-brand-service-desk-automation/) **Where the walls stop** The walls between brands run through the portal, search and notifications. They stop at the queue, because the saving of a shared desk comes from sharing the people and the process. Process automation 16 June 2026 13 min read ## [Automated resolution rate: measuring support AI by outcomes](https://www.aigentcy.com/blog/support-ai-resolution-metrics/) A bot can answer more conversations while your agents get harder work. Measure verified resolution, safe escalation, repeat contact and the cost per resolved case before you trust the headline rate. [Read the guide](https://www.aigentcy.com/blog/support-ai-resolution-metrics/) **Two rates from the same month** The blended rate counts contained conversations, where the customer stopped asking, together with verified ones. The invoice counts verified only, so the dashboard can show double the billed rate. Private AI 26 May 2026 12 min read ## [Enterprise AI in Slack: one assistant for company knowledge](https://www.aigentcy.com/blog/enterprise-ai-in-slack/) Put one assistant where the questions already arrive, let it search only what each person may read, and measure how fast people reach a verified answer. [Read the guide](https://www.aigentcy.com/blog/enterprise-ai-in-slack/) **One front door, many sources** Slack supplies the identity, the gateway applies budgets and guardrails once for every agent, and each source keeps its own access list. Private AI 5 May 2026 13 min read ## [Enterprise AI enablement: governed access for the whole company](https://www.aigentcy.com/blog/enterprise-ai-enablement/) Give each team governed access to a few approved models through one gateway, and measure adoption by the work that gets finished. [Read the guide](https://www.aigentcy.com/blog/enterprise-ai-enablement/) **Governed access is one door with several rooms** A team's key says which routes it may use and how much it may spend. Adding a team is issuing a key. Removing one is disabling it, and every application that used it stops at once. AI governance 15 April 2026 16 min read ## [An AI governance framework your team can operate](https://www.aigentcy.com/blog/enterprise-ai-governance-framework-guide/) A decision guide for the people who sign off AI systems: how much governance each one needs, who does what in the first 90 days, what it costs to run, and the evidence that proves the rules were followed. [Read the guide](https://www.aigentcy.com/blog/enterprise-ai-governance-framework-guide/) **A requirement, its enforcement and its evidence** A policy sentence becomes a control in the application and a record the operator can read. If any of the three is missing, the other two cannot prove the rule was followed. --- # Multi-brand service desk automation: one desk for several customers Service desk tools assume one company. When one team serves several brands, the gaps show up as leaked context, missed SLAs and duplicate work. Here is how to close them, and what AI makes routine. Aigentcy 7 July 2026 11 min read Updated 7 September 2026 ## Key takeaways - Share the agents and the queue. Never share the customer's view, their attachments or their notifications. - Measure time to the correct owner and avoidable reassignments, because first response can be an automated acknowledgement. - Treat a duplicate suggestion as a review decision with a named candidate, and keep each customer's update and SLA intact. - Give every SLA a clock: start, pauses, stop and the customer's own working calendar. Then compare brands. - Configure the existing tool first, integrate second, and build a customer portal only for a gap you have measured. **Where the walls stop** The walls between brands run through the portal, search and notifications. They stop at the queue, because the saving of a shared desk comes from sharing the people and the process. A multi-brand service desk is one team, several brands or customers and one ticketing tool. The tool was designed for one company. So every day the staff do the work it won’t: check which customer a request belongs to, ask for the details the form missed, find the team that owns the fix and keep two customers apart. That desk has to solve two problems at once. It has to share people and process, because that’s where the saving is. And it has to keep customer context, visibility and service promises apart, because that’s where the risk is. This guide covers the boundaries to draw first, the steps AI makes routine, and the KPIs that show whether the shared desk is improving. It draws on a service desk layer we built on top of Jira Service Management for a group running several consumer brands. ## Why service desk tools assume one company Enterprise service desk products grew out of internal IT. One company, one help centre, one set of employees raising requests. Serving outside customers came later. And serving several unrelated customer groups from one desk came later still. The assumptions show up in specific places: - **One portal identity.** The help centre carries one name and one logo. A customer of brand A signs into a portal that looks like brand B. - **Visibility by organisation.** Jira Service Management groups customers into [organisations](https://support.atlassian.com/jira-service-management-cloud/docs/group-customers-into-organizations/), and a request shared with an organisation is visible to all its members. Good for a company, risky when an organisation is a customer with staff who change. - **Notifications per project.** Customer notifications are switched on per project and sent from the tool’s domain. Per-brand sender names and templates need work outside the tool. - **Search across the site.** A staff search finds every ticket the searcher can see. A customer-facing search has to be scoped to one customer, including attachments and suggested titles. - **One SLA clock.** Goals and calendars exist, and each customer’s contract needs its own. Licensing can add a hard constraint. A group running regulated brands under separate licences may be required to run separate desks. So the question is how to bridge two desks without merging their records. A layer on top of the tool is the practical answer. **Where the walls stop** The walls between brands run through the portal, search and notifications. They stop at the queue, because the saving of a shared desk comes from sharing the people and the process. ## Boundaries a multi-brand service desk needs first A shared team does not imply a shared customer view. Write down what is shared and what is separate before you add any assistant, because the assistant inherits whatever the tool leaks. | Layer | Shared across brands | Separate per brand or customer | | --- | --- | --- | | Customer portal | Design, general help content | Requests, attachments, membership, notifications, sender identity | | Staff queue | Workload view for authorised staff, the triage process | Which staff may open or change each customer’s records | | Knowledge search | Approved general procedures | Resolved cases, customer-specific incidents, restricted documents | | Delivery teams | Technical detail needed to do the work | Customer identity and unrelated source material | | Reporting | Team capacity and throughput | SLA attainment, reopen rate and ageing, per customer | Access follows a verified account and an approved membership. A brand name typed into a form is context. It’s never proof that the person belongs to that brand. Atlassian’s own guidance on [customer permissions and request sharing](https://support.atlassian.com/jira/kb/manage-access-jira-service-management-projects-requests/) covers restricted versus open portals and what customers can share. Read it, configure it, then test it with synthetic accounts across two brands. Check search, direct links, attachments, notifications and a revoked membership. And a clean queue proves nothing about separation. ## Where the delay sits Before you automate the queue, follow twenty recent requests from submission to close. Record where staff waited, asked again or moved the work. Separate hands-on effort from elapsed time, because they need different fixes. Two requests can show the same first-response time and very different service. One got an automated acknowledgement and sat unowned for six hours. The other reached a specialist in ten minutes and waited two days for the customer to answer a question. So the first is a routing problem, and the second is an intake problem. Define the starting measures before you change anything: - **Time to correct owner.** From submission to acceptance by the team that will do the work. - **Avoidable reassignment.** Requests moved because the first routing decision was wrong, divided by all reviewed requests. - **Clarification rounds.** Exchanges needed before work can start. - **Ageing work.** Open requests grouped by age, priority, customer and the reason they are waiting. - **Review effort.** Staff minutes spent accepting, editing or rejecting suggestions. Keep request categories visible in every one of these. A software defect, an access request and a planned change should not share one handling-time target. And a change in the mix moves the average without changing the service. ## What AI makes routine in a multi-brand service desk The coordination work in a shared desk was always possible to do well. But it was too expensive to do on every ticket, so it was done on the loud ones. Language models change that cost. Four steps that were occasional become routine. | Step | Before | With a model in the loop | Who decides | | --- | --- | --- | --- | | Duplicate and related-case check | Searched by a senior agent when a ticket looked familiar | Every new request is compared with resolved cases in the same customer’s scope, with a named candidate and a reason | A reviewer links, separates or asks | | Classification and priority | Set by the customer, then corrected by staff | A suggested type and priority from the customer’s own request vocabulary and the agreed priority matrix | A reviewer accepts, edits or rejects | | Missing detail | Asked for in the first reply, a day later | Bounded clarifying questions at intake, and a draft the customer can edit before submitting | The customer, before submission | | Summaries and updates | Written by hand when the ticket changed teams | A summary of the history for the next team, and a draft status update for the customer | The agent who sends it | The pattern is the same in each row. The model proposes, with evidence a person can inspect. The person decides. Nothing writes to the customer’s record or changes a status without that decision, and every suggestion records the model, the prompt version and the evidence it used. Triage suggestion flow with a reviewer decision before any change ```mermaid flowchart TD accTitle: Triage suggestion flow with a reviewer decision before any change A[New request arrives] --> B[Deterministic checks] B --> C[Model reads request and evidence] C --> D[Suggestion with reason] D --> E{Reviewer} E -->|Accept| F[Type, priority and links set] E -->|Edit| F E -->|Reject| G[Reason recorded] F --> H[Customer update drafted] G --> H ``` Use fixed rules wherever the rule is already clear. A request from a customer whose contract names a P1 response time gets that priority from the contract, never from a model’s reading of the tone. The model earns its place on the ambiguous middle. ## Duplicates across brands without losing a request Two tickets with similar wording can describe different work. They may belong to different customers, need different permissions or carry separate service commitments. So a duplicate suggestion is a review decision, and the reviewer needs to see the candidate rather than a similarity score. **Two customers, one fix, two updates** Whatever the reviewer chooses, each customer keeps their own request, their own update and their own service clock. Linking the work never merges the customers. | Candidate relationship | Useful action | What to preserve | | --- | --- | --- | | Same issue, same requested outcome, same customer | Link to the existing request or merge | Who tells the customer, and which SLA clock continues | | Similar symptom, different customer | Reuse the diagnosis, keep the requests separate | Each customer’s visibility and update | | One incident affecting several customers | Coordinate one technical fix | A separate request, update and service obligation per customer | | Uncertain match | Ask for clarification or keep the work separate | No premature closure | The retrieval behind the suggestion obeys the same access rules as the portal. It searches resolved cases within the customer’s own scope, and a request from another customer never appears as a candidate, a suggested title or a line in a summary. Staff with broader rights can see more. Even then, the summary that goes to a delivery team carries the minimum: the symptom, the steps tried and the evidence, without the customer’s identity where the work doesn’t need it. And for customer intake the check runs before submission. If a customer’s own open request matches, the portal shows it with a link, and the customer confirms that the new work is different or goes to the existing request. Resolved guidance never blocks a submission. ## SLAs and KPIs per customer A service-level agreement needs a clock. Decide when it starts, what pauses it, when it stops and which working calendar applies. Then write those four answers into the contract and the tool in the same words. First response and resolution are separate commitments. An automated acknowledgement satisfies neither when the contract asks for a meaningful reply from a person. So measure first meaningful response, defined as a reply that answers or asks a specific question. Calendars differ by customer and by region. Jira Service Management’s [SLA calendars](https://support.atlassian.com/jira-service-management-cloud/docs/set-up-sla-calendars/) carry working days, time slots, a time zone and holidays per calendar, and each goal can use a different one. A brand with 24-hour cover and a brand with office hours need different calendars. And their attainment figures can’t be compared without them. **Same hours, different clocks** Both brands waited the same 26 hours. Only the brand with office-hours cover is inside its target, so comparing their attainment without their calendars says nothing. Make waiting states visible instead of using them to hide delay. A pause for customer information records what is needed and who owns the next step. Waiting on an internal team is a different state, and it usually shouldn’t pause the customer’s clock at all. | KPI | Definition | Why it matters in a shared desk | | --- | --- | --- | | SLA attainment per customer | Requests that met their goal / requests with that goal, on the customer’s calendar | One team, several contracts. A blended figure hides the customer you are failing | | Time to first response | Submission to first meaningful reply, on the customer’s calendar | Automated acknowledgements make the raw figure meaningless | | Time to correct owner | Submission to acceptance by the responsible team | Routing quality, which triage automation is meant to improve | | Reopen rate | Requests reopened within 14 days of closure / closed requests | Catches closures that satisfied the queue rather than the customer | | Agent hours per ticket | Hands-on staff time / closed requests, by category | The number the shared desk exists to lower | | Suggestion accuracy | Accepted without edit / all reviewed suggestions, with a sampled check of accepted ones | Acceptance alone measures trust, which can be misplaced | A worked example, with assumptions. A desk closes 600 requests a month across three brands and spends 1.5 agent hours per ticket, so 900 hours. Assume intake and triage automation cut clarification rounds by half and avoidable reassignment by a third, and that those two account for 20 minutes of the 1.5 hours. The desk then saves around 60 hours a month before review time is subtracted. That’s the order of saving to expect from triage alone. The larger gain comes from fewer reopens and better ownership, and it takes a quarter to show. ## The smallest change that closes the gap Three routes exist, and they cost very different amounts to run. 1. **Configure the tool.** Organisations, portal groups, request-type permissions, per-customer SLA goals and calendars. Cheapest, and it keeps one system to operate. Test it with synthetic accounts before deciding it is enough. 2. **Integrate.** When a customer request must create technical work in another project or another instance and carry status back, an integration under a service account does that without exposing the internal workspace. This is also how two licensed desks get bridged. 3. **Build a customer layer.** When customers need their own login, their own domain and notifications from their own brand, and the tool cannot provide it, a portal on top of the desk is the honest answer. Budget for accounts, invitations, recovery, notifications, accessibility and support. The request form is the small part. We took the third route for the group described above. Their brands needed separate customer identities, and their two desks couldn’t be merged for licensing reasons. The staff stayed in Jira Service Management. The customers got a portal that knows which brand they belong to, and an integration creates the linked developer work behind it. The triage suggestions, duplicate checks and drafts described here run in that layer, and every one of them ends in a person’s decision. That is the shape of the work our [process automation service](https://www.aigentcy.com/services/process-automation/) delivers. The same review-before-action pattern runs the [HR reporting and reminders](https://www.aigentcy.com/case-studies/hr-automation/) we built elsewhere. ## Proving it on one service journey Pick one request type, one customer group and a named service owner. Capture the baseline from the measures above, then run a bounded pilot with the ordinary manual route still open. The pilot review has four checks: - **Separation.** Two synthetic customers with different memberships. Search, direct links, attachments, notifications and a revoked membership. Each one either passes or blocks the rollout. - **Real status.** Follow completed requests through the customer view and the delivery team’s system. A status shown to the customer must match the record behind it, and a retry must not create duplicate work. - **Effort.** Total staff time before and after, including review of suggestions and handling of exceptions. But if intake time fell and reassignment rose, fix routing before expanding. - **Customer effect.** Reopen rate and status-chasing contacts for the pilot group against the baseline. Expand when ownership improved, avoidable exchanges fell and no boundary check failed. The number of tickets the assistant touched is activity. The numbers above are the outcome, and they’re what a service manager can take to the customer. ## Frequently asked questions Do we need a separate service desk for every brand? Usually not. One desk can hold separate customer organisations, request types and SLAs, and the staff can work one queue. Licensing can force a split, as it does for regulated brands that hold separate licences. In that case a layer on top of the desks bridges them. Can AI close duplicate tickets automatically? We don't let it. Similar wording is not the same request, and two customers may hold separate service commitments for one underlying incident. AI proposes a candidate with a reason. A person links or separates, and each customer still gets their own update. Why does Jira Service Management struggle with several brands? It handles them, with work. Organisations, portal groups and request-type permissions keep customers apart, and SLA calendars can differ per customer. The gaps are the customer portal, which carries one identity, and notifications, which are configured per project rather than per brand. Which KPIs show whether triage automation is working? Time to correct owner, avoidable reassignments, clarification rounds, SLA attainment per customer, reopen rate and agent hours per ticket. Track accepted, edited and rejected suggestions separately, and review a sample of accepted ones for rushed approvals. Should we replace our ticketing system? Test configuration first, then an integration. A dedicated customer experience is justified when a measured gap in privacy, identity or notifications cannot be closed inside the tool. Budget for accounts, invitations, recovery and support, because the form is the small part. ## Related reading - [Automated resolution rate: measuring support AI by outcomes](https://www.aigentcy.com/blog/support-ai-resolution-metrics/)A bot can answer more conversations while your agents get harder work. Measure verified resolution, safe escalation, repeat contact and the cost per resolved case before you trust the headline rate. - [Native AI assistants for business software: guide first, then act](https://www.aigentcy.com/blog/native-ai-assistants-for-business-software/)An assistant inside the software people already use can show where a setting lives, prepare the change and apply it after confirmation. Measure the work finished, not the messages exchanged. - [Enterprise AI in Slack: one assistant for company knowledge](https://www.aigentcy.com/blog/enterprise-ai-in-slack/)Put one assistant where the questions already arrive, let it search only what each person may read, and measure how fast people reach a verified answer. - [Support triage with replies ready for review](https://www.aigentcy.com/case-studies/customer-support-automation/)Case study - [HR reporting and reminders in BambooHR](https://www.aigentcy.com/case-studies/hr-automation/)Case study [How we automate processes](https://www.aigentcy.com/services/process-automation/) [Talk to us about your project](https://www.aigentcy.com/contact/) --- # Native AI assistants for business software: guide first, then act An assistant inside the software people already use can show where a setting lives, prepare the change and apply it after confirmation. Measure the work finished, not the messages exchanged. Aigentcy 28 July 2026 12 min read Updated 7 September 2026 ## Key takeaways - Build the assistant inside the CMS, ERP or CRM where the work happens. It sees the record on screen and never asks the person to switch tools. - Ship a guide-only assistant first. It answers 'where do I change this' from the application's own navigation and field definitions, so it can't drift from the real screens. - Add actions one at a time, each confirm-first: the assistant proposes, the person sees before and after, the application applies and records who approved it. - The application checks permission at the moment of the change. The model never decides who may do what. - Measure task completion without rework, time to complete and errors caught before save, on the same tasks with and without the assistant. **The assistant works beside the record** It sees the page the person has open, proposes a change with before and after, and the application checks the role and writes only after apply. A content manager knows what she wants to change on the welcome page. She doesn’t know which of the forty CMS screens holds the field. So she asks a colleague, gets a path, clicks through, edits the text and asks whether someone has to approve it. Native AI assistants for business software are built to remove that walk. Multiply it across a company. An [HBR study](https://hbr.org/2022/08/how-much-time-and-energy-do-we-waste-toggling-between-applications) of 137 people at three large companies found they switched between applications about 1,200 times a day and spent just under four hours a week reorienting after each switch, around 9% of their working time. The assistant sits in the CMS, the ERP or the CRM. It sees the record on screen, tells the person where the change lives, and, when you allow it, makes the change after they confirm. This guide covers how to build one in that order and which numbers show it’s working. ## Where a native AI assistant lives A separate chat window knows nothing about the screen in front of the person. They paste in context, get an answer, switch back and apply it by hand. Every one of those steps is a place to make a mistake. An assistant inside the application starts with the current page, the record and the person’s role. It can open the right screen, fill a draft and hand the final decision back. And it runs under the same login and permissions the person already has. | Question | Separate chat window | Assistant inside the application | | --- | --- | --- | | What does it know about the task? | Only what the person pastes in | The current page, record and role | | Who checks permissions? | Nobody, or the model | The application, at the moment of change | | How does a change get applied? | The person retypes it | The application applies it after confirmation | | What is the audit trail? | A chat log | The application’s own change history | | What does it cost to run? | A subscription per seat | Model calls per question, often a few cents | The two aren’t rivals. A company-wide assistant in chat is the front door for questions that span systems, which we cover in [enterprise AI in Slack](https://www.aigentcy.com/blog/enterprise-ai-in-slack/). The native assistant is for work that lives deep inside one system. ## Guide first The first version of the assistant only answers one question, “where do I change this”. Ask for the SEO title on the welcome page and it replies with the path, “Pages, then Welcome page, then SEO settings”, and a link that opens that screen. It changes nothing. That sounds modest. It removes the colleague interruption, the wrong-screen detour and the “is this the right field” doubt, which is where the four hours a week go. And it carries no write risk, so it can ship in weeks. **Authority grows one level at a time** Each level is a separate decision with its own evidence. Most of the value arrives at the first two, before the assistant can write anything. The important design choice is where the assistant’s knowledge comes from. Ground it in the application’s own navigation model and field definitions, the same data that draws the menus and labels. When a screen is renamed, the assistant’s answer changes with it. A hand-written help guide would drift within a month. That grounding also keeps the assistant cheap. A small, fast model answers a “where is” question well in about a second, because the answer is a lookup with some phrasing around it. So the running cost is a rounding error next to the people time it saves. Two more rules for the guide phase: - **Say so when it can’t find it.** If a setting isn’t in the map or the person’s role can’t see it, the assistant says that and leaves the normal interface in place. - **Degrade to documentation.** If the model is unavailable, the panel links to the generated guide instead of failing. The application never depends on the assistant to work. ## Then act, with confirmation Once people trust the guide, they’ll ask it to make the change. Add that ability one action type at a time, and make every action confirm-first. The sequence is the same for a text edit, a banner image or a list of payment providers: 1. The person describes the change in plain words. 2. The assistant proposes it at a high level: which page, which setting, which record, the new value. It never invents internal identifiers. 3. The application resolves that proposal into a concrete change server-side, reads the current value and checks the person’s role against the section. 4. The panel shows a confirmation card: before and after, with a word-level diff for rich text and the actual asset for an image. 5. The person clicks apply or cancels. Only on apply does the application write, through the same path the editor uses, and record the change against that person in the audit trail. A confirm-first action inside a business application ```mermaid flowchart TD accTitle: A confirm-first action inside a business application A[Person describes the change] --> B[Assistant proposes target and value] B --> C[Application resolves the record] C --> D{Role allows this section?} D -->|No| E[Explain and give the path] D -->|Yes| F[Show before and after] F --> G{Person confirms?} G -->|No| H[Nothing changes] G -->|Yes| I[Application writes and audits] ``` **What the person approves** The card names the exact record and shows the difference, so approval means something. The application resolves the record, checks the role and writes the audit entry. Step 4 is where the value shows. A person can only approve what they can see, so the card names the exact record, the language, the current value and the proposed value. For a long paragraph it highlights the changed words. For a list it shows additions and removals. And if the record changed while they were reading, the card asks for a fresh look before anything is overwritten. Keep separate approvals separate. Confirming a text edit must never publish the page, send a notification or touch another language. Name every extra consequence before asking for the click, or make it a separate action. | Level of authority | What the assistant may do | Control the business needs | | --- | --- | --- | | Guide | Explain the application and open the right screen | Answers grounded in the application’s own structure | | Propose | Prepare a change without saving it | Exact target and a reviewable before-and-after view | | Apply | Save a confirmed, supported change | Permission check, confirmation and an audit record | | Consequential | Publish, send, delete or change access | A separate approval flow and stronger safeguards | Avoid a single “AI enabled” switch. One team wants draft text help and no automated publishing. Another wants record lookup and no changes at all. Each level is its own decision with its own evidence. ## Permissions checked by the application The assistant works within the signed-in person’s authority. Someone who can’t edit a section through the normal screens must not gain that ability by asking in natural language. Enforce that rule in the application, at the moment the action is requested. Telling the model to respect roles is useful guidance. But it’s never the final check, because a model can be talked out of it, and because the write path may have no role check of its own. In one CMS we worked in, the internal write path trusted every caller. So the role check had to sit in the assistant’s server layer, in front of that path, before anything was written. OWASP’s list of risks for language model applications names excessive agency as one of them: too much functionality, too many permissions, or too much autonomy for the intended task ([OWASP LLM06:2025](https://genai.owasp.org/llmrisk/llm062025-excessive-agency/)). Its recommended controls are to limit the tools, run them with the minimum permissions and require a person to approve high-impact actions. That is the confirm-first design above. | Control | Where it lives | Who enforces it | | --- | --- | --- | | “Only edit what this role may edit” | The application, when a proposal is resolved | The application’s permission model | | “Show before and after” | The assistant panel | The person, by confirming | | “Never publish from a text edit” | The action definition | The application, by not exposing that path | | “Ignore instructions inside content” | The assistant’s prompt and input limits | The model, with tests that prove it | | “Record who approved what” | The application’s audit trail | The application, on every write | The same rule applies to reading. Search results, previews and summaries can expose a record whose page is protected. Include them in permission testing. Treat content as information to inspect, never as instructions. A page body or a record note must not be able to grant itself permission to send a message or expose another person’s data. Cap the input, strip anything that looks like a command, and test it with an adversarial set before launch. ## Exposing actions through MCP The [Model Context Protocol](https://modelcontextprotocol.io/), MCP for short, is an open standard for how an application exposes context and actions to an AI assistant. A server offers three kinds of things: resources (data to read), prompts (templates for common tasks) and tools (functions the model may call). Any assistant that speaks the protocol can use them. For a business buyer the useful question is which of those the workflow needs. A read-only server that answers “where does this setting live” needs no tools that write. So ship that first. It serves the in-app panel and any other assistant the company runs, including one in chat, from the same map of the application. Writing tools are a separate product decision. When you add one, shape it the way the confirmation flow expects: - **High-level inputs.** The tool takes a page, a setting and a value in the person’s words. The application resolves identifiers. The model never sees a database id. - **A proposal step and an apply step.** Two calls, so the confirmation card sits between them and nothing writes on the first call. - **The caller’s identity.** The tool runs as the signed-in person, and the application checks their role on every call. - **Untrusted descriptions.** The specification says a tool’s own description of itself should be treated as untrusted unless it comes from a trusted server, and that hosts must obtain explicit user consent before invoking any tool. MCP doesn’t decide whether a change is commercially sensible or who may approve it. Those stay with the product and the [process around it](https://www.aigentcy.com/services/process-automation/). What MCP gives you is one way to expose the application’s actions that every assistant can use, so you don’t build the integration twice. ## Measuring what a native assistant completes Count tasks finished, never messages exchanged. A long conversation may mean useful help or repeated confusion. An opened panel says someone tried the feature, and nothing else. Compare the same tasks with and without the assistant, across people with different levels of experience in the application. Record the outcome, the time and the corrections, and ask afterwards whether it helped. | KPI | Definition for a pilot | Why it matters | | --- | --- | --- | | Task completion without rework | Eligible tasks finished correctly at the first attempt, divided by attempted tasks | Separates activity from useful work | | Time to complete | Minutes from intent to a verified result, including the review | Counts the effort after the draft | | Errors caught before save | Proposals corrected or cancelled at the confirmation card, divided by proposals shown | Shows the card doing its job | | Errors found after save | Applied changes corrected later, divided by applied changes reviewed | Finds defects that passed the card | | Adoption within the workflow | Eligible tasks attempted with the assistant, divided by all eligible tasks | Shows use where it was meant to be used | | Cost per completed task | Model, hosting and support cost, divided by tasks completed without rework | Tests the whole economics | State the review sample and the follow-up window, so recent changes don’t look error-free only because nobody has checked them yet. Include abandoned attempts in the time measure, or the feature will look faster than it is. Here is a planning sketch with labelled assumptions. It describes no customer. | Line | Assumption | Result | | --- | --- | --- | | Assisted tasks per month | 600 | 600 | | Time saved per task before review | Two minutes of navigation and retyping avoided | 20 hours | | Review and corrections | Eight hours a month across the team | 12 hours net | | Model spend | 1 to 3 cents per interaction, three interactions per task | $18 to $54 | | Errors caught before save | 5% of proposals corrected at the card | 30 mistakes that never reached the site | Twelve hours of released capacity and thirty caught mistakes is the honest shape of the result. It turns into money when overtime falls, a backlog clears or a correction cycle disappears. ## Failure and recovery People need to know whether an action failed, succeeded or is uncertain. A network error after “apply” must not tempt them into submitting the same change three times. - **Show the recorded result.** After a write, display what the application stored, with a link to the record, so “done” is verifiable. - **Never replay from history.** A restored conversation is plain text. Old proposals don’t run again when the panel reopens. - **Keep the editor working.** If the model or the gateway is down, guidance falls back to the generated documentation and the normal editor stays usable. - **Know what can be undone.** Text edits can be reverted from the audit trail. Publishing and sending need their own corrective step, so gate them harder. Colleagues stop using a feature they have to double-check. Reliable confirmation and a working fallback are part of the value, and they belong in the pilot’s acceptance criteria. ## Configure, buy or build Test the vendor’s own assistant first, against your actual task, permission boundary and review process. A native feature may already do the job with configuration and a short training session. | Situation | Sensible choice | | --- | --- | | The task lives in one screen and the vendor assistant handles it | Configure the vendor feature | | The task crosses two applications | Build an assistant with an MCP server per application | | Your business rules decide what may change | Build, and put the rules in the resolve step | | The vendor assistant writes without a before-and-after view | Build, or keep it guide-only until it does | | Records, roles and screens change often | Build on the application’s own structure so the map regenerates | We took the build route for a services firm whose enquiries arrive through several channels. The workflow captures each enquiry in [Odoo, adds company context and prepares a follow-up](https://www.aigentcy.com/case-studies/odoo-lead-generation-automation/), and a consultant makes the qualification call. The same shape applies to purchase orders, where the buyer approves and the workflow never pays an invoice on its own. Run the first pilot on one bounded workflow with a named business owner. Keep consequential actions off until their separate checks pass. Then expand where the completion numbers say to. The result to aim for is a colleague who finishes the task with less searching and fewer interruptions, and who can see what changed and who approved it. A chat panel on its own is a feature. That is a working process. ## Frequently asked questions What is a native AI assistant? It's an assistant built into the business application where the work happens, such as a CMS, an ERP or a CRM. It can use the record the person is looking at and, when enabled, offer approved actions. Its value comes from finishing real tasks, wherever the chat panel sits. Does an in-app assistant need permission to change records? No. Guidance and read-only lookup are useful on their own and carry no write risk. Add write actions one at a time when the case is clear, with a permission check in the application, a before-and-after preview and confirmation for anything consequential. Does the Model Context Protocol make an assistant secure? No. MCP standardises how an application exposes context and actions to an assistant. Your application still needs authentication, permission checks, limits, confirmation rules and an audit trail. The specification itself says hosts must get explicit user consent before invoking any tool. How should we measure the return? Compare task completion, time to complete and corrections on the same tasks with and without the assistant. Include operating and support costs. Time released is capacity. It becomes a saving only when a cost line changes. Should we configure the vendor's assistant or build our own? Test the vendor's feature against your real task, permission boundary and review process first. Build when the task crosses applications, depends on your own business rules or needs a confirmation experience the vendor feature can't give you. ## Related reading - [Enterprise AI in Slack: one assistant for company knowledge](https://www.aigentcy.com/blog/enterprise-ai-in-slack/)Put one assistant where the questions already arrive, let it search only what each person may read, and measure how fast people reach a verified answer. - [Multi-brand service desk automation: one desk for several customers](https://www.aigentcy.com/blog/multi-brand-service-desk-automation/)Service desk tools assume one company. When one team serves several brands, the gaps show up as leaked context, missed SLAs and duplicate work. Here is how to close them, and what AI makes routine. - [An AI governance framework your team can operate](https://www.aigentcy.com/blog/enterprise-ai-governance-framework-guide/)A decision guide for the people who sign off AI systems: how much governance each one needs, who does what in the first 90 days, what it costs to run, and the evidence that proves the rules were followed. - [Lead qualification and follow-up in Odoo](https://www.aigentcy.com/case-studies/odoo-lead-generation-automation/)Case study - [Purchase orders and invoice checks](https://www.aigentcy.com/case-studies/wholesale-procurement-automation/)Case study [How we automate processes](https://www.aigentcy.com/services/process-automation/) [Talk to us about your project](https://www.aigentcy.com/contact/) --- # Automated resolution rate: measuring support AI by outcomes A bot can answer more conversations while your agents get harder work. Measure verified resolution, safe escalation, repeat contact and the cost per resolved case before you trust the headline rate. Aigentcy 16 June 2026 13 min read Updated 7 September 2026 ## Key takeaways - Write the numerator, the denominator and the reporting window next to every automated resolution rate before you compare two numbers. - A vendor's blended rate can sit at twice the verified rate you are billed for. Report both, and label which one is which. - Grade a sample of conversations with a second model and a human reviewer, and store the evidence behind each verdict. - Test an escalation by what the receiving agent gets: the right queue, a usable summary and no repeated questions. - Cost per resolved case includes platform fees, grading, review time and rework. The model bill is the smallest line. **Two rates from the same month** The blended rate counts contained conversations, where the customer stopped asking, together with verified ones. The invoice counts verified only, so the dashboard can show double the billed rate. Your support AI dashboard says the automated resolution rate went up again. Your agents say the queue got harder. Both can be true. And the gap between them is what this guide is about. An automated resolution rate is a fraction. The number on the dashboard depends on what the vendor puts in the numerator, what it leaves out of the denominator and when it counts the conversation as finished. Change any of those and the rate moves without the service changing. So before you fund the next phase of automation, define the number you’re paying for. Then add the four measures that show whether the work went away or moved: verified resolution, safe escalation, repeat contact and cost per resolved case. ## What an automated resolution rate counts Every AI support platform reports a headline rate. The definitions differ, and the differences are large enough to change a business case. Zendesk groups outcomes into [automated resolution tiers](https://support.zendesk.com/hc/en-us/articles/9570369117338-About-automated-resolution-tiers). An assisted escalation means the bot collected details and a person finished the job. A contained resolution means the customer stopped asking. A verified resolution means a language model read the ended conversation and judged that the request was resolved. And only the verified tier draws on the paid allowance. Intercom counts a [Fin resolution](https://www.intercom.com/help/en/articles/8205718-fin-ai-agent-outcomes) when the customer confirms the answer helped, or leaves without asking for more help. It calls the second case an assumed resolution. But both are billed at the same price. | Outcome the platform reports | What happened | What it proves about the customer’s problem | | --- | --- | --- | | Bot replied | The bot sent an answer | Nothing yet | | Contained (assumed) | The customer did not ask for a person and the conversation timed out | The customer stopped talking. They may have solved it, or given up | | Verified | A model read the transcript and judged the request resolved | The transcript reads as resolved. Nothing outside the chat was checked | | Confirmed | The customer said the answer helped | Strong signal, and rare, because few customers reply to say thanks | | Assisted escalation | The bot gathered details, then a person resolved it | Agent time was saved. The resolution belongs to the agent | Note the timing. Zendesk ends an email conversation 72 hours after the last message, and a messaging conversation two hours after it by default. A resolution can’t be verified until the conversation has ended, so the newest days on any dashboard undercount until they settle. **Two rates from the same month** The blended rate counts contained conversations, where the customer stopped asking, together with verified ones. The invoice counts verified only, so the dashboard can show double the billed rate. ## Why the dashboard and the invoice disagree A support team we worked with pays per verified resolution. Their vendor’s admin dashboard showed a headline rate near 50 percent. The billed verified rate for the same weeks was near 25 percent. But nobody had made an error. The two numbers counted different things. Three causes explained the whole gap: - **Numerator.** The headline blended contained and verified conversations. Billing counted verified only. That alone roughly doubled the displayed rate. - **Date basis.** The vendor’s export grouped conversations by end time. The dashboard grouped them by start time. Conversations that ran overnight moved between days. - **Time zone.** The export used UTC. The account was set to a European time zone. Around 60 conversations changed day on a single date from that alone. The verified rate was stable under every grouping we tried. So that became the defensible number for the finance team. The blended rate was useful for the service team, as a ceiling on what verification could reach. Report both numbers, label each with its definition, and don’t let one stand in for the other in a board pack. ## Choosing the denominator for an automated resolution rate The numerator gets the attention. The denominator decides whether the rate describes the whole service or a flattering slice of it. | Denominator | What it includes | Who tends to use it | What it hides | | --- | --- | --- | --- | | All inbound contacts | Every conversation and ticket in the period, whether the bot saw it or not | Finance, the COO | Nothing. It needs a count the bot platform doesn’t hold | | AI-handled conversations | Conversations the bot took part in | Vendors, by default | Contacts that went straight to email or phone | | In-scope conversations | AI-handled minus request types the bot is not allowed to handle | The service team, for tuning | Whether scope is growing or shrinking | A worked example shows the effect. Assume 10,000 contacts in a month, of which 6,000 reach the bot and 1,500 end as verified resolutions. - Verified rate of AI-handled conversations: 1,500 / 6,000 = 25 percent. - Verified rate of all contacts: 1,500 / 10,000 = 15 percent. - Involvement rate: 6,000 / 10,000 = 60 percent. All three are correct. The first is a quality number. The second is the business number, because it tells you what share of the whole workload went away. The third tells you where to look for growth. And a strong first number on a small second number is the usual shape of an early deployment. Reviewed transcripts add a fourth base. If 800 of 1,000 eligible conversations had transcripts available and reviewers verified 400, the verified share is 40 percent of eligible conversations and 50 percent of reviewed ones. So show the 200 unavailable transcripts as unknown. An export gap isn’t a quiet day. ## Verifying a resolution A verified resolution is a claim about the customer’s problem. The vendor’s own check reads the transcript with a model. That is a reasonable first check, and it’s also the check that decides your invoice. So we add an independent one. The method we use grades a sample of billed resolutions with a second model, against a rubric the service owner approved. Every verdict stores the transcript, the rubric version, the model and the reason. Humans review the disagreements and every sensitive case. Grading a billed resolution with rules, a second model and a reviewer ```mermaid flowchart TD accTitle: Grading a billed resolution with rules, a second model and a reviewer A[Billed resolution] --> B{Deterministic checks} B -->|Escalated, reopened or rated negative| C[Not resolved] B -->|No hard signal| D[Second model grades transcript] D -->|Confident and not sensitive| E[Verdict with evidence] D -->|Doubt or sensitive topic| F[Human reviewer] F --> E E --> G[Disputed resolution list] G --> H[Weekly service review] ``` Three details make this work in practice: 1. **Deterministic checks go first.** A conversation that was escalated, reopened or rated negative isn’t resolved. No model is needed to say so, and the result is reproducible. 2. **The grader knows the policy.** If phase one says the bot must escalate every account change, an escalation is correct behaviour. Without the policy in front of it, a grader marks designed behaviour as failure. 3. **Humans set the bar.** A small gold set of human-graded conversations shows how often the model grader agrees with people. Publish that agreement figure next to the grade. The output is a disputed-resolution rate: billed resolutions that a second reading didn’t support. Expect single digits once the bot is tuned. And a rising figure is a knowledge or policy problem. It’s also money you should discuss with the vendor. ## Testing the handoff from the receiving side In a first phase the bot escalates anything that touches an account. So most of the value comes from the handoff, and most of the hidden cost hides there too. A bot that says “I have passed this to the team” has made a promise, and the customer treats it as one. **The promise and the evidence** The bot's message is what the customer heard. The four checks and the repeat counter are what the test scores, because they decide how long the case takes from here. We test the handoff from the receiving side: 1. Confirm the case met an agreed escalation rule, such as a missing identity check or an exception outside policy. 2. Check the bot made no promise it couldn’t keep, and disclosed nothing it shouldn’t. 3. Find the routing event and confirm the case reached the right queue with an owner. 4. Read the summary the agent received. It should hold the problem, the steps tried and what is still missing. 5. Follow the case to its end and count the questions the customer had to answer twice. Measure agent handling time on escalated cases separately from ordinary cases. A bot that collects details well cuts that time. But a bot that sends a thin summary raises it. An average across both hides which one you have. Include the closed-queue case in the test. When the receiving team is offline, the bot should state the approved next step without inventing a response time. ## Repeat contact and what it proves A customer who comes back within a week is a signal, and only a signal. They may have a new question, or the same question on a different channel, or a real unresolved problem. To turn the signal into a measure, define four things: - **The window.** Seven days is common. A window that hasn’t closed yet gives an immature result, so report it as such. - **Identity coverage.** If only authenticated customers can be linked, say what share of contacts that is. - **Issue matching.** A same-issue repeat needs the subject and outcome to match, with human review on the ambiguous ones. - **The two measures.** Keep broad repeat contact and confirmed same-issue recurrence as separate lines. They answer different questions. Then read the repeats by theme before touching a prompt. Repeated withdrawal questions at a group running several consumer brands turned out to be a hold-period policy the customers couldn’t find. So that was a content change, and it took a morning. ## Automations that pay before the bot resolves anything Full resolution is the last step to earn. The earlier steps are native to the support tools you already run, and each one has a measure of its own. We built exactly this for [a support team whose agents were sorting tickets before they could answer them](https://www.aigentcy.com/case-studies/customer-support-automation/). | Automation | What it does | What to measure | Typical risk | | --- | --- | --- | --- | | Triage and routing | Reads the ticket and sends it to the right queue with a priority | Time to correct owner, avoidable reassignments | Wrong queue on an urgent case | | Tagging | Applies consistent categories for reporting | Share of tickets with a usable category, reporting effort | Tag drift that breaks trend lines | | Data collection | Asks for the order number, account email or screenshots before an agent looks | Questions the agent no longer asks, handling time on escalated cases | Collecting data nobody uses | | Draft replies for review | Prepares an answer from approved help content, and an agent sends it | Edit rate, time per reply, wrong-answer rate on sampled drafts | An agent approving drafts without reading them | | Summaries | Condenses a long thread for the next person | Time to first useful action after handoff | A summary that drops the missing information | The draft-reply pattern deserves a note. An agent decides what reaches the customer, so the quality bar is lower than for unaided resolution and the savings arrive earlier. The measure is the edit rate on a sample. And if agents rewrite half the drafts, the help content needs work before the bot does. ## Observability across the support stack The measures above come from four systems, and each one keeps a different clock. Verification settles days after the conversation. The ticketing system records escalations and reopens in its own time zone. Agent handling time lives in a workforce tool. Customer identity lives in your own systems, if anywhere. To report one honest number a week, we found these habits necessary: - **Pull the vendor export daily and keep every version.** The files are immutable per day, and the latest days change as verification settles. - **Store every graded verdict with its inputs.** The transcript, the rubric version, the model and the reviewer. A rerun should give the same result. - **Use one time zone and one date basis everywhere.** Pick the conversation end time, in the account’s time zone, and state it on the dashboard. - **Show missing data as missing.** An export that failed is a gap on the chart. It’s never a zero. - **Keep the billed number visible.** The usage figure in the vendor’s admin area is the invoice. Reconcile your operational number against it each cycle. Sensitive categories sit in a separate lane. For a regulated consumer business, a conversation about self-exclusion or a vulnerable customer is a compliance event. Count those incidents as an absolute number with a target of zero. Never average them into a quality score, and make them ineligible for a verified resolution by policy. Our [AI governance service](https://www.aigentcy.com/services/ai-governance/) sets these boundaries before a bot goes live. ## Cost per resolved case The model bill is the line people ask about, and it’s the smallest one. A cost per resolved case includes everything the service spends to produce a resolution it can stand behind. The example below uses assumptions, labelled as such. It is not a customer result. | Line | Monthly assumption | Note | | --- | --- | --- | | Verified resolutions | 1,500 | 25 percent of 6,000 AI-handled conversations | | Platform fee | 1,500 EUR | A per-resolution price near 1 EUR, in line with Intercom’s published outcome price | | Model, hosting and monitoring | 800 EUR | Grading models, dashboards, exports | | Grading and review time | 700 EUR | 20 hours of reviewer time at 35 EUR | | Rework | 900 EUR | 10 percent of verified cases return within 7 days and cost 6 EUR each to handle | | Total | 3,900 EUR | | | Net resolved cases | 1,350 | Verified minus the cases that came back | | Cost per resolved case | 2.89 EUR | 3,900 / 1,350 | Set that against the fully loaded cost of an agent-handled contact for the same request types. We treat it as an assumption of 6 EUR here, and you should replace it with your own figure. The saving is real at that spread. But it disappears if rework climbs to 30 percent, or if the review time to keep the bot honest doubles. **The lines that go missing** Grading, review and rework are the cost of a resolution you can defend. Leave them out and the model bill alone makes any bot look cheap. Two rules keep the comparison honest. Use the same request population and the same period for the before and after. And count capacity as a saving only when a real cost changes: fewer contractor hours, less overtime, a hiring plan that moved. Released capacity that absorbs growth is valuable, and it’s a different line in the business case. ## The weekly review that assigns work The review we run turns each measure into an owner and a task, so a bad week produces a change rather than a chart. | Measure | Definition | Owner of a bad week | | --- | --- | --- | | Verified resolution | Verified resolutions / AI-handled conversations in a settled period | Service owner | | Disputed resolution | Billed resolutions a second grade rejected / billed resolutions | Knowledge owner, then the vendor | | Safe escalation | Handoffs that reached the right queue with a usable summary / sampled handoffs | Integration owner | | Same-issue repeat | Confirmed same-issue returns within 7 days / identity-linked resolutions | Content owner or product owner | | Compliance incidents | Sensitive conversations mishandled, as a count | Compliance owner, target zero | | Cost per resolved case | Total service cost / net resolved cases | Finance, with the service owner | Expand one request type at a time. Agree a baseline, a settled review period and the conditions that pause automation, such as a compliance incident or a broken handoff. Then decide per request type: expand, repair or hold. A mixed result supports a narrow rollout. It doesn’t support a service-wide one, and a rising headline rate doesn’t change that. For the support teams we’ve worked with, the sequence has been the same. Triage and drafting first, because they pay early and carry little risk. Then guided resolution with escalation on every action. Then, once verified resolution and repeat contact hold steady for a quarter, automated actions on the narrow request types that earned it. Our [process automation service](https://www.aigentcy.com/services/process-automation/) runs that sequence, with the measures in this guide in place from the first week. ## Frequently asked questions What is a good automated resolution rate? It depends on what the rate counts. A verified rate of 25 to 40 percent of AI-handled conversations is common for a first phase that escalates every account action. A blended rate that includes unverified conversations can show twice that on the same traffic. Compare like with like, and track the trend for one request type at a time. Is containment rate the same as resolution rate? No. Containment means the customer did not ask for a person and the conversation ended. Resolution means the problem was solved. A customer who gave up is contained. A verified resolution needs a check on the transcript, or a confirmed change in another system. Can AI grade its own support conversations? A separate model can grade transcripts against a written rubric, and it scales to every conversation. It still needs calibration against human reviewers, an option to say the evidence is insufficient, and a human on sensitive cases. We treat the model grade as a first pass, never as the only check. Does a returning customer prove the first answer failed? Not on its own. The customer may have a new question or may use another channel. A same-issue repeat needs identity matching, an issue match and a complete follow-up window. Broad repeat contact is still useful as a signal for investigation. How do we work out the cost per resolved case? Add the platform fees, model and monitoring costs, grading and review time and the cost of rework for the period. Divide by the verified resolutions in the same scope. Compare that with the fully loaded cost of an agent-handled contact for the same request types. ## Related reading - [Multi-brand service desk automation: one desk for several customers](https://www.aigentcy.com/blog/multi-brand-service-desk-automation/)Service desk tools assume one company. When one team serves several brands, the gaps show up as leaked context, missed SLAs and duplicate work. Here is how to close them, and what AI makes routine. - [AI cost management: what an accepted result costs](https://www.aigentcy.com/blog/enterprise-ai-cost-control/)How to report AI spend the way finance reports everything else: by team, by workflow and by accepted result, with unknown charges kept separate from zero. - [An AI governance framework your team can operate](https://www.aigentcy.com/blog/enterprise-ai-governance-framework-guide/)A decision guide for the people who sign off AI systems: how much governance each one needs, who does what in the first 90 days, what it costs to run, and the evidence that proves the rules were followed. - [Support triage with replies ready for review](https://www.aigentcy.com/case-studies/customer-support-automation/)Case study [How we automate processes](https://www.aigentcy.com/services/process-automation/) [Talk to us about your project](https://www.aigentcy.com/contact/) --- # Technical SEO and AI search optimization: turn visibility into qualified demand Fix the crawl and index faults first, write pages that people and AI assistants can read, cover the searches your main site was never built for, and judge the work by qualified enquiries. Aigentcy 31 August 2026 13 min read Updated 7 September 2026 ## Key takeaways - Write down what a qualified enquiry is before you spend on search. Everything else is measured against that definition. - Six crawl and index faults cause most lost visibility: bad canonicals, stale sitemaps, wrong robots rules, blocked assets, structured data that lies, and slow pages. - Google says its AI features need nothing beyond an indexed, snippet-eligible page. Clear headings, an answer near the top and honest structured data do the rest. - Your main site wins your brand and main services. A focused site per specific search topic covers the demand it was never built for. - Report impressions, qualified enquiries and assisted conversions as three separate numbers. A citation in an AI answer is not a lead. **From a search to a qualified enquiry** The count shrinks at each step, so each step needs its own number and its own owner. The figures are the article's worked example, not a result. Your search report says impressions are up. Your sales team says the enquiries look the same as last quarter. Somewhere between those two numbers, the buyers you wanted went elsewhere. Part of that gap is new. When Google shows an AI summary, people click a normal result on 8% of visits, against 15% without one, according to [Pew Research](https://www.pewresearch.org/short-reads/2025/07/22/google-users-are-less-likely-to-click-on-links-when-an-ai-summary-appears-in-the-results/). [Ahrefs](https://ahrefs.com/blog/ai-overviews-reduce-clicks/) measured a 34.5% lower click rate for the top result when an AI Overview appears. So a page can rank, get read by a machine, and send you nothing. The rest of the gap is old. Pages a crawler can’t reach, duplicate addresses that split credit, slow pages on phones, and copy that never answers the buyer’s question. This guide covers both halves of technical SEO and AI search optimization in the order to fix them, and ends with how to judge the work in enquiries rather than charts. ## What qualified demand means Define the enquiry you want before touching the website. Agree it with whoever handles the leads, and write it down. Every later decision is measured against that sentence. A workable definition has three parts: - **A need you serve.** The person wants something on your service list, in a form you deliver. - **A place you serve.** The right country, language or region. - **A plausible fit.** A company size, budget or timing your team would take on. Everything outside that is either research traffic, which is useful and counted separately, or noise. Keep the two apart in every report. Mixed together, the noise hides the signal. | Demand type | Example search | What to measure | How to report it | | --- | --- | --- | --- | | Branded | “your company name reviews” | Share of brand searches that land on your pages | Protect it. Don’t count it as growth | | Service intent | “payroll outsourcing cost” | Qualified enquiries per hundred visits | The number the programme is judged on | | Research | “what is a service level agreement” | Return visits and next-page clicks | A capacity measure. Never a lead count | | Wrong fit | Outside your region or offer | Count and cause | Filter it, then check the page that attracted it | ## The crawl and index faults that break most often Google has to find a page, fetch it, render it and decide to keep it before anyone can search for it. Each step has a common way to fail. And most of those failures are invisible from a browser, which is why they last for months. | Fault | What it costs you | How to check | The fix | | --- | --- | --- | --- | | Canonical URLs. Several addresses for one page: with and without www, trailing slash, tracking parameters | Links and signals split across copies. Google picks one address, sometimes the wrong one | Search Console URL inspection shows the Google-selected canonical | One address per page, redirect the rest, rel="canonical" on the page. Google ranks redirects strongest, then the canonical tag, then sitemap inclusion | | Sitemaps. Missing, stale, or listing redirects, errors and pages marked noindex | New pages take weeks to appear. Crawl effort goes to dead addresses | Open the sitemap. Every listed page should return 200 and be indexable | Generate it from the build with a real last-modified date, then submit it in Search Console | | Robots rules. A staging Disallow: / copied to production, or bot protection at the CDN blocking Googlebot | Pages vanish or show with no description | Fetch /robots.txt. Test a key page in URL inspection | Allow crawling. Use noindex for pages you want kept out, because robots.txt is not a way to hide a page | | Blocked assets. CSS or JavaScript files disallowed, or content that only appears after a script runs | The rendered page is empty to the crawler. Google won’t render JavaScript from blocked files | Turn JavaScript off and read the page | Serve the main content in the HTML. Allow the assets | | Structured data. Markup that disagrees with the visible text, or fails validation | No rich results, and a trust problem if it claims things the page doesn’t say | Google’s Rich Results test | Keep to types you can keep true (Organization, Article, FAQ) and match the visible text | | Page speed. Slow largest paint, slow response to taps, layout that jumps | Buyers leave, and Core Web Vitals feed ranking | Search Console’s Core Web Vitals report and Lighthouse | Right-sized images, fewer third-party scripts, stable layout | The speed thresholds are public. Google’s [Core Web Vitals](https://web.dev/articles/vitals) call a page good when the largest content paints within 2.5 seconds, input gets a response within 200 milliseconds and the layout shift score is 0.1 or lower. For scale, the [2024 Web Almanac](https://almanac.httparchive.org/en/2024/performance) found 43% of sites passed all three on mobile. So a fast site is still a minority position. ### A technical SEO checklist you can hand to your web team Ask for a yes or a fix on each line. None of them needs an SEO specialist to check. 1. Every page has one address, and the other variants redirect to it. 2. The sitemap lists only live, indexable pages and carries real modified dates. 3. `robots.txt` on production allows crawling of the pages that sell. 4. A key service page reads correctly with JavaScript turned off. 5. Structured data validates and says nothing the page doesn’t say. 6. The largest paint on the service pages is under 2.5 seconds on a phone. 7. The whole site is served over HTTPS with no mixed content. 8. The contact form on a phone works, and the submission reaches the team that answers it. 9. Search Console is verified and someone reads the coverage report monthly. 10. A test enquiry sent today shows up in the CRM with the page it came from. Rank the fixes by the journey each fault interrupts. Fix a blocked service page that buyers land on before a missing alt text on a page nobody visits. Group related faults, name an owner and verify the repair on a phone as well as a desktop. ## How AI assistants and AI search read a page Google’s position is short. Its [guidance on AI features](https://developers.google.com/search/docs/appearance/ai-features) says there are no additional requirements to appear in AI Overviews or AI Mode. A page must be indexed and eligible to show with a snippet. The same document says you don’t need new machine-readable files or special schema for these features. So the checklist above is the entry ticket. But the features read differently from a classic result. Google describes a “query fan-out”: the system issues several related searches on sub-topics and assembles an answer from the passages it finds. A page wins a citation when one of its passages answers one of those sub-questions cleanly. How a page reaches an AI answer ```mermaid flowchart TD accTitle: How a page reaches an AI answer A[Page published] --> B{Crawl allowed?} B -->|No| X[Invisible to search] B -->|Yes| C[Rendered and indexed] C --> D{Snippet eligible?} D -->|No| X D -->|Yes| E[Query fan-out] E --> F{Passage answers a sub-question?} F -->|Yes| G[Cited with a link] F -->|No| H[Ranked but not cited] ``` That changes how a page should be written. The principles below are public guidance, and they help human readers for the same reasons. - **Headings that state the question.** “How much does a POS system cost” beats “Pricing considerations”. A crawler and a buyer both scan headings first. - **The answer near the top.** The first paragraph under a heading gives the answer. Detail, caveats and evidence follow it. - **FAQ blocks with real answers.** Two or three sentences per answer, in the words a buyer would use. A question with a one-line brush-off earns nothing. - **Structured data that matches the page.** Article, FAQ and Organization types, saying exactly what the visible text says. - **Key content as text.** Prices, service scope and locations in HTML, never only in an image or a PDF. - **Pages that read without JavaScript.** Not every assistant runs a browser. Google does. Others fetch the HTML and read what’s there, so server-rendered pages travel further. - **Deliberate preview controls.** `nosnippet`, `max-snippet` and `noindex` limit what Google shows. `Google-Extended` limits training and grounding in Google’s other products and, by Google’s account, has no effect on Search. Decide, rather than inherit a default. **What each reader takes from a page** An AI answer is assembled from passages, so the passage that answers the question has to be findable under the heading that names it. The same layout is what a buyer scans on a phone. Other assistants publish their own crawler rules and they change often. Check each one’s current documentation before you pay for “generative engine optimization” as a separate service. Ask the seller which of the principles above the work would change, and what evidence would show it helped. | Reader | What it needs from the page | What breaks it | | --- | --- | --- | | Google’s crawler | Crawl allowed, HTML content, one canonical address | Robots blocks, blocked assets, duplicate URLs | | Google AI Overviews and AI Mode | An indexed, snippet-eligible page with a clear passage per question | Long build-ups, answers buried in the middle, nosnippet set by accident | | Other AI assistants | Server-rendered text a simple fetch can read | Content that appears only after scripts run | | A buyer on a phone | A fast page, a readable answer, a form that works | Slow paint, tiny tap targets, a form that fails silently | ## Focused sites and branded keyword coverage Your website already wins the searches it was built for: your brand and your main services. Buyers also search for something specific, such as “POS system for restaurants” or “payroll outsourcing costs”. Google answers each of those with a page about exactly that thing. And the winning page often sits on a site about that one topic. A focused site, often called a micro site, is one domain about one service or search topic. It carries a handful of pages that answer the buyer’s questions on that topic, its own enquiry form, and your brand. Your main site stays what it is. The focused site covers demand the main site was never built to chase. Branded keyword coverage is the other half. People search your brand plus a word: “\[brand\] pricing”, “\[brand\] reviews”, “\[brand\] alternatives”. If you have no page for those searches, a review site or a competitor answers them for you. Cover them with pages you control, so the first thing a buyer reads about your pricing comes from you. **Your website plus focused sites, one enquiry inbox** The main site keeps the brand and main-service searches and lends its colours, logo and tone to the focused sites. Every enquiry from any of them arrives with the page and search that earned it. ### When a focused site is the wrong tool The choice depends on how much a topic has to say. This is the one place where the site-versus-page decision matters, so decide it per topic. | Situation | Better choice | Why | | --- | --- | --- | | The topic fits on one page | A page on your main site | It inherits the site’s existing authority and links | | The topic is a service with its own buyer questions, pricing and comparisons | A focused site | The whole domain is about the thing the buyer typed | | Brand-plus-word searches | Pages on your main site, or one brand site | The brand carries the ranking. The page supplies the answer | | Many topics, same copy with a name swapped | Neither | Google’s scaled content abuse policy covers many pages that add no value, however they were produced | We build [Flotta](https://www.flotta.ai/) for the second row. It reads your existing website for brand, colours and tone, maps the searches your customers make into topics, and builds and runs a focused site for each one with its own enquiry form. Every page passes automated checks and a second-model review before you approve it. Every enquiry arrives with the page and search that earned it. The options look like this side by side: | Option | Who does the work | Time until pages are live | Quality control | Do you know which page earned each lead? | | --- | --- | --- | --- | --- | | Your website as it is | Nobody new | Already live | Your existing review | Depends on the tracking in place | | An agency | The agency’s team | After briefs, drafts and revisions | Experienced people review each page | If attribution is in the brief | | A content hire | One writer | One page at a time | Self-edited unless you review | If they wire up the tracking | | Focused sites run by a platform | The platform runs, you approve | After generation passes the checks | Automated checks, a second-model review, your approval | Every lead carries its page | ## How to measure Treat visibility, visits and enquiries as three separate numbers with three separate owners. A citation can happen without a visit. A visit can help a reader without producing an enquiry. And an enquiry can look fine until sales finds it’s outside your region. | Measure | Definition | Source | What it can’t tell you | | --- | --- | --- | --- | | Impressions | Times a page appeared in results, including AI features | Search Console, Web search type | Which impressions were inside an AI answer. Google reports them together | | Sampled AI appearances | Whether you appear for a fixed set of buyer questions, checked on a schedule | Your own log of questions, dates and cited pages | Market-wide visibility. It’s a sample under recorded conditions | | Qualified enquiries | Form, call or email that meets your written definition | CRM, with the source page and search term attached | Whether the page caused the decision or confirmed it | | Assisted conversions | An enquiry that came by phone or direct visit after an earlier session read a search page | Analytics attribution with a stated lookback window | Certainty. Label it assisted and keep it separate | Sample AI answers the same way each time. Choose the questions before looking at the results, include early and late stages of the decision, record the date and wording, and keep the misses. Swapping hard questions for ones that already show you is the fastest way to fool yourself. A worked example shows why the stages need separate numbers. These are assumptions for the arithmetic, and they are neither a customer result nor a benchmark. | Scenario | Visits per month | Enquiry rate | Enquiries | Qualified share | Qualified enquiries | Cost per qualified enquiry at EUR 1,500 per month | | --- | --- | --- | --- | --- | --- | --- | | Today | 2,000 | 1.0% | 20 | 40% | 8 | EUR 188 | | Better pages, same traffic | 2,000 | 1.5% | 30 | 50% | 15 | EUR 100 | | More traffic, same pages | 3,000 | 1.0% | 30 | 40% | 12 | EUR 125 | The middle row wins without any extra traffic. That is the usual shape: the pages and the fit move the number more than the volume does. Don’t extend it to revenue without win rates and deal sizes from your own CRM. ## Start with one enquiry journey Pick one service and follow its journey from a search to a qualified enquiry in the CRM. Run the checklist on the pages involved, fix what interrupts the journey, and send a test enquiry through to the team. Our [lead generation automation case study](https://www.aigentcy.com/case-studies/odoo-lead-generation-automation/) shows what the handover into a CRM looks like when it works. Then look at the searches that journey misses. If a topic has its own buyer questions, give it a focused site. If it is one page’s worth, write the page. Either way, the enquiry definition from the first section decides whether it worked. Bring three things to the next review: - The affected pages and the faults found on them. - A sample of qualified and unsuitable enquiries from the same period. - The agreed baseline for impressions, enquiries and qualified enquiries. If you want the focused sites run for you, [Flotta](https://www.flotta.ai/) does that work and returns each enquiry with its source. If the bottleneck is what happens after the enquiry arrives, our [process automation](https://www.aigentcy.com/services/process-automation/) team handles the routing, the CRM and the follow-up. ## Frequently asked questions Is AI search optimization different from normal SEO? For Google, no. Its own guidance says there are no additional requirements to appear in AI Overviews or AI Mode beyond being indexed and eligible for a snippet. What changes is how the page is read: AI features assemble answers from passages, so a page needs a clear answer under a clear heading rather than a long build-up. Should we fix technical SEO or publish more content first? Fix the faults that stop buyers reaching or using the pages you already have. A blocked page, a broken contact form or a canonical pointing at the wrong address wastes every new article you publish. Once the journey works, add pages for the buyer questions you can't answer today. How do we know if AI assistants cite us? Google reports AI Overview and AI Mode traffic inside the ordinary Web search type in Search Console, so you can't separate it there. Sample a fixed set of buyer questions on a schedule, record whether you appear and which page is cited, and keep the misses as well as the hits. Do micro sites hurt our main website? Not when each one covers a distinct search topic with pages written for that topic. Your main site keeps its brand and service searches. Problems start when many sites carry the same copy with a name swapped in, which Google treats as scaled content abuse. What should a technical SEO audit give us? A short list of faults ranked by the buyer journey each one interrupts, an owner for each fix, and a way to verify the repair. A report with three hundred warnings and no ranking is a data export. ## Related reading - [AI content quality at volume: expertise in, drafts out](https://www.aigentcy.com/blog/ai-generated-content-quality/)A cheap draft can be expensive to approve. Put the expertise in before the machine writes, let deterministic checks and a critic reject what fails, and measure cost per approved article. - [AI cost management: what an accepted result costs](https://www.aigentcy.com/blog/enterprise-ai-cost-control/)How to report AI spend the way finance reports everything else: by team, by workflow and by accepted result, with unknown charges kept separate from zero. - [An AI governance framework your team can operate](https://www.aigentcy.com/blog/enterprise-ai-governance-framework-guide/)A decision guide for the people who sign off AI systems: how much governance each one needs, who does what in the first 90 days, what it costs to run, and the evidence that proves the rules were followed. - [Lead qualification and follow-up in Odoo](https://www.aigentcy.com/case-studies/odoo-lead-generation-automation/)Case study [See Flotta, our SEO and content platform](https://www.flotta.ai/) [Talk to us about your project](https://www.aigentcy.com/contact/) --- # Shared code knowledge for an engineering team A queryable map of services and dependencies gives engineers and their assistants scoped context for planning and reviewing changes. Agentic engineering Software engineering ## Results lower model cost per question on the main product repository 27% assistant turns per question, down from 13 8 to set up the graph and the gateway on a new repository Under 10 minutes of model requests carry a key tied to a person or a service, with a budget 100% Cost and turns were measured on a fixed question set in real assistant sessions, one run per configuration, during the first two months. **Fewer turns is where the saving comes from** Two graph queries replace most of the file reads, so the question is answered in 8 turns instead of 13 and the billed cost is 27% lower on the main repository. ## The problem Cross-service changes needed context from several repositories. Engineers were collecting that context manually and reconstructing dependencies during review. A change that touched three services needed context from three repositories. An engineer opened each one, searched for the interfaces, read the callers and pasted what they found into the assistant's prompt. The assistant then searched and read the same files again. That showed up as cost. On the main product repository a structural question took about 13 assistant turns, most of them file reads, before an answer appeared. Nobody could say what the team spent on models per person, because the provider keys sat on laptops. The project created a shared, queryable model of services and relationships so engineers and assistants could retrieve context for the task. It also gave the team one place to see model spend. ## What we built The shared context layer exposes services, interfaces and relationships for scoped retrieval and change planning. - Retrieve relevant services and interfaces for a task. - Inspect dependencies before planning a cross-service change. - Use the dependency map to identify areas that need testing. - Prepare release notes from the changes for engineer review. ## How we built it 1. Indexed each repository into a local code graph of definitions, calls and dependencies, refreshed by a hook after every change. 2. Exposed the graph to the assistants as a tool, so a question about callers or dependencies is answered from the index instead of a search across files. 3. Put every model request behind one gateway. Each engineer and each service has its own key with a budget, and provider keys stay off laptops. 4. Added a console that shows spend per person, team and model, and which sessions used the graph. 5. Wrote a benchmark: a fixed set of questions run through real assistant sessions with and without the graph, recording billed cost and turns. ## What changed The team has a common starting point for change planning, dependency review and release preparation. Retrieved context still needs checking against current code and tests; it is not a guarantee that a proposed change is safe. An engineer planning a cross-service change asks the assistant which services call an interface and gets the list from the graph. Release notes are prepared from the changes and checked by an engineer. Nothing in the graph replaces reading the current code or running the tests. The saving depends on the question. Discovery-heavy questions across many files got cheaper. On a 134,000-line repository the difference was within run-to-run noise, and a task that already names the exact file gains nothing. We underestimated how much the gateway would matter on its own. Seeing spend per person for the first time changed model choices more than the graph did in the first month. ## How the workflow fits together Shared code context supports planning, dependency review and release preparation ```mermaid flowchart TD accTitle: Shared code context supports planning, dependency review and release preparation M[Queryable services, interfaces and dependencies] --> C[Retrieve context for the task] C --> P[Plan a cross-service change] C --> T[Identify dependencies and areas to test] C --> N[Prepare release notes from changes] P --> R[Engineers review current code and test evidence] T --> R N --> R ``` ## What we measured and how Each figure in the results block comes from one of these measurements. | What we measured | How | Result | | --- | --- | --- | | Model cost per question | Billed cost from real assistant sessions on a fixed question set, run with and without the graph. | 27% lower on the main product repository, 15% lower on a small one | | Assistant turns per question | Counted from the session records of the same runs. | 7.8, from 13.2 | | Setup time | Timed on new repositories, from install to a passing health check. | Under 10 minutes | | Spend attribution | Gateway records: every request carries a key tied to a person or a service. | 100% of requests | ## Planning a similar project These are questions to resolve with your team before implementing a similar workflow. | Decision | What to establish | | --- | --- | | Context freshness | Which repositories and revisions does the map represent? Make stale or missing context visible before an assistant uses it to propose a change. | | Access scope | Which engineers and assistants may retrieve each repository or service? Apply the project's access boundaries to retrieval as well as to direct source access. | | Evidence of value | Can you compare cost, turns and review effort for the same questions with and without the map? Count incorrect retrievals and rework as well, because fewer tokens alone is not enough evidence. | ## Questions about this workflow Does a dependency map prove a change is safe? No. It helps identify the relevant services, interfaces and areas to test. Engineers still read the current code, review the proposed change and run the tests. What context do engineers and assistants retrieve? The layer exposes services, interfaces and relationships for scoped retrieval. A task can pull the relevant context instead of someone assembling a whole-codebase prompt each time. How should a team evaluate the cost of code-context retrieval? Run the same questions with and without the graph in real sessions and compare billed cost, turns and rework. Keep model choice and pricing fixed across the comparison. The figures on this page came from one run per configuration, so treat them as the direction and measure your own repository before relying on them. ## Discuss your workflow. Tell us which systems your team uses and where the work gets stuck. [Discuss your project](https://www.aigentcy.com/contact/) [Private AI](https://www.aigentcy.com/services/private-ai/) [Back to case studies](https://www.aigentcy.com/case-studies/) --- # Support triage with replies ready for review Incoming tickets are categorised and routed, with suggested replies drawn from the team's help documents. Agents review and send. Process automation Customer support ## Results from a ticket arriving to a draft reply in the agent's queue Under 2 minutes of tickets routed to the right queue on the first pass 91% of drafts sent as they were or with a light edit 62% of sampled sensitive requests reached a person before any reply 100% Measured over the first three months on about 1,200 tickets a month, with a weekly sample of 50 tickets graded by the support team. **Three steps moved, two stayed** Sorting, routing and drafting run when the ticket arrives. Checking the draft and sending it stay with the agent, and sensitive requests never get a draft at all. ## The problem Agents had to categorise, tag and route incoming tickets before they could start resolving them. Repeated questions also meant drafting the same kinds of replies. Every ticket started with sorting. An agent read the message, picked a queue, added tags and set a priority before anyone could answer it. On a busy morning that was the first hour of the day. The same questions came back every week, such as password resets, invoice copies and delivery status. Each one got a reply typed from scratch or pasted from a personal snippet file, so the answers drifted away from the help documents. Sensitive cases were the worry. A complaint or a request to close an account needs a person straight away, and a queue sorted by hand can bury it. The project brought the preparation steps into the existing helpdesk and left the decision to edit and send with the agent. ## What we built The workflow prepares the ticket and a suggested reply inside the existing support process. - Categorise and prioritise incoming emails and form submissions. - Route tickets with consistent tags. - Draft suggested replies from the team's approved help documents. - Flag ambiguous or sensitive requests for a person. ## How we built it 1. Wrote the routing scheme down with the support lead: eight queues, the tags that change who handles a ticket, and twenty examples of tickets that are hard to place. 2. Built the intake step. Each email or form submission is categorised, given a priority and routed with consistent tags. 3. Connected the approved help documents so every draft cites the document it drew from. If no document covers the question, the ticket gets a note instead of a draft. 4. Added a fixed rule for sensitive requests. Complaints, account closures and anything that mentions a regulator or a lawyer skip the draft and go to a person. 5. Set up the weekly sample. A senior agent grades 50 tickets for routing and draft quality, and the results go on a shared dashboard. ## What changed Agents receive a sorted queue and a draft they can check or edit. Ambiguous and sensitive questions remain with a person. Agents open a sorted queue with a draft attached to most routine tickets. They read the customer's message, check the draft against it, then send or edit. Nothing reaches a customer until an agent presses send. The weekly sample kept the numbers honest. Routing accuracy started at 84% and reached 91% after we merged two queues that overlapped. Draft acceptance rose as the team retired the outdated help documents the drafts kept surfacing. We underestimated how much of the value sat in the sample rather than the drafting. The grading exposed stale help content and a queue nobody owned. Both were problems before the project and invisible until then. ## How the workflow fits together Support intake prepares the queue and a draft for agent review ```mermaid flowchart TD accTitle: Support intake prepares the queue and a draft for agent review I[Email or form submission] --> T[Categorise, prioritise and route] T --> D[Prepare a suggested reply] H[Approved help documents] --> D D --> R[Agent checks, edits and sends] T --> E[Flag ambiguous or sensitive requests] E --> R ``` ## What we measured and how Each figure in the results block comes from one of these measurements. | What we measured | How | Result | | --- | --- | --- | | Time to a draft reply | Helpdesk timestamps, from the ticket being created to the draft being attached. | Median under 2 minutes for routine tickets | | Routing accuracy | A weekly sample of 50 tickets, each checked against the agreed scheme by a senior agent. | 91% correct on the first pass, from 84% in month one | | Draft acceptance | The sent reply compared with the draft and grouped: sent as it was, light edit, rewritten, or no draft. | 62% sent as they were or with a light edit | | Sensitive requests | The fixed rule, plus a weekly review of every flagged ticket and a search of the sample for missed ones. | All sampled sensitive requests reached a person before any reply | ## Planning a similar project These are questions to resolve with your team before implementing a similar workflow. | Decision | What to establish | | --- | --- | | Queue decisions | Which tags and priorities change who handles the ticket? Start with a small, agreed routing scheme and examples of difficult requests. | | Reply sources | Which help documents are approved and who maintains them? Decide what happens when a source is missing, outdated or does not answer the question. | | Review quality | Which cases must reach a person immediately? Sample the routing and the drafts separately so a good-looking draft does not hide a routing error. | ## Questions about this workflow Are replies sent without an agent checking them? No. The workflow prepares a draft for review. The agent checks it, edits it if needed and sends it. The workflow cannot send a reply on its own. What happens to ambiguous or sensitive requests? They are flagged for a person and skip the draft. The workflow prepares routine tickets and leaves uncertain or sensitive questions to human judgement. How should a team evaluate support automation? Grade routing accuracy, the share of drafts sent or edited, and the time agents spend resolving tickets. This case used a weekly sample of 50 tickets graded by a senior agent. Check the difficult and sensitive cases as well as the common questions, because faster drafting alone does not show better support. ## Discuss your workflow. Tell us which systems your team uses and where the work gets stuck. [Discuss your project](https://www.aigentcy.com/contact/) [Process automation](https://www.aigentcy.com/services/process-automation/) [Back to case studies](https://www.aigentcy.com/case-studies/) --- # HR reporting and reminders in BambooHR Scheduled leave reports, approval reminders and employee-change notifications from BambooHR, delivered in Slack and email. Process automation Human resources Built with Rachel Tabone Hall, Head of HR. ## Results returned to the HR team 5 hours a week leave requests still waiting after a week, down from 1 in 4 1 in 20 monthly leave reports delivered on schedule 6 of 6 IT hears about employee changes, previously up to a week Same day Measured over the first six months after go-live, against four weeks of logged time before it. **Four schedules, one reviewer** Each task runs on its own day and goes to the channel its recipient already reads. HR sees every report before anyone acts on it. ## The problem The team needed a repeatable way to prepare leave data, remind managers about pending approvals and notify IT of relevant employee changes. The recurring work crossed three groups. Managers approved time off, HR prepared leave information for payroll, and IT needed to know about starters, leavers and role changes. Before the project the HR team rebuilt the same information by hand. Someone exported leave data from BambooHR, tidied it in a spreadsheet and sent it on. Managers were chased for approvals one message at a time. That took about six and a half hours a week, and it was easy to miss. A late monthly report held up the payroll check. A leave request could sit unapproved for two weeks because nobody noticed it, and IT found out about a new starter when someone remembered to tell them. Rachel and the team helped sort the tasks into two groups: the ones that could run on a schedule and the ones that still needed a person to decide. ## What we built We mapped the scheduled tasks with Rachel Tabone Hall, Head of HR, and connected BambooHR to the channels the team already uses. - Send managers pending leave approvals scoped to a seven-day window. - Prepare the monthly leave report for HR. - Run carryover reminders, absence-pattern flags and zero-hour reports on schedule. - Notify IT of non-confidential employee-profile changes. ## How we built it 1. Listed every recurring task with the HR team: who needs it, which BambooHR fields it uses and when it is due. 2. Agreed the data boundaries. Managers see their own team's pending requests, and IT receives non-confidential profile changes only. 3. Connected BambooHR to Slack and email, with each report and reminder on its own schedule. 4. Ran the schedules beside the manual process for one month and compared the outputs line by line. 5. Handed over with a named owner, a log of every run and a way to pause any schedule. ## What changed Reports and reminders run on a schedule. Managers still approve leave, and the HR team reviews the information before acting on it. Reports and reminders now arrive without anyone asking for them. A manager gets one message a week listing the requests waiting on them, scoped to a seven-day window, with names and dates. HR checks the monthly report instead of building it. The approval backlog shrank because the reminder is specific. Requests waiting more than a week went from about 1 in 4 to 1 in 20, and the monthly report has been ready for the payroll check every month since go-live. What we underestimated was the cleanup. About a third of the first month went into fixing BambooHR records the reports exposed, such as missing managers and wrong leave allowances. The reports have been clean since. ## How the workflow fits together BambooHR supplies scheduled reports, reminders and relevant employee updates ```mermaid flowchart TD accTitle: BambooHR supplies scheduled reports, reminders and relevant employee updates B[BambooHR] --> R[Leave and absence reports] B --> M[Approval and carryover reminders] B --> I[Non-confidential employee changes] R --> H[HR reviews the information] M --> A[Managers and employees act] I --> T[IT updates its processes] ``` ## What we measured and how Each figure in the results block comes from one of these measurements. | What we measured | How | Result | | --- | --- | --- | | HR time on reports and reminders | The team logged time on these tasks for four weeks before go-live, then again in months three and six. | From 6.5 hours a week to 1.5, so 5 hours returned | | Leave requests waiting more than seven days | Counted from the request dates in BambooHR every Monday. | From 1 in 4 to 1 in 20 | | Monthly report delivered on time | The run log compared with the payroll cut-off date each month. | 6 of 6 on schedule | | Delay before IT learned of a change | The change date in BambooHR compared with the date of the IT ticket. | Same working day, from up to a week | ## Planning a similar project These are questions to resolve with your team before implementing a similar workflow. | Decision | What to establish | | --- | --- | | Report ownership | Who uses each report, which period should it cover, and when do they need it for payroll or HR review? | | Data boundaries | Which employee fields may reach HR, managers or IT? Agree the permitted fields and recipients before connecting the channels. | | Exceptions | Who checks missing data, failed runs or unusual absence patterns? A reminder needs a named owner who can act on it. | ## Questions about this workflow Does the workflow approve leave automatically? No. It prepares reports and sends reminders. Managers keep the leave-approval decision, and HR reviews information before acting on it. Does IT receive the full employee record? No. The workflow sends non-confidential profile changes that IT needs, such as a start date or a role change. A similar implementation should list its allowed fields and recipients before anything is connected. How would you measure the value of a similar HR workflow? Log the time spent preparing each report and chasing approvals before you start. Then compare preparation time, missed runs and approval delays over several reporting cycles. The figures on this page came from that comparison: four weeks of logged time before go-live, then months three and six. ## Discuss your workflow. Tell us which systems your team uses and where the work gets stuck. [Discuss your project](https://www.aigentcy.com/contact/) [Process automation](https://www.aigentcy.com/services/process-automation/) [Back to case studies](https://www.aigentcy.com/case-studies/) --- # The work behind the automation. How we connect systems, prepare decisions and keep people in control. Read what each workflow does and what changed for the team using it. Client work ## Real outcomes for real enterprises. [ **Four schedules, one reviewer** Each task runs on its own day and goes to the channel its recipient already reads. HR sees every report before anyone acts on it. Human resources ### HR reporting and reminders in BambooHR Scheduled leave reports, approval reminders and employee-change notifications from BambooHR, delivered in Slack and email. Read the case study ](https://www.aigentcy.com/case-studies/hr-automation/)[ **Three steps moved, two stayed** Sorting, routing and drafting run when the ticket arrives. Checking the draft and sending it stay with the agent, and sensitive requests never get a draft at all. Customer support ### Support triage with replies ready for review Incoming tickets are categorised and routed, with suggested replies drawn from the team's help documents. Agents review and send. Read the case study ](https://www.aigentcy.com/case-studies/customer-support-automation/)[ **Where the buyer's time goes now** Matched lines reach the approval queue with the three documents attached. The buyer's checking time is spent on the 1 in 5 invoices that carry a real difference. Wholesale distribution ### Purchase orders and invoice checks Draft purchase orders from stock data and compare invoices with orders and deliveries. Buyers review exceptions and approve. Read the case study ](https://www.aigentcy.com/case-studies/wholesale-procurement-automation/)[ **The wait moved from days to minutes** The four manual steps that took a day or two now run in the CRM within minutes of the enquiry. The consultant's review is the last step, and the reply still goes out in their words. IT services ### Lead qualification and follow-up in Odoo Capture enquiries in Odoo, add company context and prepare follow-up. Consultants review the fit and handle the conversation. Read the case study ](https://www.aigentcy.com/case-studies/odoo-lead-generation-automation/)[ **Fewer turns is where the saving comes from** Two graph queries replace most of the file reads, so the question is answered in 8 turns instead of 13 and the billed cost is 27% lower on the main repository. Software engineering ### Shared code knowledge for an engineering team A queryable map of services and dependencies gives engineers and their assistants scoped context for planning and reviewing changes. Read the case study ](https://www.aigentcy.com/case-studies/agentic-second-brain/) 78% Average process time reduction 50+ Enterprise clients served 6+ Industries covered 14 wk Average governance framework delivery ## Let's build your AI future together. [Get started](https://www.aigentcy.com/contact/) [Call +356 7990 2911](tel:+35679902911) --- # Lead qualification and follow-up in Odoo Capture enquiries in Odoo, add company context and prepare follow-up. Consultants review the fit and handle the conversation. Process automation IT services An Odoo Service Provider ## Results from an enquiry arriving to a reviewed follow-up, previously 1 to 2 days 15 minutes of enquiries logged in Odoo, up from about 70% 100% returned to the consultants 4 hours a week of enquiries screened as a poor fit before a consultant reads them 40% Measured over the first three months on about 60 enquiries a month. **The wait moved from days to minutes** The four manual steps that took a day or two now run in the CRM within minutes of the enquiry. The consultant's review is the last step, and the reply still goes out in their words. ## The problem Enquiries arrived through several channels and needed manual research, CRM entry and follow-up. That work competed with client delivery. Enquiries came in through the website form, direct email and partner referrals. Whoever saw one first looked up the company, typed a CRM record and replied when delivery work allowed. That took a day or two, and about 3 in 10 enquiries were never logged at all. The consultants are the firm's billable people, so this admin competed with client work. Follow-ups were inconsistent, and two consultants sometimes answered the same enquiry. Speed matters here. A [Harvard Business Review study of 2,241 companies](https://hbr.org/2011/03/the-short-life-of-online-sales-leads) found that firms which contacted a lead within an hour were nearly seven times as likely to qualify it as firms that waited even an hour longer. ## What we built The workflow collects inbound enquiries in Odoo and prepares the information a consultant needs to review them. - Capture website and inbound enquiries in Odoo CRM. - Add company and contact context. - Score enquiries against the firm's agreed ideal-client profile. - Assign the enquiry and prepare a first follow-up for review. ## How we built it 1. Routed every channel into Odoo CRM: the website form, the shared inbox and a forwarding address for partner referrals. Duplicates are matched on email domain and company name. 2. Added company and contact context: size, sector, website, any Odoo modules visible on the site, and previous contact already in the CRM. 3. Wrote the ideal-client profile down with the partners and turned it into a score with reasons, so a consultant sees why an enquiry scored as it did. 4. Assigned each enquiry to one consultant by sector and prepared a first follow-up as a draft in the CRM. 5. Reviewed the scores with the partners every two weeks for three months and adjusted the criteria twice. ## What changed Consultants start with enquiries and company context in their CRM. They retain the qualification decision and the customer conversation. A consultant opens Odoo and sees the enquiry, the company context, a score with reasons and a draft reply. They decide whether to pursue it and send the reply in their own words. Nothing reaches the prospect until they do. The score's main job turned out to be saying no early. About 40% of enquiries are students, job seekers or companies outside the firm's regions. Those now get a polite reply before a consultant spends time on them. We underestimated duplicates. Partner referrals often arrived twice, once from the partner and once from the prospect, and merging them needed a rule we had not planned for. ## How the workflow fits together Enquiries become prepared Odoo records for consultant review ```mermaid flowchart TD accTitle: Enquiries become prepared Odoo records for consultant review E[Website and inbound enquiries] --> C[Capture in Odoo CRM] C --> X[Add company and contact context] X --> S[Score fit and assign a consultant] S --> D[Prepare the first follow-up] D --> R[Consultant reviews fit and handles the conversation] ``` ## What we measured and how Each figure in the results block comes from one of these measurements. | What we measured | How | Result | | --- | --- | --- | | Time to a reviewed follow-up | Odoo timestamps, from the enquiry being created to the consultant marking the reply as sent. | Median 15 minutes in working hours, from 1 to 2 days | | Enquiries logged | The monthly count of CRM records compared with inbox and form submissions. | 100%, from about 70% | | Consultant time on enquiry admin | Logged for three weeks before go-live and again in month three. | From about 5 hours a week to 1, so 4 hours returned | | Score corrections | Consultants mark a score as wrong when they disagree with it. | 1 in 8 in month one, 1 in 20 by month three | ## Planning a similar project These are questions to resolve with your team before implementing a similar workflow. | Decision | What to establish | | --- | --- | | Intake coverage | Which channels should create a CRM record? Identify duplicate submissions and ownership rules so two consultants do not follow up on the same enquiry. | | Qualification criteria | What makes an enquiry a good fit for the firm? Write the criteria down and decide how to handle missing company information before using a score. | | Follow-up ownership | Who reviews the prepared message and owns the next action? Decide how consultants can correct the context or disagree with a score. | ## Questions about this workflow Does this replace the consultancy's CRM? No. The workflow uses the existing Odoo CRM for enquiry capture, company context, assignment and follow-up preparation. Consultants work in the same screens they used before. Who decides whether a lead is a fit? The workflow scores enquiries against the agreed ideal-client criteria and shows its reasons. Consultants keep the qualification decision and the customer conversation, and they can mark a score as wrong. What would demonstrate value for a similar sales workflow? Track the delay between an enquiry arriving and a reviewed follow-up, the share of enquiries logged, duplicate work and score corrections. Compare those with the original process before attributing changes in pipeline or revenue to the automation. This page reports the first four and makes no revenue claim. ## Discuss your workflow. Tell us which systems your team uses and where the work gets stuck. [Discuss your project](https://www.aigentcy.com/contact/) [Process automation](https://www.aigentcy.com/services/process-automation/) [Back to case studies](https://www.aigentcy.com/case-studies/) --- # Purchase orders and invoice checks Draft purchase orders from stock data and compare invoices with orders and deliveries. Buyers review exceptions and approve. Process automation Wholesale distribution A Wholesale Provider ## Results returned to the two buyers 16 hours a week of invoice lines matched to the order and the delivery without a buyer touching them 80% to prepare the weekly supplier orders, down from about 3 hours 45 minutes orders placed or invoices paid without a buyer's approval 0 Measured over the first three months on about 400 supplier invoices and 60 purchase orders a month. **Where the buyer's time goes now** Matched lines reach the approval queue with the three documents attached. The buyer's checking time is spent on the 1 in 5 invoices that carry a real difference. ## The problem Buyers were checking stock, preparing supplier orders and comparing invoice lines with orders and deliveries by hand. Two buyers ran purchasing for the warehouse. Each week one of them went through stock levels and recent sales by hand, worked out what to reorder and typed the supplier orders. That took most of a morning. Invoices were the bigger cost. Every invoice line was checked against the order and the delivery note by eye, about 400 invoices a month at around 12 minutes each. Price changes and short deliveries were caught late or missed. Preparing an order and checking an invoice are related tasks that need different evidence. The project used stock and recent sales for the order side, and the order, the delivery and the invoice for the checking side. Buyers kept every approval. ## What we built The workflow prepares reorder suggestions and purchase orders, then flags mismatches for review. - Prepare reorder suggestions from stock levels and recent sales. - Draft purchase orders by supplier for buyer approval. - Compare invoice quantities and prices with orders and deliveries. - Flag price changes, short deliveries and unfamiliar suppliers. ## How we built it 1. Mapped supplier and item codes across the stock system, purchase orders, delivery notes and invoices, so the same product is recognised in all four. 2. Built reorder suggestions from current stock, recent sales and each supplier's lead time, grouped into one draft order per supplier. 3. Added the three-way check. Each invoice line is compared with the order line and the delivery line on quantity and price. 4. Agreed the exception rules with the buyers: any price change, any short delivery, any supplier not on the approved list, and any invoice with no matching order. 5. Ran it beside the manual checks for six weeks and compared every flag before switching over. ## What changed The buyer reviews prepared orders and flagged exceptions. The workflow does not place orders or pay invoices without approval. The buyer starts the week with draft orders to review instead of a spreadsheet to build. Invoices that match on every line go to the approval queue with the evidence attached. The rest come to the buyer with the mismatch highlighted. About 1 in 5 invoices carries a real difference, most often a price that changed after the order was placed. Those take a buyer about 10 minutes each to resolve, which is where the remaining checking time goes. We underestimated the code mapping. Three suppliers used their own item codes on invoices, and the match rate sat at 55% until we built the translation table. After that it settled at 80%. ## How the workflow fits together Procurement preparation and three-way matching retain buyer approval ```mermaid flowchart TD accTitle: Procurement preparation and three-way matching retain buyer approval S[Stock levels and recent sales] --> P[Draft purchase order by supplier] P --> A[Buyer reviews and approves] O[Purchase order] --> M[Compare quantities and prices] D[Delivery record] --> M I[Supplier invoice] --> M M --> E[Buyer reviews mismatches and exceptions] ``` ## What we measured and how Each figure in the results block comes from one of these measurements. | What we measured | How | Result | | --- | --- | --- | | Buyer time on orders and invoice checks | Logged for four weeks before go-live and again in month three. | From about 21 hours a week to 5, so 16 hours returned | | Invoice lines matched automatically | Counted in the match log as lines that agreed on quantity and price with the order and the delivery. | 80% in month three, from 55% in month one | | Order preparation time | Timed weekly runs, from opening the stock data to sending the orders. | 45 minutes, from about 3 hours | | Missed mismatches | A six-week parallel run in which every manual flag was compared with the system's flags. | 3 missed before the code mapping was fixed, none after | | Approvals bypassed | Every order and payment checked for a buyer's approval record. | 0 | ## Planning a similar project These are questions to resolve with your team before implementing a similar workflow. | Decision | What to establish | | --- | --- | | Source records | Can the same supplier and item be identified across stock, purchase orders, deliveries and invoices? Resolve those mappings before relying on a match. | | Exception rules | Who reviews changed prices, partial deliveries and unfamiliar suppliers? Agree which differences need approval and what evidence the buyer should see. | | Approval boundaries | Who may approve a purchase order or a payment? Keep those decisions separate from preparing a document or flagging a mismatch. | ## Questions about this workflow Does the workflow place orders or pay invoices? No. It prepares supplier orders and checks invoice lines. Buyers review and approve. In three months no order was placed and no invoice was paid without a buyer's approval record. What is being matched in this case? Invoice quantities and prices are compared with the purchase order and the delivery record, line by line. Differences such as a changed price or a short delivery are flagged for the buyer with the three documents side by side. What should a buyer measure after implementation? Compare the time spent preparing orders and checking invoices, the number and type of exceptions, and the work needed to resolve them. Check both missed mismatches and unnecessary flags. This case measured those through a six-week parallel run against the manual checks. ## Discuss your workflow. Tell us which systems your team uses and where the work gets stuck. [Discuss your project](https://www.aigentcy.com/contact/) [Process automation](https://www.aigentcy.com/services/process-automation/) [Back to case studies](https://www.aigentcy.com/case-studies/) --- # Which workflow needs attention? Tell us what happens today, which tools are involved and where your team spends time. That is enough to start a useful conversation. Contact info ## Reach out to us. Our location Malta Email us [info@aigentcy.com](mailto:info@aigentcy.com) Call us [+356 7990 2911](tel:+35679902911) Connect [LinkedIn](https://www.linkedin.com/company/130554432/)[X](https://x.com/aigentcy) Based in Malta. [View Malta on Google Maps](https://maps.google.com/?q=Malta). ## Let's build your AI future together. [Get started](https://www.aigentcy.com/contact/) [Call +356 7990 2911](tel:+35679902911) --- # Cookie policy Last updated: 15 September 2026 This policy covers www.aigentcy.com. It lists what the site stores in your browser, what loads only with your permission, and how to change your choice. For what happens to the details you send through a form, read our [privacy policy](https://www.aigentcy.com/privacy-policy/). ## Categories The site has two categories. Essential storage is always on, because the site needs it to work and to remember your choice. Marketing is off until you accept it in the cookie banner. Nothing in the marketing category loads before you choose. ## Essential storage - `aigentcy-consent` in local storage holds your cookie choice, the date you made it and the version of these categories. It's kept for 12 months. After that, or when we change the categories, the banner asks again. - `aigentcy-theme` in local storage holds the light or dark theme, if you pick one. It stays until you clear it. - `audit-request` in session storage carries the short reference from the audit form to its confirmation page. Your browser clears it when the tab or session ends. None of these is an advertising identifier, and none of them follows you to other websites. ## Marketing: the Meta Pixel The Meta Pixel is a script from Meta Platforms Ireland Limited. We use it to measure visits and enquiries that come from our ads on Facebook and Instagram. It loads only after you accept marketing cookies, and the legal basis is your consent. Once you accept, the site sends Meta a page view for each page you open. It also sends a lead event when you send the contact form, the audit form, the EU AI Act quiz or the policy generator. The lead event names the form. Meta also receives technical details such as your IP address, your browser and the address of the page, and it can match these events to a Facebook or Instagram account. Meta uses this data under its own [privacy policy](https://www.facebook.com/privacy/policy/). - `_fbp` is a cookie on aigentcy.com that the pixel sets to recognise your browser on later visits. It lasts 90 days. - `_fbc` is a cookie on aigentcy.com that the pixel sets when you arrive from a click on one of our ads. It lasts 90 days. - If you're logged in to Facebook or Instagram in the same browser, Meta can also read its own cookies on facebook.com, such as `fr`, which lasts 90 days. ## Changing your choice Use Cookie settings at the bottom of any page. You can accept everything, reject everything, or tick or untick marketing and save. The change applies straight away. If you withdraw consent, the pixel stops sending events on the page you're on, the site removes the `_fbp` and `_fbc` cookies, and the pixel doesn't load on any later page. Meta's own cookies on facebook.com are managed in your Facebook or Instagram settings. Clearing this site's storage in your browser also resets your choice, and the banner appears again. ## Links to other services The links to ChatGPT, Claude and Perplexity open those services only when you choose to follow them. Their own privacy and cookie policies apply. Copying the prompt doesn't send it to an AI provider. ## Questions Send questions about this policy to [info@aigentcy.com](mailto:info@aigentcy.com). --- # Before you automate. Scope, systems, cost and control. These are the questions we work through before building. ## Need help? Start here. ### Book a free discovery call Thirty minutes on your priorities, then a scoped proposal within five business days. [+356 7990 2911](tel:+35679902911)[Or send a message](https://www.aigentcy.com/contact/) What does Aigentcy do? Aigentcy is an agentic AI agency specialising in three enterprise pillars: AI governance frameworks, private open-source model deployment, and intelligent process automation. We help organisations adopt AI responsibly, securely, and at scale. How does private AI model deployment work? We assess your use case and data environment, then select, fine-tune, and deploy an open-source LLM (such as Llama, Mistral, or Phi) entirely within your on-premise or private cloud infrastructure. Your data never touches a third-party server. What regulations does your AI Governance service cover? Our governance frameworks address the EU AI Act, ISO/IEC 42001, NIST AI RMF, SOC 2, GDPR, HIPAA, and Australian Privacy Act requirements. We map your specific obligations and build audit-ready controls around them. How long does a process automation engagement typically take? Discovery and process mapping typically takes 2–4 weeks. A focused automation sprint (one to three processes) runs 6–12 weeks. Enterprise-wide transformation programmes are phased over 3–12 months with measurable milestones at each stage. Do you work with existing enterprise systems? Yes. We integrate with SAP, Salesforce, ServiceNow, Microsoft 365, major ERP and CRM platforms, and most document management systems. Our automation solutions use standard API and RPA approaches to avoid vendor lock-in. How do I get started? Book a complimentary discovery call through our contact page. We'll spend 30 minutes understanding your priorities and return a scoped proposal within five business days. ## Let's build your AI future together. [Get started](https://www.aigentcy.com/contact/) [Call +356 7990 2911](tel:+35679902911) --- Enterprise agentic AI # Deploy AI with governance, privacy & control. [](https://www.aigentcy.com/about/) Aigentcy helps enterprises deploy AI governance frameworks, private open-source models, and intelligent process automation, securely and at scale. [Let's talk](https://www.aigentcy.com/contact/) [See our work](https://www.aigentcy.com/case-studies/) ![Aigentcy, enterprise agentic AI](https://www.aigentcy.com/assets/images/hero/hero-img.webp) 50+ ###### Enterprise clients trust Aigentcy with their AI programmes. [Scroll down](#choose) Why choose Aigentcy ## Enterprise AI done right. #### Governance-first approach We build compliance, risk management, and explainability into every AI deployment, not as an afterthought but as a foundation. #### Data sovereignty guaranteed Our private AI deployments keep your sensitive data within your own infrastructure, with no third-party cloud exposure, ever. #### Measurable ROI Every engagement is scoped with clear KPIs. We measure time saved, error rates reduced, and cost per process, then we deliver on them. ![About Aigentcy](https://www.aigentcy.com/assets/images/about/about-1.webp) Experience 5+ ###### Years deploying enterprise AI at scale Get to know us ## The AI agency built for enterprise reality. [Learn more](https://www.aigentcy.com/about/) ★★★★★ ★★★★★ > Aigentcy automated our sales pipeline for us. Every enquiry now lands in our CRM already qualified, scored, and assigned to the right person, with a first follow-up drafted, so we've stopped letting good leads go cold while we're heads-down on delivery. ###### Ernest Baldacchino Managing Director ![Ernest Baldacchino](https://www.aigentcy.com/assets/images/about/ernest-baldacchino.webp) Our services ## Three pillars of enterprise AI. ![AI Governance](https://www.aigentcy.com/assets/images/service/service-1.webp) #### [AI governance](https://www.aigentcy.com/services/ai-governance/) Comprehensive governance frameworks, risk management programmes, and audit-ready compliance infrastructure for regulated AI deployments. [Learn more](https://www.aigentcy.com/services/ai-governance/) ![Private AI Models](https://www.aigentcy.com/assets/images/service/service-5.webp) #### [Private AI models](https://www.aigentcy.com/services/private-ai/) Fine-tune and deploy open-source large language models entirely within your infrastructure, so your data never leaves your environment. [Learn more](https://www.aigentcy.com/services/private-ai/) ![Process Automation](https://www.aigentcy.com/assets/images/service/service-6.webp) #### [Process automation](https://www.aigentcy.com/services/process-automation/) Map, optimise, and automate manual business processes using AI agents, RPA, and intelligent document processing, reducing cost and error rates. [Learn more](https://www.aigentcy.com/services/process-automation/) Case studies ## Real outcomes for real enterprises. We work closely with our clients to understand their unique AI challenges and deliver measurable, sustainable results. [All case studies](https://www.aigentcy.com/case-studies/) ![HR automation](https://www.aigentcy.com/assets/images/project/hr-automation.webp) [Process automation](https://www.aigentcy.com/case-studies/hr-automation/) #### [HR automation](https://www.aigentcy.com/case-studies/hr-automation/) [](https://www.aigentcy.com/case-studies/hr-automation/) ![Customer support automation](https://www.aigentcy.com/assets/images/project/customer-support-automation.webp) [Process automation](https://www.aigentcy.com/case-studies/customer-support-automation/) #### [Automating customer support operations](https://www.aigentcy.com/case-studies/customer-support-automation/) [](https://www.aigentcy.com/case-studies/customer-support-automation/) ![Wholesale procurement automation](https://www.aigentcy.com/assets/images/project/wholesale-procurement-automation.webp) [Process automation](https://www.aigentcy.com/case-studies/wholesale-procurement-automation/) #### [Procurement automation for a wholesale provider](https://www.aigentcy.com/case-studies/wholesale-procurement-automation/) [](https://www.aigentcy.com/case-studies/wholesale-procurement-automation/) ![Odoo lead generation automation](https://www.aigentcy.com/assets/images/project/odoo-lead-generation-automation.webp) [Process automation](https://www.aigentcy.com/case-studies/odoo-lead-generation-automation/) #### [Automating lead generation for an Odoo service provider](https://www.aigentcy.com/case-studies/odoo-lead-generation-automation/) [](https://www.aigentcy.com/case-studies/odoo-lead-generation-automation/) ![FAQ](https://www.aigentcy.com/assets/images/faq/faq.webp) ## Need help? Start here... #### Book a free discovery call [+356 7990 2911](tel:+35679902911) What does Aigentcy do? Aigentcy is an agentic AI agency specialising in three enterprise pillars: AI governance frameworks, private open-source model deployment, and intelligent process automation. We help organisations adopt AI responsibly, securely, and at scale. How does private AI model deployment work? We assess your use case and data environment, then select, fine-tune, and deploy an open-source LLM (such as Llama, Mistral, or Phi) entirely within your on-premise or private cloud infrastructure. Your data never touches a third-party server. What regulations does your AI Governance service cover? Our governance frameworks address the EU AI Act, ISO/IEC 42001, NIST AI RMF, SOC 2, GDPR, HIPAA, and Australian Privacy Act requirements. We map your specific obligations and build audit-ready controls around them. How long does a process automation engagement typically take? Discovery and process mapping typically takes 2–4 weeks. A focused automation sprint (one to three processes) runs 6–12 weeks. Enterprise-wide transformation programmes are phased over 3–12 months with measurable milestones at each stage. Do you work with existing enterprise systems? Yes. We integrate with SAP, Salesforce, ServiceNow, Microsoft 365, major ERP and CRM platforms, and most document management systems. Our automation solutions use standard API and RPA approaches to avoid vendor lock-in. How do I get started? Book a complimentary discovery call through our contact page. We'll spend 30 minutes understanding your priorities and return a scoped proposal within five business days. Insights & ideas ## The AI knowledge hub. **Expertise in, drafts out** The expert's work is finished before the machine writes. The checks and the critic run before any person reads, and the person's decision comes last and is recorded. Process automation 6 September 2026 13 min read ### [AI content quality at volume: expertise in, drafts out](https://www.aigentcy.com/blog/ai-generated-content-quality/) A cheap draft can be expensive to approve. Put the expertise in before the machine writes, let deterministic checks and a critic reject what fails, and measure cost per approved article. **From a search to a qualified enquiry** The count shrinks at each step, so each step needs its own number and its own owner. The figures are the article's worked example, not a result. Process automation 31 August 2026 13 min read ### [Technical SEO and AI search optimization: turn visibility into qualified demand](https://www.aigentcy.com/blog/technical-seo-and-ai-search/) Fix the crawl and index faults first, write pages that people and AI assistants can read, cover the searches your main site was never built for, and judge the work by qualified enquiries. **Three columns, three meanings** Recorded spend has a receipt, reserved allowance is a ceiling held while work runs, and an unconfirmed charge keeps its ceiling until a receipt or a review settles it. The total is never the sum of all three. AI governance 18 August 2026 13 min read ### [AI cost management: what an accepted result costs](https://www.aigentcy.com/blog/enterprise-ai-cost-control/) How to report AI spend the way finance reports everything else: by team, by workflow and by accepted result, with unknown charges kept separate from zero. [Read all insights](https://www.aigentcy.com/blog/) ## Let's build your AI future together. [Get started](https://www.aigentcy.com/contact/) --- # Privacy policy Last updated: 15 September 2026 ## 1\. Introduction Aigentcy is an AI automation agency based in Malta. We value your privacy and are committed to protecting your personal information. This privacy policy explains how we collect, use, share and protect information when you visit www.aigentcy.com or engage our services, in line with the EU General Data Protection Regulation (GDPR) and applicable Maltese law. Read it together with our [cookie policy](https://www.aigentcy.com/cookie-policy/). ## 2\. Information we collect - **Information you give us.** Your name, email address, phone number, company, the service you are interested in and anything you write in the contact form or the automation audit form. - **Free tools.** The EU AI Act readiness quiz collects your email address, your answers, your score and band. The AI compliance policy generator collects your email address and your questionnaire answers, such as company name, sector and role. Policy documents are assembled in your browser; the document itself is not sent to us. - **Campaign details.** When you arrive from one of our adverts, the audit form records the campaign tags in the link and the page you landed on. - **Technical information.** Your IP address and browser details, which our hosting provider processes to deliver and secure the site. We use your IP address to limit repeated form submissions. - **Cookies and similar technologies.** With your consent, the Meta Pixel. See section 6 and the cookie policy. ## 3\. How we use your information - To reply to your enquiry, arrange a call and provide the services you ask for. - To show your quiz result or prepare your policy document. - To protect the site and its forms from spam and abuse. - With your consent, to measure visits and enquiries from our adverts. - To meet our legal obligations. Submitting a form does not sign you up to any mailing list. ## 4\. Legal basis for processing - **Legitimate interests.** Replying to an enquiry you sent us, and keeping the site and its forms secure. - **Contractual necessity.** Where processing is needed to provide services you have asked for. - **Consent.** For the Meta Pixel. You can withdraw consent at any time from Cookie settings at the bottom of any page. - **Legal obligation.** Where the law requires us to process or keep information. ## 5\. Who processes your information We do not sell or rent your personal information. We use these service providers, who process information on our behalf and only for the purposes above: - **Cloudflare, Inc.** Hosts the site, runs the form handling, stores form submissions and provides Turnstile, the check that a form is sent by a person. - **Plunk.** Delivers the notification email that tells our team about your enquiry. - **Microsoft.** Hosts our business email, where those notifications and our replies are kept. - **Meta Platforms Ireland Limited.** Provides the Meta Pixel, only after you accept marketing cookies. Some of these providers may process information outside the European Economic Area. Where they do, they rely on safeguards recognised under the GDPR, such as the European Commission's standard contractual clauses. We may also disclose information where the law or a valid request from a competent authority requires it. ## 6\. Analytics and advertising The site does not use Google Analytics. With your consent, it loads the Meta Pixel to measure visits and enquiries from our adverts. It sends a page view for each page and a lead event, which names the form, when you send one. Nothing loads until you accept marketing cookies. The [cookie policy](https://www.aigentcy.com/cookie-policy/) lists what is stored, for how long, and what happens when you withdraw. Following an external link opens the destination service, whose own privacy policy applies. The assistant links include a generic prompt and the public site address, not your form entries. ## 7\. Data retention Form submissions are deleted from the website's database seven days after they arrive; an hourly job removes them. The notification email in our business inbox is kept for as long as we need it to respond to you, follow up on your enquiry, meet our legal obligations and resolve disputes. Our hosting provider keeps its own operational logs to run and secure its network. ## 8\. Your data protection rights Under the GDPR, you have the right to: - access the personal information we hold about you; - ask us to correct inaccurate or incomplete information; - ask us to erase your personal information; - restrict or object to our processing of your information; - ask for your information in a portable format; and - withdraw your consent at any time, where processing is based on consent. To exercise any of these rights, email [info@aigentcy.com](mailto:info@aigentcy.com). If you have the reference shown after you sent a form, include it, but do not send sensitive information. You also have the right to lodge a complaint with the Information and Data Protection Commissioner (IDPC) in Malta. ## 9\. Data security We use appropriate technical and organisational measures to protect your information against unauthorised access, loss or misuse, including encrypted connections, bot checks and limits on repeated submissions. No method of transmission over the internet is completely secure, so we cannot guarantee absolute security. ## 10\. Changes to this policy We may update this privacy policy from time to time. Changes are posted on this page with a new "Last updated" date, and significant changes are communicated where appropriate. ## 11\. Contact us For questions about this privacy policy or your information, email [info@aigentcy.com](mailto:info@aigentcy.com). --- # Know what your AI can do, and who is accountable. Turn your AI policies into controls people can use. We connect ownership, permissions, evaluation and reporting to the systems your teams run every day. [Discuss your project](https://www.aigentcy.com/contact/) 1. AI activity 2. Permissions and approval 3. Evidence for review ## Make the policy part of the process. Your teams need to know which AI systems are in use, what they can access and who answers for their decisions. We help put that responsibility into the workflow and make the evidence available for review. ### Map the systems, owners and risks Start with an AI inventory, data flows and risk assessment. Vendor due diligence and regulatory mapping, including the EU AI Act and ISO 42001 where applicable, help your team identify the work to address with its qualified advisers. ### Put responsibilities into the workflow Responsible AI policies need named owners and clear limits. We implement permissions, evaluation and human approval around the actual use case, with audit trails and the context people need to examine an output or decision. ### Give oversight something to work with Board and operational reporting should draw from recorded usage, costs, changes and incidents. We build the reporting and review paths so your team can investigate what happened and decide what needs to change. ### What you have at handover Controls and evidence your technology, operations and risk teams can use together. Legal conclusions and certification stay with qualified advisers. ## Where this shows up in the work - Map AI systems, owners and data flows - Define permissions and approval boundaries - Evaluate outputs against agreed examples - Track usage, incidents and changes ### Give engineers context before they change a system A queryable map of services and dependencies gives engineers and their assistants scoped context for planning and reviewing changes. The case study follows the code-context layer: what engineers can retrieve, how they inspect dependencies and where review stays with a person. [Read the case study : Shared code knowledge for an engineering team](https://www.aigentcy.com/case-studies/agentic-second-brain/) ## When this is a good fit AI is already being used across your team, but ownership, access or oversight is inconsistent. ## Before you build A document-only exercise will not tell you who accessed a model or approved its output. Implementation work is most useful when you need those controls to operate in the actual workflow. ## Which AI system or workflow needs attention? Tell us what it needs to do, which systems it touches and what is holding it back. We'll work through the implementation with you. [Discuss your AI project](https://www.aigentcy.com/contact/) --- # From a repeated task to a working system. Build the workflow, connect the knowledge and put the right controls around it. We scope the work against the problem you need to solve. Our services ## Three pillars of enterprise AI. Governance, private models and automation. Each service stands on its own, and the three fit together when a programme needs all of them. [ ## AI governance Governance frameworks, risk management programmes and audit-ready compliance infrastructure for regulated AI deployments. Practical AI governance: inventory, permissions, evaluation, spend attribution and review controls built into day-to-day operations. See the service](https://www.aigentcy.com/services/ai-governance/)[ ## Private AI models Fine-tune and deploy open-source large language models inside your own infrastructure, so your data never leaves your environment. Private AI deployment and knowledge systems shaped around your access rules, model quality requirements and operating costs. See the service](https://www.aigentcy.com/services/private-ai/)[ ## Process automation Map, optimise and automate manual business processes with AI agents, RPA and intelligent document processing, and cut cost and error rates. AI workflow automation for support, HR, sales and procurement. Connect your existing tools, keep approvals with your team and track what each workflow does. See the service](https://www.aigentcy.com/services/process-automation/) ## Let's build your AI future together. [Get started](https://www.aigentcy.com/contact/) [Call +356 7990 2911](tel:+35679902911) --- # Put AI to work within your data boundaries. Give your team AI that can work with the information they are allowed to use. We build private AI applications around your data, access rules and deployment requirements. [Discuss your project](https://www.aigentcy.com/contact/) 1. Approved sources 2. Controlled access 3. Answers with context ## Useful answers start with the right access. An internal knowledge assistant needs more than a model. It needs current sources, permission-aware retrieval, a way to check answers and someone responsible for operating it. ### Bring the right knowledge into reach Connect proprietary knowledge through retrieval-augmented generation (RAG), with access rules that follow the user and the source. Fine-tuning is an option for a defined task, not a substitute for keeping the underlying knowledge current. ### Choose where the model and data run Compare on-premise, private cloud and managed deployment against model quality, operating cost and data sovereignty requirements. We document data flows and work with your advisers on applicable requirements, including GDPR or HIPAA where relevant. Hosting location alone does not establish compliance. ### Evaluate, maintain and update Test representative questions, failure cases and access boundaries before rollout. Model evaluation and red-teaming inform the release decision. Ongoing maintenance covers source updates, model changes, usage records and operating costs. ### What you have at handover An evaluated AI application with documented data flows, permissions and operating responsibilities. ## Where this shows up in the work - Connect approved knowledge sources - Enforce user and service access boundaries - Compare models on representative tasks - Record model usage, errors and operating costs ### Shared knowledge for an engineering team A queryable map of services and dependencies gives engineers and their assistants scoped context for planning and reviewing changes. Explore the retrieval and review workflow, including where engineers check retrieved context against current code. [Read the case study : Shared code knowledge for an engineering team](https://www.aigentcy.com/case-studies/agentic-second-brain/) ## When this is a good fit You have a concrete internal use case and requirements that a general-purpose chat account cannot meet. ## Before you build Self-hosting is a trade-off, not a privacy guarantee by itself. We compare managed and private options against your requirements before committing to infrastructure. ## Which AI system or workflow needs attention? Tell us what it needs to do, which systems it touches and what is holding it back. We'll work through the implementation with you. [Discuss your AI project](https://www.aigentcy.com/contact/) --- # Automate the work between your systems. Connect the inboxes, spreadsheets and business tools your team works between. We build automations that prepare the work, handle routine steps and bring exceptions back to a person. [Discuss your project](https://www.aigentcy.com/contact/) 1. Work arrives 2. Rules and review 3. Systems updated ## Less copying and chasing. More work completed. Start with a process your team repeats, not a model you want to use. We work through the handoffs, decide what can run on rules and test where AI is useful. ### Find the steps worth automating Process mapping makes the handoffs visible: where information arrives, who copies it, who checks it and where it goes next. We agree what to measure before building, from time spent per task to rework and exceptions. ### Connect the process, including approvals Document processing extracts the information a workflow needs. Rules, RPA and AI agents connect it to your ERP, CRM and other tools. Approval steps keep decisions such as sending a reply or placing an order with the right person. ### Keep it working when something changes A missing field or unavailable system needs a defined response. We build exception handling, logs and a route back to the team, then measure the workflow against the agreed baseline and improve it as the process changes. ### What you have at handover A working integration with an owner, exception handling, logs and an agreed way to measure its value. ## Where this shows up in the work - Capture and qualify enquiries in your CRM - Triage support tickets and draft replies for review - Schedule HR reports and approval reminders - Match purchase orders, deliveries and invoices ### From a new ticket to a reply ready for review Incoming tickets are categorised and routed, with suggested replies drawn from the team's help documents. Agents review and send. The support workflow prepares the work. The agent decides what reaches the customer. [Read the case study : Support triage with replies ready for review](https://www.aigentcy.com/case-studies/customer-support-automation/) ## When this is a good fit You have a repeated process, access to the underlying systems and someone who can approve how it should work. ## Before you build If a built-in feature or a simple rule solves the problem, use it. Custom automation earns its place when the workflow crosses systems or needs to interpret documents and messages. ## Which AI system or workflow needs attention? Tell us what it needs to do, which systems it touches and what is holding it back. We'll work through the implementation with you. [Discuss your AI project](https://www.aigentcy.com/contact/) --- Find a page # Sitemap Services, implementation examples and practical guides, grouped so you can find the next useful page. Other formats: [XML sitemap](https://www.aigentcy.com/sitemap.xml), [Markdown reading index](https://www.aigentcy.com/llms.txt), [complete site text](https://www.aigentcy.com/llms-full.txt). ## Services - [From a repeated task to a working system.](https://www.aigentcy.com/services/) - [Know what your AI can do, and who is accountable.](https://www.aigentcy.com/services/ai-governance/) - [Put AI to work within your data boundaries.](https://www.aigentcy.com/services/private-ai/) - [Automate the work between your systems.](https://www.aigentcy.com/services/process-automation/) ## Case studies - [The work behind the automation.](https://www.aigentcy.com/case-studies/) - [Shared code knowledge for an engineering team](https://www.aigentcy.com/case-studies/agentic-second-brain/) - [Support triage with replies ready for review](https://www.aigentcy.com/case-studies/customer-support-automation/) - [HR reporting and reminders in BambooHR](https://www.aigentcy.com/case-studies/hr-automation/) - [Lead qualification and follow-up in Odoo](https://www.aigentcy.com/case-studies/odoo-lead-generation-automation/) - [Purchase orders and invoice checks](https://www.aigentcy.com/case-studies/wholesale-procurement-automation/) ## Guides - [Insights](https://www.aigentcy.com/blog/) - [AI content quality at volume: expertise in, drafts out](https://www.aigentcy.com/blog/ai-generated-content-quality/) - [AI governance](https://www.aigentcy.com/blog/category/ai-governance/) - [Private AI](https://www.aigentcy.com/blog/category/private-ai/) - [Process automation](https://www.aigentcy.com/blog/category/process-automation/) - [AI cost management: what an accepted result costs](https://www.aigentcy.com/blog/enterprise-ai-cost-control/) - [Enterprise AI enablement: governed access for the whole company](https://www.aigentcy.com/blog/enterprise-ai-enablement/) - [An AI governance framework your team can operate](https://www.aigentcy.com/blog/enterprise-ai-governance-framework-guide/) - [Enterprise AI in Slack: one assistant for company knowledge](https://www.aigentcy.com/blog/enterprise-ai-in-slack/) - [Multi-brand service desk automation: one desk for several customers](https://www.aigentcy.com/blog/multi-brand-service-desk-automation/) - [Native AI assistants for business software: guide first, then act](https://www.aigentcy.com/blog/native-ai-assistants-for-business-software/) - [Automated resolution rate: measuring support AI by outcomes](https://www.aigentcy.com/blog/support-ai-resolution-metrics/) - [Technical SEO and AI search optimization: turn visibility into qualified demand](https://www.aigentcy.com/blog/technical-seo-and-ai-search/) ## Tools - [A starting point for AI oversight.](https://www.aigentcy.com/tools/) - [AI compliance policy generator](https://www.aigentcy.com/tools/ai-compliance-policy-generator/) - [EU AI Act readiness quiz](https://www.aigentcy.com/tools/eu-ai-act-readiness-quiz/) ## Company and resources - [Deploy AI with governance, privacy & control.](https://www.aigentcy.com/) - [We build around how your team works.](https://www.aigentcy.com/about/) - [About Aigentcy](https://www.aigentcy.com/ai-summary/) - [Which workflow needs attention?](https://www.aigentcy.com/contact/) - [Cookie policy](https://www.aigentcy.com/cookie-policy/) - [Before you automate.](https://www.aigentcy.com/faq/) - [Privacy policy](https://www.aigentcy.com/privacy-policy/) - [Sitemap](https://www.aigentcy.com/sitemap/) - [Terms & conditions](https://www.aigentcy.com/terms-and-conditions/) - [Tools disclaimer](https://www.aigentcy.com/tools-disclaimer/) --- # Terms & conditions **Last updated:** 6 July 2026 These Terms & Conditions (“Terms”) govern your access to and use of the Aigentcy website at [https://www.aigentcy.com](https://www.aigentcy.com) and any content, functionality and services offered on or through it (collectively, the “Services”). By using our Services, you accept and agree to be bound by these Terms. If you do not agree, please do not use the Services. ## 1\. Acceptance of terms By accessing or using the Services, you confirm that you accept these Terms and that you agree to comply with them. These Terms apply to all visitors, users and others who access the Services. ## 2\. Changes to these terms We may revise these Terms at any time. Any changes take effect as soon as they are posted on this page. Your continued use of the Services after changes are posted constitutes your acceptance of the revised Terms, so please review this page periodically. ## 3\. Your responsibilities When you use our Services, or where you register for an account or submit an enquiry, you agree to: - Provide accurate, current and complete information where requested. - Keep any login credentials or account details secure and confidential. - Notify us promptly of any unauthorised use of your account or any other breach of security. - Accept responsibility for all activity that takes place under your account. ## 4\. Privacy Your use of the Services is also governed by our [Privacy Policy](https://www.aigentcy.com/privacy-policy/) and [Cookie Policy](https://www.aigentcy.com/cookie-policy/), which explain how we collect, use and protect information about you. By using our Services, you consent to that processing. ## 5\. Intellectual property All content on the Site — including text, graphics, logos, icons, images, audio, downloads, software and the Aigentcy name and branding — is owned by Aigentcy or its licensors and is protected by copyright, trademark and other intellectual-property laws. You may not copy, reproduce, republish or exploit any of this content without our prior written permission, except as expressly permitted by these Terms. ## 6\. Content you provide If you submit any content to us (for example through a form, enquiry or communication), you grant Aigentcy a non-exclusive, worldwide, royalty-free and sublicensable right to use, reproduce and process that content for the purpose of providing and improving the Services. You are responsible for ensuring you have the right to share any content you submit. ## 7\. Third-party links The Services may contain links to third-party websites or resources that are not owned or controlled by Aigentcy. We have no control over, and accept no responsibility for, the content, policies or practices of any third-party sites. We encourage you to review the terms and privacy policies of any third-party sites you visit. ## 8\. Disclaimer of warranties The Services are provided on an “as is” and “as available” basis. To the fullest extent permitted by law, Aigentcy makes no warranties, express or implied, as to the accuracy, reliability or completeness of any content or information provided through the Services, and does not guarantee that the Services will be uninterrupted, secure or error-free. Use of our free online tools, including the EU AI Act Readiness Quiz and the AI Compliance Policy Generator, is additionally governed by our [Tools Disclaimer](https://www.aigentcy.com/tools-disclaimer/), which forms part of these terms in respect of those tools. ## 9\. Limitation of liability To the fullest extent permitted by applicable law, Aigentcy will not be liable for any indirect, incidental, special, consequential or punitive damages — including loss of profits, data, use or goodwill — arising out of or relating to your access to or use of (or inability to use) the Services. ## 10\. Indemnification You agree to defend, indemnify and hold harmless Aigentcy, its affiliates, and their respective officers, directors, employees and agents from any claims, liabilities, damages, losses, costs or expenses (including reasonable legal fees) arising out of or relating to your breach of these Terms or your misuse of the Services. ## 11\. Termination We may suspend or terminate your access to the Services at any time, without prior notice or liability, for any reason, including if you breach these Terms. Upon termination, your right to use the Services will cease immediately. ## 12\. Governing law These Terms, and any dispute or claim arising out of or in connection with them, are governed by and construed in accordance with the laws of Malta, without regard to its conflict-of-law principles. The courts of Malta will have exclusive jurisdiction over any such dispute. ## 13\. Severability If any provision of these Terms is found to be invalid or unenforceable, the remaining provisions will continue in full force and effect, and the invalid provision will be interpreted so as to best reflect the original intent of the parties. ## 14\. Entire agreement These Terms, together with our Privacy Policy and Cookie Policy, constitute the entire agreement between you and Aigentcy regarding your use of the Services and supersede any prior agreements relating to the Services. ## 15\. Contact us If you have any questions about these Terms, please contact us at [info@aigentcy.com](mailto:info@aigentcy.com). --- # Tools disclaimer **Last updated:** 28 July 2026 This Tools Disclaimer (the “Disclaimer”) governs your use of the free online tools made available by Aigentcy (“we”, “us” or “our”) on [https://www.aigentcy.com](https://www.aigentcy.com), including the [EU AI Act Readiness Quiz](https://www.aigentcy.com/tools/eu-ai-act-readiness-quiz/) and the [AI Compliance Policy Generator](https://www.aigentcy.com/tools/ai-compliance-policy-generator/) (together, the “Tools”). It applies in addition to our [Terms & Conditions](https://www.aigentcy.com/terms-and-conditions/) and [Privacy Policy](https://www.aigentcy.com/privacy-policy/). By using the Tools, you accept this Disclaimer. ## 1\. Not legal advice The Tools, and any output they produce — including quiz scores, readiness bands, recommendations and generated policy documents — are provided for **general informational purposes only**. They do not constitute legal, regulatory, compliance or other professional advice, and they are not a substitute for advice from qualified legal counsel familiar with your specific circumstances. Use of the Tools does not create any professional-client, advisory or fiduciary relationship between you and Aigentcy. ## 2\. Nature of the output - The **EU AI Act Readiness Quiz** produces an indicative self-assessment based solely on the answers you provide. It is not an audit, a compliance determination, or a representation of your legal position under Regulation (EU) 2024/1689 or any other law. - The **AI Compliance Policy Generator** assembles a generic draft template from a predefined library of clauses based on the answers you provide. The output is a **starting point only**. It must be reviewed, adapted and approved by qualified legal counsel before being adopted or relied upon, and it may not reflect the most recent legal or regulatory developments or the specific requirements of your sector, jurisdiction or circumstances. ## 3\. No warranty The Tools and their output are provided **“as is” and “as available”**, without warranty of any kind, whether express or implied, including but not limited to warranties of accuracy, completeness, currency, merchantability, fitness for a particular purpose or non-infringement. We do not warrant that the Tools will be uninterrupted, error-free or that their output will meet your requirements or achieve compliance with any law or regulation. ## 4\. Limitation of liability To the maximum extent permitted by applicable law, Aigentcy, its directors, employees and agents shall not be liable for any loss or damage of any kind — whether direct, indirect, incidental, consequential or special, and including without limitation loss of profits, business interruption, regulatory fines or penalties, or professional fees — arising out of or in connection with your use of, or reliance on, the Tools or their output, even if we have been advised of the possibility of such loss. You use the Tools, and act or refrain from acting on their output, entirely at your own risk. ## 5\. Your responsibilities - You are responsible for the accuracy of the information you enter into the Tools. - You are responsible for obtaining independent professional advice before adopting any generated document or acting on any assessment result. - You remain solely responsible for your organisation’s compliance with the EU AI Act and all other applicable laws and regulations. ## 6\. Intellectual property You may use, adapt and reproduce documents generated by the Tools for your own internal business purposes. The Tools themselves, including their underlying question sets and clause libraries, remain the property of Aigentcy and may not be resold, republished or offered as a service to third parties without our prior written consent. ## 7\. Data you provide When you use the Tools we collect the email address you provide and your responses, as described in our [Privacy Policy](https://www.aigentcy.com/privacy-policy/). Generated policy documents are assembled in your browser and are not stored on our servers. ## 8\. Changes to this disclaimer We may update this Disclaimer from time to time. Any changes will be posted on this page with an updated “Last updated” date. ## 9\. Contact us If you have any questions about this Disclaimer, please contact us at [info@aigentcy.com](mailto:info@aigentcy.com). --- # AI compliance policy generator Free tool ## Draft your AI compliance policy. Answer eight questions to prepare an editable AI policy starting point. It covers governance, risk assessment, transparency, human oversight and vendor management. Download the draft and have qualified legal counsel adapt it to your organisation before use. **This interactive tool requires JavaScript.** It generates a draft AI compliance policy covering: purpose and scope; definitions; governance and accountability; AI system inventory and risk classification; prohibited uses; data governance; transparency and disclosure; human oversight; general-purpose AI models; vendor management; incident reporting; training and AI literacy; and review and maintenance. Prefer a hands-on approach? Email us at [info@aigentcy.com](mailto:info@aigentcy.com) or [get in touch](https://www.aigentcy.com/contact/) and we’ll help you build your AI governance framework. Generated documents are draft templates only — not legal advice. Review with qualified counsel before adoption. See our [Tools Disclaimer](https://www.aigentcy.com/tools-disclaimer/). --- # EU AI Act readiness quiz Free tool ## How ready are you for the EU AI Act? Answer 14 questions about AI ownership, risk assessment, controls and training. The result identifies areas to discuss with your team; it does not classify systems or determine compliance. Check the [European Commission’s current AI Act guidance](https://digital-strategy.ec.europa.eu/en/policies/regulatory-framework-ai) for applicable requirements and timelines. **This interactive quiz requires JavaScript.** It assesses your readiness across these areas: AI system inventory; provider/deployer role awareness; system-level scoping (intended purpose, affected persons, profiling); prohibited practices (Article 5); risk classification under both Article 6 routes (Annex III and Annex I product/safety-component); governance and accountability; data governance (Article 10); transparency disclosures (Article 50); human oversight (Article 14); vendor management; general-purpose AI tracking; AI literacy training (Article 4); and technical documentation (Article 11/Annex IV) with incident reporting. Prefer to talk it through? Email us at [info@aigentcy.com](mailto:info@aigentcy.com) or [get in touch](https://www.aigentcy.com/contact/) for a guided readiness assessment. Indicative self-assessment only — not legal advice or a compliance determination. See our [Tools Disclaimer](https://www.aigentcy.com/tools-disclaimer/). --- # A starting point for AI oversight. Use a structured questionnaire to identify discussion points, or prepare a policy draft for review. These tools do not certify compliance or replace legal advice. Free tools ## Practical AI compliance tools. The EU AI Act is in force, with penalties of up to EUR 35m or 7% of global turnover. Use these free tools to find out where you stand and take a first concrete step towards a compliant AI governance framework. No cost, no obligation. [ ## EU AI Act readiness quiz How prepared is your organisation for the EU AI Act? Answer 14 quick questions and get an instant readiness score across governance, risk and classification, operational controls, and people and vendors. Updated for the Digital Omnibus timeline, with recommendations for every gap. 14 questions, about 3 minutes, instant score Take the quiz](https://www.aigentcy.com/tools/eu-ai-act-readiness-quiz/)[ ## AI compliance policy generator Need a written AI policy? Answer 8 short questions about your organisation and get a draft AI compliance policy aligned to the EU AI Act. Read it on screen or download it as a Word document to review with your legal counsel. 8 questions, tailored draft, Word download Build your policy](https://www.aigentcy.com/tools/ai-compliance-policy-generator/) These tools give you a fast, structured starting point. They produce drafts and indicators, not legal advice. See the [tools disclaimer](https://www.aigentcy.com/tools-disclaimer/). When you are ready to go further, our [AI governance service](https://www.aigentcy.com/services/ai-governance/) turns the gaps into an enterprise-grade compliance framework. ## Let's build your AI future together. [Get started](https://www.aigentcy.com/contact/) [Call +356 7990 2911](tel:+35679902911)