Enterprise AI assistants that answer staff questions and complete routine tasks

A knowledge platform is the shared layer that indexes and retrieves company information, while an enterprise assistant is the staff-facing tool that uses it and also takes action. The assistant adds tool connectors for tickets, leave or CRM lookups, department-specific instructions, drafting from templates, file uploads and approval steps. Many organisations start with an assistant for one or two departments and later move its retrieval onto a shared platform, so other chatbots and agents can reuse the same index.

Yes, one platform can host several assistants, each with its own sources, instructions, tools and user groups. An HR assistant can answer from policies and the HR system while a sales assistant works from product sheets and the CRM, and neither can reach the other's data unless you allow it. Shared material such as company-wide policies is connected once and made available to every assistant that needs it.

It can take any action you expose to it as a scoped tool, typically routine requests such as raising an IT ticket, checking a leave balance, booking a meeting room, finding a customer record or starting a purchase request. Each tool runs with the employee's own permissions or a narrowly scoped service account. Actions that change records show a confirmation first, and sensitive ones can require a manager's approval before they complete.

Launch with two or three requests that staff make often, that have a clear owner and that the assistant can complete or answer from well-kept sources. Good candidates are logging IT tickets, answering leave and expense policy questions, and finding customer or product details before a meeting. Open-ended research and sensitive casework are better left until the basics are trusted. Usage in the first weeks then shows which sources and actions to add next, so the assistant grows where people are already asking.

Yes, it keeps each person's conversation history so they can return to a thread, but that history is private to them and is never used to answer someone else's question. Your administrators set how long history is kept, and staff can delete their own threads where policy allows, while audit logs are held separately under your security team's rules. Preferences such as default department, language or document style can be saved per user. Under the enterprise API terms we use, conversations are not used to train the underlying models.

Yes, staff can upload a contract, spreadsheet or report and ask questions about it within their own session. Uploaded files are processed for that conversation only, are not added to the shared index and are deleted after a retention period you set. Policy rules can block certain file types or scan uploads for personal and financial identifiers before any model sees them, and every upload is recorded in the audit log.

We combine permission-aware retrieval with input and output controls and full logging. The assistant can only reach what the user is already allowed to see, so it cannot become a route around access rules. Filters detect attempts to override instructions, requests for restricted data types and unusual volumes, and can block or flag them. Every conversation is logged against the user's identity, which discourages misuse and supports investigations.

Yes, routing rules decide which model handles each request based on the data involved, the task and the user's department. Requests touching personal, financial or client-confidential material can be restricted to Azure OpenAI in a chosen region or to an open model hosted in your own cloud account, while general drafting can use other providers. Identifiers can be redacted before a call is made, and the rules are versioned so security teams can review every change.

It can find and quote the relevant policy accurately, but it should not replace judgement on individual cases. Answers cite the exact clause, say plainly when the documents do not cover a question, and direct people to HR, legal or compliance for decisions about specific situations. Before these topics open to all staff, we test them against an evaluation set that the policy owners have reviewed and approved.

The user reports it with one click, and the full trace shows which sources were retrieved, which instructions applied and what the model produced. We classify the cause, usually an outdated document, a retrieval miss or an instruction gap, and fix it at that level rather than patching a single reply. The corrected question then joins the evaluation set, so every later change is tested against it before release.

The build is quoted as a fixed price after discovery, based mainly on the number of sources and tools to connect, your identity and policy requirements, the channels needed and how many departments are included. Monthly running costs come mainly from model usage, which rises with active users and question volume, plus hosting and the search index. We estimate them per department before each stage of rollout, and sending short lookups and classification steps to smaller models keeps the monthly figure down.

A pilot for one department with a few well-organised sources is often in staff hands within a few weeks of the agreed proposal. The biggest variable is usually how quickly source access and security approvals are granted, rather than the build itself. Wider rollout follows in phases, with each new department or system added after the previous one has been reviewed, and working software to see at every stage.