What the First Week Actually Does

The most common mistake teams make with new software is trying to make week one do everything. They want to migrate history, explore every feature, train everyone at once, and redesign the process on day one.

That is usually how a rollout gets stuck.

The first week has one job: get your current operation running through the system so you can see, clearly, what is actually happening in the business right now.

What not to do first

Do not begin with a grand migration project.

Do not start by trying to backfill every historical delivery.

Do not spend three days debating perfect category structures or designing a reporting taxonomy nobody will use yet.

And do not train the entire company before the core workflow has been tested end to end by the people who actually create and complete deliveries.

A good first week is not ambitious. It is live.

Days 1-2: Two lists

Start with two lists: your products and your supermarket accounts.

For each product, capture the basics: name, weight, price, category. If you have more than 20 products, use the CSV import. Pull the data from whatever you already use, clean it up once, upload it, and move on.

For each account, enter the details you actually need to operate: store name, branch, address, contact person, delivery window, and any handling notes that drivers need at the point of arrival.

Those two lists power almost everything else in the system. If they are clean, the rest of the setup becomes straightforward.

Do not start with historical migration. That is a separate project, and it does not help you get live this week.

Day 3: The first delivery

Create a delivery for tomorrow. Pick the supermarket, add the products and quantities, and let the system generate the delivery note. Print it if you need to, or pull it up on the driver's phone.

This step matters more than people think because it forces the product list and the supermarket list to prove they are usable. If something is missing, vague, or inconsistent, you find out immediately.

When the delivery is done, close it properly. Mark it complete. Record any returns or discrepancies there and then. That part should take minutes, not another follow-up process at the end of the day.

At that point you have your first real record in the system: when it went out, where it went, what was delivered, and what came back. That is enough to begin.

Day 4: Put it in the hands of the people doing the work

By day 4, at least one real delivery should have passed through the system from creation to completion.

Now put the workflow in the hands of the people who will actually use it every day.

If the office creates deliveries but drivers close them, test that handoff. If one person handles returns, let them process the next real return in the system instead of recreating it later from paper. If your team works from phones, install the PWA and use it the way the operation will really use it.

This is where rollout plans either become real or stay theoretical.

Day 5: Review what the system is already showing you

By day 5, the flow should feel familiar: create delivery -> complete delivery -> log returns. That is the loop the rest of the platform builds on.

Now look at the dashboard. Even with only a few days of data, you can already see things that were hard to spot before: what has been delivered, what is still open, where return rates are climbing, which deliveries are sitting in "pending" longer than they should.

That information was usually somewhere in the spreadsheet already. It just was not visible in a way that helped you act on it.

If you have more than one driver or more than one person managing accounts, use the end of the week to agree on one simple standard: every delivery is closed in the system, and every return is logged against the original job. That one discipline creates most of the downstream value.

What you should have after one week

By the end of the first week, success should look like this:

• your current product catalog exists in one place
• your supermarket accounts and branches are usable
• at least one live delivery has gone through the full workflow
• returns are being recorded against real deliveries
• the team knows where the shared source of truth now lives

That is enough.

You do not need advanced analytics on day five. You need operational consistency.

What can wait until week two

Week two is a better time for everything that sounds important but is not required to get live:

• cleaning up old historical data
• adding long-tail product metadata
• refining categories and naming conventions
• configuring recurring schedules
• exploring more advanced reporting
• expanding usage to every supporting team member

Those are worthwhile projects. They are just not first-week projects.

The first-week checklist we actually recommend

If you want a practical checklist, use this:

1. Import or enter all active products.
2. Enter every live supermarket account and branch.
3. Confirm delivery windows and contact details.
4. Create one real delivery.
5. Complete that delivery in the system.
6. Log the next real return against the original delivery.
7. Review the dashboard with the people who own the workflow.

If all seven happen, the rollout is working.

Why this matters more than a "full implementation"

A lot of software rollouts fail because they ask a team to imagine the future state of their business before they have even run tomorrow's delivery cleanly.

We prefer the opposite approach.

Get tomorrow's delivery right.

Then get Friday's return right.

Then get next week's records consistent enough that the dashboard starts telling the truth.

Once that foundation is in place, the heavier features start to matter: analytics, PDF output, operational reporting, mobile workflows, and the wider coordination features around them. But those features only help once the core loop is trustworthy.

That is what the first week actually does. It establishes trust in the record.

If you need the step-by-step delivery workflow, the delivery creation guide covers the mechanics. If your team works from phones, the PWA install guide is worth doing during rollout, not after it.