> For the complete documentation index, see [llms.txt](https://docs.artific.nl/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.artific.nl/en/for-administrators/first-week.md).

# Your first week

An ordered plan for setting the platform up. Following it roughly in this order will save you rework. Several steps depend on earlier ones.

## Day 1: Look around and set the frame

**Find your bearings.** Sign in and open each menu item you can see. The menu only shows what your rights allow, so this also tells you what you are able to configure.

**Set your brand identity.** [Brand identity settings](/en/for-administrators/organization/brand-identity.md): logo, primary colour, browser icon. It takes ten minutes and it is the first thing colleagues notice. Upload a Word reference document too, so exports come out looking like your documents.

**Check organisation settings.** [Organization settings](/en/for-administrators/organization/settings.md): which sign-in methods you allow, and whether people may register themselves.

{% hint style="warning" %}
Decide about data retention now, with whoever owns data policy. It is easier to set a retention period before there is a year of history than to explain afterwards why everything was deleted.
{% endhint %}

## Day 2: Decide who gets what

Do this before creating assistants. Access shapes everything else.

1. Write down the kinds of people you have: everyday users, builders, administrators, perhaps a support team.
2. Look at the ready-made roles under [Roles and rights](/en/for-administrators/access/roles.md). They cover most cases.
3. Create one [user group](/en/for-administrators/access/user-groups.md) per kind of person and attach the right role to each.
4. Set **Default user groups** so new users land somewhere sensible.

Keep it to three or four groups. You can always add more; untangling twenty overlapping ones is much harder.

## Day 3: Build one assistant properly

Resist building five. Build one that solves a real problem for a real team, and get it right.

1. Pick something narrow with an obvious owner: an HR policy assistant, a product support assistant.
2. [Create it](/en/for-administrators/assistants/creating-an-assistant.md).
3. Write the [instructions](/en/for-administrators/assistants/settings.md) carefully. This is where the quality comes from.
4. Create a [collection](/en/for-administrators/knowledge-base/collections.md), upload the documents, and build a [search tool](/en/for-administrators/knowledge-base/search-tools.md) over it.
5. Attach the search tool, and turn on **Show references**.
6. Test it in **Preview**. Ask the awkward questions, not just the easy ones.
7. Add [suggested questions](/en/for-administrators/assistants/suggested-questions.md).
8. Restrict it to the right user group, then publish it.

## Day 4: Make it usable and prove it works

**Add a tone of voice.** [Tone of voice](/en/for-administrators/tone-of-voice.md), generated from your own website, then edited. Apply it to the assistant.

**Set up quality control.** Write five or six [scenarios](/en/for-administrators/quality/scenarios.md) covering the questions that matter, including one the assistant should refuse. Turn on the daily schedule. This is the thing administrators skip and later wish they had not.

**Build two Toolbox elements.** Find a repetitive writing task and [package it](/en/for-administrators/toolbox/elements.md). For many colleagues this is the easiest entry point. No prompting skill required.

## Day 5: Introduce it

The most common cause of a failed rollout is that nobody told anyone.

1. **Give people something specific to try.** "Ask the HR assistant when you next have a leave question" works. "We now have AI" does not.
2. **Share the** [**user documentation**](/en/for-everyone/users.md)**.** It contains nothing admin-only, so it is safe to send to everyone.
3. **Say who to ask.** Tell people you are the administrator and how to reach you.
4. **Set expectations honestly.** Say what the assistant covers and what it does not, and ask people to tell you when an answer is wrong.

## Week 2 and after

**Read the** [**session logs**](/en/for-administrators/assistants/session-logs.md)**.** This is the single most valuable administrator habit. You will find questions you never anticipated, phrasing you did not expect, and gaps in your knowledge base.

**Act on what you find.** Turn common questions into suggested questions. Turn gaps into documents. Turn wrong answers into quality control scenarios.

**Check the** [**reports**](/en/for-administrators/reports/activity.md)**.** Watch active users rather than total sessions. Flat adoption after a launch means people are not finding it useful. Go and ask them why.

**Then expand.** Once one assistant is genuinely working, build the second. What you learned from the first will make it much better than it would have been.

## A checklist

* [ ] Brand identity set, Word reference document uploaded
* [ ] Sign-in methods and self-registration decided
* [ ] Data retention discussed and set
* [ ] User groups created, roles attached, default groups set
* [ ] One assistant built, tested and published
* [ ] Knowledge collection created and made searchable
* [ ] Tone of voice created and applied
* [ ] Quality control scenarios written, daily run enabled
* [ ] Two Toolbox elements published
* [ ] Colleagues told, with something concrete to try