What to Do in the First Week With a New System

The first week with a new business system is usually spent configuring it: fields, stages, permissions, templates, integrations. It feels like the right work, and it produces something that looks finished.

It is also the week in which the decisions with the longest consequences get made, by the people with the least information about how the thing will actually be used. A few different priorities make a substantial difference later.

Do less configuration than feels right

The strongest instinct in week one is to model the business completely — every stage it might have, every field anyone might want, every rule that currently lives in someone's judgement.

This produces a system shaped by predictions rather than practice, and predictions made before anyone has used the tool are usually wrong in the same direction: too elaborate. Stages get added for situations that occur twice a year. Fields get created for information nobody ends up collecting. The result is a structure people navigate around rather than through.

The better approach is to configure the minimum that lets real work happen, then add only in response to something that actually got in the way. The rule that keeps this honest is not creating fields speculatively "in case it is useful later" [1] — every one of them has a cost paid by every person who ever looks at the screen.

Under-configuring is easy to fix. Over-configuring is not, because by the time it is obviously wrong there is data in the extra fields, and removing them means deciding what to do with it.

Import less than you have

The second instinct is to bring everything across. All the contacts, all the history, all the records from the last decade.

Two reasons to resist.

The first is that bad data is more expensive in a new system than an old one. In the previous tool, everyone knew which parts were unreliable — that knowledge was the compensation. Imported into somewhere new, the same records look authoritative, and the caveats that lived in people's heads do not come with them.

The second is that a large import makes the system feel used before anyone has used it. New records get lost among thousands of dormant ones, and the search results that should be helpful are mostly archaeology.

Importing the active subset and leaving the rest in an archive you can consult is almost always better. The archive is available if needed; in practice it is needed rarely, and the cleanliness is worth more.

Test the exit before you commit to the entrance

Week one is the ideal time to run the export, and almost nobody does, because leaving is the last thing on anyone's mind when a system is new.

That is exactly why it is the right moment. There is no pressure, no deadline, and no dispute. Run the export, open the file, and see whether it contains what you would need — records, relationships, history, attachments. Whatever you find is what will be available on a much worse day.

For us the answer is a JSON export of all your records [2]. Whatever the system, the point is to have seen the file rather than read a promise about it, while it is still easy to change your mind.

Decide who owns it

Systems without an owner drift. Not dramatically — nobody breaks them — but small decisions go unmade, questions go unanswered, and after a few months the configuration reflects a series of individual improvisations rather than an intention.

Someone should be responsible for it, and that responsibility should be explicit and modest: they decide what changes, they answer questions about how it is meant to work, and they notice when it stops being used properly. It is not a full-time job and it is not a committee.

The most common failure here is assuming ownership sits with whoever chose the software. Choosing and operating are different activities, and the person who ran the evaluation is frequently not the right person to run the system.

Find out how it fails

Every system will fail at something in the first months. The useful week-one question is how you will find out.

Two specific things are worth establishing. Where do error messages go, and does a human receive them? A system that logs failures into a file nobody reads has the same practical behaviour as one that hides them.

And what happens if something runs twice? Anything connected to another service faces the situation where a request succeeds but its confirmation is lost, making a retry sensible and a duplicate likely. The protection is idempotency — repeated identical requests having "the same effect... as the effect for a single such request" [3]. Asking early is much cheaper than discovering the answer through duplicate invoices.

Run one real thing through it, end to end

The most valuable hour of week one is spent taking a single genuine piece of work all the way through the system, from first contact to completion, without shortcuts.

Not a test record called "Test", and not a demonstration with prepared data. A real customer, a real quote, a real invoice, a real message — the whole path, performed by the person who will actually be doing it.

This finds things no amount of configuration review will. The field that is required at a stage where the information does not yet exist. The step that forces a switch back to email because the system cannot do it. The document that comes out with the wrong company details. The notification that goes to the person who set it up rather than the person responsible.

Each of these is trivial to fix in week one and becomes institutional in week six, because by then somebody will have invented a workaround and taught it to somebody else.

The reason it gets skipped is that a real case feels risky before the system is "ready". That is exactly backwards: the case is small now and the system is empty, which makes this the cheapest possible moment for it to go wrong.

The week-one checklist that actually helps

Configure the minimum. Import the active subset. Run the export and look at the file. Name an owner. Establish where failures are reported and who reads them. Write down the baseline numbers you will compare against in ninety days.

Notably absent: training everyone, building reports, and connecting every available integration. Those are all better done in week four, when you know what the work actually looks like — and by then, roughly a third of what seemed essential in week one will turn out not to be.