Your first week in UnitLook: what to set up first

A new tool rarely stalls because the tool is hard. It stalls because nobody is sure what to do first. One person starts with settings, another with importing old data, a third invites every colleague at once, and a week later you have half a system that nobody uses.

Here is the order we recommend. It is the same whether the organization has ten users or several hundred. The only difference is how many people are brought in at each step.

1. Organization and users

Start with people, because everything else depends on them. Add your colleagues and give each one a role: administrator, employee or client user.

Roles are not a formality. They decide what someone sees. A client account sees only the requests of its own company, and internal notes and data about other clients stay hidden without extra configuration. Employees see what their permissions allow, and for projects it is decided separately who may edit, delete and close.

If the organization is larger, group people into departments straight away. A department later serves for assigning requests, viewing workload and filtering reports.

2. Reference data

Reference data are the lists the forms draw their values from: request categories, billing types, project types, work types and clients. If a request does not have the category you expect, you add it here.

The advice is the same for every company size: start with few values. Six categories that people actually use beat thirty that nobody understands. A value you no longer want is not deleted but deactivated, so the history stays readable. We wrote more about it in ticket categories, priorities and statuses.

Billing types deserve special attention. Besides the name, they decide whether the work is billable, charged hourly, by quote, internally or under warranty, and whether the client can see it. Set that up early and there is no correcting billing afterwards.

3. The first project

A project gets a name, a client, deadlines and a team. The phases show up on the Gantt view, so after the first entry you can already see the whole schedule.

Do not try to enter every project you have on day one. Take one that is under way and has several people working on it. That is where you will quickest see what the system gives you and what still needs tuning.

4. The first real request

Not a test one, a real one from today’s work. The reason is practical: nobody wants to solve a test request, so the flow never gets tried to the end. A real one has an assignee, a deadline and somebody waiting for an answer.

Walk the whole path: assignment, comment, resolved, confirmation, closing. That shows who is on the move at every step and whether it matches what you had in mind.

5. Time logging

Agree on one simple rule: hours are logged on a request or project on the same day. Logging is done straight from the request, without going to another tool, so the context is not lost.

If the team has not tracked hours before, do not demand precision from everybody immediately. The first week is for getting used to it. Accuracy comes when people see their entries coming back to them through reports and overviews.

6. Absences

Everybody announces their own absences, and approval goes to the lead. An approved absence enters the monthly overview and the planning capacity for those days, so work is not planned onto a person nobody can give it to.

What can wait until week two

Not everything is needed at once. These can wait:

• Scheduling by time slots. Useful only once requests and time logs are flowing.
• Connecting email. Incoming mail can become a request, but only once manual entry becomes a nuisance.
• Detailed permissions per project. Until you see who really needs what.
• Project finances. Budget categories make sense when projects and hours are already in the system.

Where it usually goes wrong

Everybody at once. Inviting the whole organization on day one means everyone sees the first mistakes. It is better to start with one team and one project and then expand.

Settings without work. A week of editing reference data without a single real request produces perfect settings for work the team does not do.

No owner of the rollout. Somebody has to answer questions like “where does this go” and “who assigned this”. One person is enough, but there must be one.

What to read next

• Help desk implementation step by step, if the first goal is receiving requests.
• Time tracking for service companies, with an example of logging hours.
• Team capacity planning, once the basic flow is running.

We also describe individual parts on the pages ticketing system, project management, time tracking and leave management.

FAQ

How long does it take to roll out UnitLook?

The first round, from users to the first real request, can be done in a week. How long a full adaptation takes depends on the number of users and projects and on how much you want to cover at once.

Who should set up the system?

One person who knows how the team works, not necessarily IT. No programming is needed, it is set up through administration.

Do all modules have to be used right away?

No. The modules are connected, but you do not have to switch them all on at once. Most organizations start with requests or projects and add the rest once the basics are running.

What if we do not know which categories and billing types we need?

Start with a small list and add to it. Values can be deactivated without losing history, so the first decision is not final.

If you would like to walk through your own case, get in touch for a demo at unitlook.com. It takes 45 minutes and needs no preparation.