Virtual Assistant Development
One assistant your colleagues can ask about anything internal, answering from the policy that actually applies to them, raising the ticket when it cannot resolve something, and admitting plainly when it does not know.
Employees do not think in departments. They think about the thing they are trying to do: get the laptop replaced, book the leave, find out whether the expense is allowed, work out who approves this. Splitting that into an HR bot, an IT bot and a policy portal is an organisational artefact, and it is why internal assistants get abandoned.
Virtual assistant development is the building of a single internal assistant for employees that spans several domains such as HR, IT, finance and facilities: answering from the policies that apply to that person, performing permitted actions such as raising a ticket or booking leave, and routing what it cannot handle to the right team with context attached.
Why one assistant beats several
- People ask by problem, not by owner. One entry point removes the guessing about which system holds the answer.
- Questions cross domains. A new starter question touches HR, IT and facilities in one sentence, and three separate bots each answer a third of it.
- Coverage compounds. Every domain added makes the assistant more likely to be worth opening, which is what drives the habit that makes it useful.
- One permission model. Access and identity resolved once, consistently, rather than three times with three interpretations.
- One measurement. A single view of what people ask, what is unanswered and where the documentation is failing.
The counter-argument is scope, and it is a fair one. We manage it by launching with two or three domains covered properly and adding the rest on evidence, rather than launching with everything covered approximately.
How we build an internal assistant
Start where the volume is
Helpdesk tickets, HR queries and the questions that arrive in shared inboxes are analysed to find what people actually ask and which of those have a documented answer. The first release covers the top of that list across two or three domains, which is enough for the assistant to become a habit rather than a novelty.
Answer from the policy that applies to this person
Entitlements differ by country, contract, seniority and location, so a single correct answer rarely exists. The assistant resolves the person's context from your systems and answers accordingly, or states the condition explicitly when it cannot. The retrieval layer underneath is the same as the enterprise knowledge assistant, with permission filtering applied at query time.
Do the small things, not just describe them
Raise the ticket, book the leave, order the equipment, reset the access, start the onboarding request. Each is a scoped tool with validation and audit, following the discipline in tool and function-calling integration. An assistant that only explains the form is a search engine with a personality.
Meet people where they work
Slack, Teams or the intranet, whichever your colleagues already have open. A separate portal that requires a deliberate visit will lose to asking a colleague, every time, regardless of how good the answers are.
Report the gaps to the people who own them
Unanswered questions are routed to the domain owner as a coverage report, with volume attached, so improving documentation becomes a prioritised list rather than an ambition. This is usually the second-largest benefit of the whole programme.
Expect the first month to be uncomfortable
Within a fortnight the assistant will surface which policies contradict each other and which pages nobody has updated since a reorganisation. That is not the system failing; it is the system finding what was already costing your colleagues time quietly. Plan for owners to have capacity to fix it.
What it typically covers
| Domain | Answers | Actions |
|---|---|---|
| HR | Leave, pay dates, benefits, policy by country and contract | Book leave, update details, request a letter |
| IT | Access, software, device policy, how-to | Raise a ticket, request access, reset where permitted |
| Finance | Expenses, approval limits, supplier process | Submit a claim, check status |
| Facilities | Sites, desks, parking, access cards | Book a desk or room, raise a maintenance request |
| Onboarding | What happens when, who to contact | Trigger the standard requests for a new starter |
The actions column is what separates this from an internal search tool, and it is also where the permission and audit work concentrates.
How the engagement runs
Two or three domains covered properly first, then expansion driven by what people actually ask.
Question analysis and domain selection
Tickets and inbox queries analysed, domains chosen by volume and answerability, baseline query volume and resolution time captured.
Content and entitlement handling
Policy indexed with permission filtering, person context resolved from your systems, answers scored against real questions.
Actions and integrations
Scoped tools for tickets, requests and bookings, with validation, approval routing and audit.
Pilot in one business area
Live with a defined population, daily review of unanswered questions, gaps routed to domain owners.
Rollout and handover
Wider release with the coverage report running, plus handover of the evaluation set and expansion process.
What you receive
An assistant colleagues use by habit, and a live map of where your internal documentation fails.
Deployed assistant
Live in Slack, Teams or your intranet, integrated with your identity provider.
Entitlement-aware answers
Policy retrieval filtered by permission and resolved against the person's own context.
Action tools
Ticket raising, requests and bookings with validation, approval routing and audit.
Evaluation set
Real internal questions with agreed answers, including refusal cases, as a release gate.
Coverage reporting
Unanswered questions routed to domain owners with volume, tracked over time.
Usage baseline and impact
Query volume, resolution time and ticket deflection against the pre-launch baseline.
Is this the right engagement?
Worth being direct. Virtual Assistant Development is the wrong spend in some situations, and those are listed rather than buried.
Good fit if
- Internal teams answer the same questions repeatedly across HR, IT or finance.
- Policy documentation exists and owners will act on the gaps it exposes.
- Entitlements differ by country or contract and people get the wrong answer today.
- Your colleagues live in Slack or Teams.
- Ticket raising and simple requests can be reached through APIs.
Choose something else if
- The documentation does not exist. There is nothing to answer from.
- Nobody owns the content, so the gaps the assistant finds will sit unfixed.
- You need answering only, with no actions. That is the enterprise knowledge assistant.
- The requirement is customer-facing, which carries a different tone and risk profile.
Frequently asked questions
Marked up with FAQPage schema so these answers can surface directly in search results and inside AI assistant responses.
What is a virtual assistant in a workplace context?
A single internal assistant employees can ask about anything internal, which answers from the policy that applies to them, performs permitted actions such as raising a ticket or booking leave, and routes what it cannot handle to the right team with context attached.
How is it different from an enterprise knowledge assistant?
The knowledge assistant answers from documents. A virtual assistant also does things: raises the ticket, books the leave, requests the access. The retrieval layer is shared; the additional work is scoped action tools, permissions and audit.
How does it handle different policies for different countries or contracts?
It resolves the person's context from your systems and answers accordingly, rather than returning a generic policy. Where it cannot determine the context it states the condition explicitly instead of guessing, which is the behaviour that keeps HR from having to correct it.
Should we build one assistant or one per department?
One. People ask by problem, not by department, and questions frequently cross domains in a single sentence. We manage the scope risk by launching with two or three domains covered properly and expanding on evidence.
How do we know it is working?
We capture a baseline before launch, typically internal query volume, repeat question rate, ticket volume and time to resolution, then report the same measures after a quarter. Usage alone is a weak signal; the question is whether the queue in front of HR and IT got shorter.
Often paired with this
Most clients combine two or three engagements from the Conversational AI pillar. These are the ones that most often run immediately before or after.
AI Chatbot Development
A chatbot grounded in your own content, measured on resolution and satisfaction rather than on messages handled.
Read more →Conversational Design and CX Strategy
The design work that decides whether an assistant is used twice: scope, failure recovery, escalation and tone.
Read more →WhatsApp, Messenger and Slack Bots
Bots on the messaging platforms your customers already use, built around each platform's opt-in and window rules.
Read more →Is this the right engagement?
Tell us what you are trying to build. If a different service fits better, or if you do not need us at all, we will say so.