Why does office suite setup depend on storage shape and defaults?

Applications install themselves. What takes real thought is the shape around them: where a document lives, who owns it, and what happens when its maker leaves.

Then decide which of the fifty defaults you accepted on the first afternoon will still govern the company in five years.

Nearly every complaint about a suite two years in traces back to a decision that was never made. Office suites setup is exactly that: a short list of decisions, and everything afterward follows from them. Below is the set worth making.

The short answer is that the storage backend, not the application, decides ownership, permissions, search, and recovery — and every platform applies your defaults at the moment a file is created, so the first save fixes the pattern for everything that follows. Microsoft 365, Google Workspace, Zoho Workplace, and a LibreOffice installation pointed at a shared file server all present the same fork: personal storage (OneDrive, Google Drive's My Drive, a local folder) or team storage (SharePoint document libraries and Teams channels, Google shared drives, a departmental file store). Files created in a Teams channel live in SharePoint, and a file in My Drive belongs to the individual who made it while one in a shared drive belongs to the organization. Choose the team-owned side as the default and most leaver, absence, and search problems never arise.

What to take away

Decide the shape of the storage first

The single most consequential decision is not which application people open. It is where the file goes when they press save. Decide the default format at the same time, and prefer an openly specified one: Office Open XML (OOXML), the default family in Microsoft 365, and the OpenDocument Format (ODF), the default in LibreOffice and supported by Google Workspace and Zoho Workplace. Both are published as ISO standards — OOXML through ECMA, ODF through OASIS — and PDF remains the safe format for anything sent outside the organization. The open standards principles set out why an openly specified format matters.

A format anyone can implement keeps your options open. One controlled by a single supplier turns a document estate into a reason to renew.

Personal space versus team space. Work that belongs to the organization should live in a space the organization owns: a SharePoint document library or a Teams channel in Microsoft 365, a shared drive in Google Workspace, a departmental file store behind LibreOffice. Personal space — OneDrive, My Drive, a folder on a laptop — is for drafts and for genuinely personal material. If your finance model, your contract templates, and your board papers live in individual accounts, then every departure becomes a recovery exercise and every absence becomes a blocker.

Ownership by function. Create the team spaces around the work rather than around the current organizational chart, because the chart changes more often than the work does. Fewer, broader spaces beat many narrow ones: people can find things in a wide space and will not go looking in a space they were never told about.

A default for new documents. Configure where a new file lands, and make the correct location the easy one. Any arrangement that requires people to move a file after making it will be followed for about two weeks.

A rule for what does not belong here at all. Very large media, system exports, database dumps, and personal photographs will all end up in a document store unless somebody says where else they go. Deciding this early keeps the file storage arrangement from becoming an accidental archive of everything.

Two of the decisions below are enforced on the machine rather than in the product. The device security guidance on policies and settings is a practical reference for deciding which settings are worth enforcing centrally rather than merely recommending.

Defaults that are hard to change later

Set these before the first users arrive.

The estate you build in week one

Three pieces of scaffolding are cheap now and nearly impossible to retrofit once thousands of documents exist.

Templates. Put the real ones in the template library on day one: the letter, the proposal, the invoice, the report, the slide deck. For example, a Client proposal template using named styles, standard fonts, and the agreed page size. If they are not there, people will duplicate whatever document they last worked on, and your formatting will descend from a single 2019 file forever.

Styles rather than direct formatting. A template built on named styles can be restyled later in an afternoon. A template built by selecting text and choosing a font cannot be restyled at all, and every document made from it inherits the problem. This is the highest return decision in the whole rollout and the least visible.

A naming and versioning convention. Two rules are enough: how a document is named, and that version history in the tool replaces version numbers in the filename. A worked example: 2026-04-12 Acme proposal. The date is the creation date, Acme is the client, and proposal is the document type. Version numbers do not appear in the filename; the tool records them. Write it down, put it in the template, and enforce it for a month. After that it maintains itself.

Also settle the small things that produce large inconsistencies: which fonts are standard, what the shared color values are, and the default page size and export format for outgoing documents.

Run a pilot with the hardest team

Pilot groups are usually volunteers, and volunteers like everything. Choose instead the team whose work is hardest: the one with the long structured reports, the complicated model, the documents that go to clients, the person with fifteen years of keyboard habits.

During the pilot, deliberately do the things that only fail under real conditions:

Fix what the pilot finds before the rollout rather than after, and set the conventions during the pilot rather than at the end. The round-trip checks belong in the same window.

Train the four topics that actually matter

General training on a suite is mostly wasted, because people already know how to type. Four topics repay the time:

Everything else people learn as they need it. Deliver these four in under an hour, at the point of the switch rather than a month before, and repeat them once after a fortnight when the questions have become real.

Write a decision record

The reason is not tidiness.

The next administrator will otherwise change a setting on purpose without knowing what it protected, the same failure pattern described in the administration guide: a configuration nobody can explain gets undone by somebody reasonable.

A record can be one page. Decision: new documents default to team-only sharing. Why: client work stays inside controlled spaces. Owner: the IT operations lead. Date: the day the setting changed.

Common questions

Should everyone move at once?

Move a hard pilot team first, then move whole teams rather than individuals. Splitting a team across two systems means every document they share crosses a format boundary daily, which is the worst possible way to experience a change.

What do we do with the existing documents?

Move what is live, leave the rest reachable in place, and set a date after which the old location is read only. Bulk converting a long document estate is rarely worth it, and the effort is better spent on the handful of documents that are actually reused. The general sequencing advice for moving an estate applies here too.

How much should we standardize?

Enough that documents leaving the organization look like they came from one place, and no more. Standards nobody can follow get ignored, and an ignored standard is worse than none because it stops anyone from proposing a real one.

When is the setup finished?

When a new starter can find the template, save the file in the right place, share it correctly, and recover it after a mistake, without asking anybody. Test that with an actual new starter, because it is the only honest measure available.