Several Assistants in One Account: Separating Shop, Support and Careers

Many businesses address more than one group on their website: customers before a purchase in the shop, customers after a purchase in the service area, job applicants on the careers page. Once an assistant is in place, the question arises whether one should answer for everyone or whether each group gets its own. The answer depends less on technology than on five characteristics: target group, topic scope, tone, handover route and tools. This article shows when one assistant is enough, when separate assistants in one account work better, which operator rules are maintained per assistant, what applies to the whole account and the mistake on which a split typically founders: the same content, maintained differently in two places.

Enlarge graphic

Labels in the illustration

• Account
• applies to all assistants
• Knowledge base
• Team and roles
• Plan and allowance
• One write path for actions
• Shop assistant
• Target group
• Customers before buying
• Tone
• Brief
• Hands over to
• Sales team
• Tools
• Product search, product cards
• Support assistant
• Target group
• Customers after buying
• Tone
• Detailed
• Hands over to
• Customer service
• Tools
• Create ticket, photo upload
• Careers assistant
• Target group
• Job applicants
• Tone
• Friendly
• Hands over to
• HR department
• Tools
• No tools that write
• One widget per page: shop pages load the shop assistant, the careers page loads the careers assistant.

One account, three assistants with their own rules

One account, several touchpoints

An account is the frame in which your team works: members and roles, the booked plan and the allowance for the month. An assistant is what the visitor sees: a chat window of its own with its own greeting, its own tone and its own rules. Several assistants can run side by side in one account, each with its own identifier through which the widget addresses it on your site. The question in this article is therefore not whether several assistants are technically possible, but when they pay off and when they cause more maintenance than they bring. Ideally the visitor does not notice the split at all: on whatever page they happen to be, they meet an assistant that suits their request and do not first have to work out whether they are in the right place.

This article deliberately leaves two related questions aside. When a visitor raises several requests in one message, it remains one conversation with one assistant; how to split it cleanly is described in the article on several requests in one conversation. And when a business has several branches, one assistant that first clarifies the location is often enough – the approach is set out in the article on several locations. This article is about groups of visitors who differ in purpose, tone and contact person.

When one assistant covers everything

A second assistant does not double the capability, it doubles the maintenance: another greeting, another rule list, another set of test questions before every change. That is why a single assistant is the sensible starting point. It is usually enough when the following conditions apply:

• Visitors ask about the same offering, even if they look at it from different angles.
• The same question gets the same answer for everyone, regardless of the page on which it is asked.
• Handovers go to the same team or can be assigned to a team by topic.
• One tone suits everyone: whoever is addressed in a friendly way in the shop does not feel out of place in the service area.
• The tools the assistant may use are the same for all visitors.

Five reasons for separate assistants

The split follows conversations, not departments. The yardstick is simple: would the same question need a different answer, a different tone or a different contact person depending on the group of visitors? Then a shared assistant becomes a switch that has to guess with every message who it is dealing with. The table shows the five characteristics on which the decision can be based.

One characteristic alone rarely decides the matter. If only the tone differs, an adjusted greeting or a rule in the existing assistant is often enough. If several characteristics come together – a different target group, a different handover route, different tools – a separate assistant is usually the clearer solution. It can be changed, tested and analysed on its own, without a rule meant for applicants accidentally affecting a conversation about a return. An example makes the difference tangible: the question "How long does it take?" means the delivery time in the shop, the processing of a complaint in the service area and the response to an application on the careers page. A shared assistant first has to infer that meaning from the context; an assistant per area knows it from the outset. The split has one limit: in XICBOT, all assistants in an account share the knowledge base with its sources, Q&A pairs and text blocks. A separate assistant therefore does not keep content away from a group; topic boundary and taboo list set out in its instruction what it talks about. Content that a group is not meant to see does not belong in the knowledge base.

Shop, support, careers: three profiles compared

The three areas from the title are a common example because they differ in almost every characteristic. The tiles show what the profiles can look like. They are starting points, not specifications; which questions your visitors actually ask only becomes clear in operation.

How an assistant for sales works is described on the page about the shop assistant. The careers page deserves a closer look of its own, because different questions are asked there and different limits apply; the article on candidate questions on the careers page covers this in detail.

Operator rules per assistant

Separate assistants are only truly separate if their rules can be maintained separately. In XICBOT, the following are set per assistant: the role, which describes what the assistant is there for and how it comes across; the tone, a field with exactly one of four values (factual, friendly, brief or detailed); the topic boundary; a taboo list of topics and promises the assistant excludes; maintained facts such as responsibilities or opening hours for enquiries; and the escalation route, that is, where a conversation is handed over to. Nuances such as "patient" or "free of jargon" belong in the role, not in the tone. Every change to these settings creates a new version of the assistant concerned; the others remain untouched. The greeting comes on top: greeting text, invitation bubble and its delay can likewise be set per assistant. The first sentence is thus the first sign of which area the visitor is talking to – a careers assistant that opens with a question about open positions needs no explanation of what it is there for.

The taboo list and the maintained facts have an upper limit per assistant so that the instruction does not grow without bound; a list that is too long cannot be saved as a version. That is a useful brake: anyone who notices that an assistant needs more facts than the list can hold is usually looking at content that belongs in the knowledge base rather than in the rules. What belongs in an assistant's instruction and what does not is described in the article on the system instruction and its boundaries.

The careers page: a different purpose, different data

On the careers page, more changes than the tone. People writing there sometimes give their name, their qualifications or a possible start date – details connected with an application, not with a purchase. The General Data Protection Regulation ties the processing of personal data to the purpose for which it was collected:

No obligation to handle applicant conversations in a separate assistant follows from this. A separate assistant does, however, make the purpose visible in day-to-day operation: conversations on the careers page carry its identifier, their handovers go to HR rather than to sales, and an analysis narrowed down to the shop assistant does not include them. Where a record of processing activities is kept, this assignment helps. Article 30(1) GDPR describes it as "a record of processing activities under its responsibility" and lists among its contents "the purposes of the processing". One assistant per purpose can be described there more clearly than one that serves purchases, service and applications at the same time. The careers assistant's rules follow the purpose as well: it explains the process and the published conditions, is not meant to ask for details that are not needed for an initial answer or to assess suitability. Anything beyond that belongs in the application procedure itself and therefore with HR.

What applies per assistant and what to the whole account

Separate assistants share more than the separate chat windows suggest. That is intentional: where security and the contractual frame are concerned, there should be no exception per assistant. The knowledge base belongs to the account as well: all assistants search the same sources, Q&A pairs and text blocks. The table separates the two.

The most important shared part is the write path. Which tools an assistant may use is enabled per assistant; a careers assistant does not get product search just because the shop assistant has it. A write action, however, is executed in the same place for every assistant: all write actions pass through exactly one execution point, which first checks role, approval and tenant membership, and no tool writes around it. An additional assistant therefore opens no route around this check; which systems it reaches depends on the tools you enable for it. How actions are enabled and secured is described on the page about tool control.

On the website, the assistants are separated by page. Each page loads one widget; a second snippet with a different key has no effect. The shop pages therefore embed the shop assistant, the service area the support assistant and the careers page the careers assistant. If the careers page sits on a domain of its own, that domain is entered as a permitted domain for the careers assistant; on a page that is not listed there, its widget does not load. How embedding works with an assistant's public key is explained on the integration page.

Plan limits and allowance

The number of assistants is limited per plan, as is the number of sources, documents and knowledge base sections. The pricing page states that these limits exist; the administration shows the limits of your plan as a table under Billing. Anything above the limit is not created silently: a further assistant beyond the limit is refused, and the refusal names the limit that was reached. The monthly allowance belongs to the plan and therefore to the account; all assistants book their answers against the same allowance, and the administration shows consumption next to the list of assistants. An additional assistant therefore brings no allowance of its own; it shares the existing one.

Analytics per assistant

One advantage of separate assistants only shows in the analytics. Questions from applicants no longer distort the shop assistant's figures, as far as those can be narrowed down to one assistant, and a rising number of open questions can be assigned to the area in which it arises. XICBOT's conversation analytics, which comes with the Pro package, can be narrowed down to a single assistant for this. The retrieval quality of the knowledge base, by contrast, is reported for the whole account; a filter on one assistant does not apply there. What is worth comparing per assistant:

• Open questions: which questions remained without a reliable answer, and in which assistant?
• Handovers per topic: if the share rises in one topic, a source is usually missing there.
• Misdirected conversations: order questions on the careers page or application questions in the shop show that a link between the areas is missing.
• Drop-offs: if visitors to one assistant drop off noticeably often after long answers, its tone, for instance a switch from "detailed" to "brief", is a candidate for a new version.
• Trend rather than ranking: a careers assistant usually holds fewer conversations than a shop assistant. Comparing one assistant with itself before and after a change is therefore more telling than comparing two assistants.

Typical mistakes: one piece of content, two truths

A typical mistake after a split is unspectacular. A fact that applies to all areas – when customer service can be reached, the return period, the address for returns – is entered as a maintained fact in two assistants. When it changes, it is updated in one assistant and forgotten in the other. From that day on, the business gives two answers to the same question, depending on the page on which it is asked. For the visitor this is not a detail: they can put both answers side by side.

Against the other mistakes, one responsible person per assistant and a shared maintenance date help. Who checks which content when can be set out as described in the article on the knowledge base maintenance process; who prepares changes and who approves them is governed by a role model like the one in the article on roles and approvals. If the split is too fine, the reverse step helps: assign areas back to one assistant and reflect the difference through greeting and rules. And against copied rules, a deliberate start helps: a new assistant is created with name, template and language, and only what genuinely applies to the new area is taken over from an existing assistant – not the entire rule list in the hope of thinning it out later.

Five steps to a split

• Name the visitor groups: who writes on which pages, and with what aim?
• Check the five characteristics: target group, topic scope, tone, handover route, tools. Split where several of them differ.
• Collect shared facts and maintain them in exactly one place before the second assistant is created.
• Set operator rules, escalation route and enabled tools per assistant, and name a responsible person.
• Prepare test questions per assistant, including ones that belong to another area, and check the answers before going live.

The last step deserves attention. Sooner or later a careers assistant will be asked about a delivery, and a shop assistant about an open position. It should then not guess but refer to the right area or hand over. These cross-questions belong in every assistant's test set, just like the questions from its own area. After every later change to an assistant, it is worth running its test set again; the test sets of the other assistants can rest as long as nothing has changed in the shared content. If a shared fact changes, all test sets belong in the run. Whether one assistant is enough for your business or a split makes sense can be assessed before setup on the basis of your pages and your visitors' questions.

Frequent questions