Office suites features that matter for everyday work

Feature lists in this category are inventories, and inventories are useless for choosing. Every suite has hundreds of functions and you will use perhaps thirty. The question is not how many exist but whether the specific capabilities your work depends on are present, and whether they behave properly on documents the size of yours.

So this page is a shortlist of the features that actually decide things, grouped by what they change, with a way to test each in about ten minutes.

What to take away

• Structure features decide whether long documents are maintainable. They are invisible in a demo and dominant in daily work.
• In spreadsheets, the features that matter are the ones that stop errors, not the ones that produce charts.
• Test the review mechanics with a real second person. Commenting is where collaboration either works or quietly does not.
• Accessibility tooling is worth checking even with no obligation to meet. It is also the fastest proxy for whether a document is properly structured.

Structure is the feature that pays off later

Everything below concerns whether a document is built or merely typed.

Named styles. Formatting applied by style can be changed everywhere at once. Formatting applied by selecting text cannot be changed at all without doing it again. A suite that makes styles awkward is a suite that guarantees direct formatting, and the cost lands two years later when the branding changes.

Automatic numbering that survives editing. Headings, clauses, figures, and tables should renumber when something is inserted in the middle. Test this by inserting a section at the top of a long document and watching what happens below.

Cross references that update. A reference to "section 4.2" that stays as text after 4.2 becomes 4.3 is a defect waiting to be published.

Generated contents, figures, and indexes. Check that they regenerate and that their links still work after an export.

Sections with independent layout. Different page orientation, headers, or numbering within one document. Whether this is supported decides whether a report with a wide sideways appendix is one file or three.

Ten minute test: take your longest real document, insert a new second level heading near the front, add a figure, and regenerate the contents. Then look at whether the numbering, the references, and the contents are all correct.

In spreadsheets, look for the error prevention

Function coverage matters and is rarely the differentiator. These are:

• Named ranges and structured tables, which turn unreadable references into something a second person can check.
• Data validation, restricting what a cell will accept. This is the cheapest error control available and it varies more between suites than anything else on this list.
• Formula auditing, meaning the ability to see what feeds a cell and what depends on it. Without it, inheriting somebody's model is archaeology.
• Protection at cell and sheet level, so the model can be used without being edited.
• External data connections, and specifically what happens when the source is unreachable or has moved.
• Links between files, which are the most fragile thing in any estate. Establish whether links are by location or by identifier, because location based links break the moment storage changes, which is the point at which a migration turns painful.
• Calculation behavior at size. How a large model recalculates, whether it does so automatically, and whether the interface remains usable while it does.

Ten minute test: open your largest genuine workbook, change one input near the bottom of the dependency chain, and time how long the whole thing takes to settle. Then break a link on purpose and see whether the failure is visible or silent. Silent is the answer that should worry you.

Review mechanics, tested with a real second person

Collaboration features are demonstrated with two windows on one screen, which proves nothing about how a review actually goes.

The mechanics worth checking:

• Comment threads. Whether replies stay attached to a thread, whether a thread can be resolved, and whether resolved threads remain findable afterward.
• Suggested changes versus direct edits. Whether a reviewer can propose rather than impose, and whether proposals can be accepted individually.
• Attribution. Whether it survives export, and whether it survives a round trip through another product.
• Simultaneous editing conflicts. What happens when two people change the same paragraph, and whether anyone is told.
• Version pinning. Whether a specific version can be marked and referred to later, which is the difference between "the approved version" and "whatever it says now".
• Offline edits arriving late. Someone works on a train and syncs at four o'clock. Find out what that does to changes made in the meantime.

Ten minute test: have a colleague comment and suggest changes on a document while you edit it, resolve half the threads, then export the file and open the export somewhere else. What survived tells you what your review process can rely on.

Accessibility tooling, which is also a structure check

Whether or not you have an obligation, this tooling is worth using, because it detects the structural problems that cause every other kind of failure. Where an obligation does apply, it is normally a purchasing requirement rather than something to remediate afterwards, which is the point of the guidance on buying accessible products and services.

Look for a checker that reports missing image descriptions, heading levels used out of order, tables without header rows, low contrast text, and reading order problems in slides. A document that passes these checks is almost always a document that converts cleanly, exports cleanly, and can be restyled later. A document that fails them is a document that was typed rather than built.

Ten minute test: run the checker over three real documents from different people in your organization. The results tell you as much about your templates and habits as about the software.

Automation, and what it costs to keep

Macros and scripts do not move between suites; they are written in different languages and would have to be rebuilt. That fact belongs in the evaluation before it belongs in the budget.

Ask three questions about each candidate. What language is automation written in, and who in your organization could maintain it? What can automation reach: only the document, or also storage, mail, and other systems? And who is allowed to install and run it, since an automation platform with no administrative control over what people install is an additional integration surface rather than a feature.

Add ins deserve the same treatment. Check what permissions one asks for, whether an administrator can restrict the catalog, and what happens when the vendor of an add in you depend on stops publishing it.

Anything that reaches outside the suite is an interface with its own maintenance, and treating it that way from the start is the point of published API and data standards: a connection nobody documented is a connection nobody can fix.

Which features to weigh, and how much

Group	Weigh heavily if	Safe to ignore if
Structure and references	You produce long or reused documents	Your output is short and disposable
Spreadsheet error control	Anyone makes decisions from a model	Spreadsheets are lists rather than calculations
Review mechanics	Documents pass through more than two people	Work is drafted and published by the same person
Accessibility tooling	Anything is published or sent outside	Nothing leaves the building, though it is still a useful check
Automation	A recurring process already depends on it	Nobody has written one in five years
Output fidelity	Documents are printed or sent in fixed form	Everything is read in a browser

Fill this in for your own work before you test anything, and the shortlist of what to test becomes short. The classification of your document work is the input to this table, and it is worth doing first.

Common questions

Are the assistive and generative features worth evaluating?

Try them, weight them lightly. They change quickly, they are appearing across the whole category, and a suite chosen for one of them will be judged on everything else for years afterward.

How many templates and fonts should we care about?

Almost none. Counts of included content are marketing. What matters is whether your own templates work properly and whether the fonts you actually use are available to everyone who opens your documents, which is a decision to make during rollout rather than a feature to shop for.

What about the difference between browser and installed versions?

Assume the browser version has fewer of the structure, automation, and auditing features described here, and test the specific ones you need rather than trusting a general answer. This is the most common gap between what was demonstrated and what people get.

We have no long documents or models. Does any of this matter?

Then most of it does not, and you should choose on cost, on what your people already know, and on how easily you could leave. Not every organization has a hard requirement here, and pretending otherwise is how a simple decision becomes a project.