Onboarding tips: getting productive with teamspace in three phases

Rolling out new software is more than a tech project, it’s a change project. The first few weeks decide whether the tool gets real use or quietly fades into the background. We’ve taken hundreds of consultancies, IT services firms and agencies through onboarding. Three phases have proven themselves consistently.

Phase 1: preparation (day 1 to 7)

Preparation is the most critical phase, and the one most often underestimated. The team that lands clean master data and clear role definitions here gains three weeks downstream.

What happens in this phase:

• Master data inventory. Which customers, projects, people and hourly rates do you maintain today? Where do they live? What is current, what is outdated?
• Define roles. Who has leadership access (everything), who is a project manager (scoped), who is staff (only their own hours)? Permissions are hard to change once people are working.
• Prepare imports. Clean master data before the first login, in Excel or CSV. Duplicates, ex-employees, expired contracts: out.
• Set conventions. How are projects named? How do you classify hour types? Which status values do you use? Your team will see these conventions thousands of times, so it pays to get them right.

Common mistake: teams skip preparation and jump straight to pilot or rollout. That catches up with you three weeks in, when the first reports arrive and no one knows whether the data is consistent.

Phase 2: pilot (week 2 to 4)

The pilot is your insurance policy against big surprises. Instead of rolling out to all 30 people at once, a small group (typically 4 to 8 people) starts working productively and surfaces everything that doesn’t fit.

Who belongs in the pilot?

• One person per role: leadership, project management, staff, office management. Each role experiences the software differently.
• At least one critical observer. Not a software enthusiast, but someone who looks at things closely. That feedback is gold.
• Someone from finance, if invoicing or DATEV export is part of the scope.

What you’re testing in the pilot:

1. Time logging in real life. Does mobile logging work in a meeting? Are the hour types intuitive?
2. The first real invoices. Are hours picked up correctly? Do the layouts work? Does ZUGFeRD/XRechnung output cleanly?
3. Reporting. Are the numbers what you expect? Where there are gaps, is it the data, the configuration, or a misunderstanding?

The pilot feeds adjustments back: hour types get sharpened, layouts tweaked, permissions fine-tuned. Then rollout begins.

Phase 3: rollout (week 4 to 6)

In the rollout, teamspace becomes the company standard. Three practical recommendations:

• Train in small groups. 6 to 10 people per session. Larger groups don’t get enough interaction. Several short sessions beat one long one.
• Train by role. Staff need around 60 minutes for time logging. Project managers need 90 minutes plus reporting training. Leadership needs 30 minutes on reporting plus a steering workshop.
• Set a cutover date. From when are hours logged only in teamspace? Parallel use with Excel is the single biggest cause of inconsistent data. Clear cutover, clear communication, clear consequences.

What comes after phase 3

After six weeks the team is productive. But onboarding isn’t done yet. The first 90 days decide your data quality:

• Weekly office hour. 30 minutes for any team member to ask questions. Low threshold, ideally on Microsoft Teams.
• First monthly report. Walk through the first full monthly report with leadership and project management. What looks plausible? What doesn’t?
• Customer success check-in. We reach out actively at 30, 60 and 90 days. What’s working? What isn’t? Which modules should come online next?

Things to avoid

Four no-gos have crystallised over the years:

1. Big bang without a pilot. No real-use learning, almost never works.
2. Running the legacy system in parallel. Excel and teamspace side by side equals inconsistent data, which equals lost trust.
3. Optional time logging. “Voluntary” hours are missing hours. The point of the tool evaporates.
4. No leadership buy-in. Leadership has to use the reports and demand them. Otherwise the platform decays into a glorified time tracker.

How much effort is realistic?

For a company of 30 people we typically budget:

• Preparation: 2 to 3 person-days of internal effort (master data, roles, conventions).
• Pilot: 4 to 6 person-days spread over 2 weeks.
• Rollout and training: 5 to 8 person-days, depending on module scope.
• Customer success support: bookable as a fixed-price package, typically 3 to 5 person-days.

Total: 2 to 3 person-weeks spread across a six-week timeline, for a system that will run the operational steering of your business for the next 5 to 10 years. A sound investment by any measure.

Where to start: a 30-minute call

Before you kick off internally, one step usually pays for itself ten times over: in a 15 to 30-minute requirements check we’ll look at whether teamspace fits your situation and which module sequence makes sense for your industry and size. Free, no commitment, no obligation to follow up.

Read more

• Help center — topic directory with links to every pillar page.
• Time tracking — typical first-module choice for consultancies.
• Project management — when steering takes priority.
• Security & compliance — ISO 27001, GDPR, DPA, hosting Frankfurt.
• Downloads — migration guides for Excel, Toggl, Jira, Asana.