Before You Hire Another Person to Copy Things Between Spreadsheets…

Follow the part that arrived this morning

Imagine a bicycle repair shop with a booking sheet, a parts-order sheet and a bench list. Each was useful when someone made it. Now the front desk copies the customer and bicycle into all three. The mechanic writes a note in one place. The person unpacking deliveries updates another. Before work can start, someone has to reconcile them.

Two green bicycles are waiting for chains. One chain arrives. A row saying “green bike—parts here” leaves a question that copying faster cannot answer: which repair was that delivery allocated to?

Give the jobs distinct references—say R-104 and R-105—and connect each parts requirement to its job. Record the received quantity and which job it serves. R-104 may now have its required part; R-105 is still waiting. Neither should become “ready for collection” until the shop’s actual repair and completion checks are done.

The useful change is an answer everyone can trace. A job reference follows the work; the person receiving parts records a receipt; the mechanic confirms completion. Each action means something different.

Spend a normal morning watching one job travel. Note every retyped fact, every decision and every search for the latest answer. Do not count a customer conversation or a mechanic’s diagnosis as unnecessary administration just because it happens near a spreadsheet.

You may be one better sheet away from enough

If the problem is inconsistent dates, informal labels and emailed copies, first try a shared place to work, clear column names and a named owner. Agree what each status means. Keep job numbers stable when a row moves, and give corrections an understandable history.

Google Sheets tables already support column types and views. A date column can warn about a value that is not the expected type, and a view can filter or sort the data without changing what colleagues see. Those are useful building blocks for a modest tracker; a valid date still does not tell you that a part will arrive on it. [1] (opens in a new tab)

Try that simpler arrangement with the actual staff. Can the front desk find the job without asking the mechanic? Can receiving identify an unallocated delivery? Can someone cover a colleague’s absence? If it works reliably and takes little effort to maintain, there may be no reason to replace it.

A stronger signal for change is a relationship the team keeps rebuilding by hand. One customer can own several bicycles. Each bicycle can have several repairs. Each repair can need several parts, arriving at different times. Repeating the customer’s details on every row makes a simple correction something to reconcile across copies.

A database-style tool can keep those things separately and connect them. Airtable, for example, documents links between records in the same table or different tables, with the relationship reflected on both sides. The capability is real; whether its interface and account limits suit a particular shop still needs checking. [2] (opens in a new tab)

Give the first version a small, useful job

Bring the job journey to any software conversation. A repair-management product may already cover intake, parts and invoicing. A configurable database may suit a simpler operation. A small custom tool may make sense when the existing options repeatedly force staff to work around an important local process.

For the imagined shop, the first version could be a job page, a list of outstanding parts and an arrival screen. The parts receiver records what came in and assigns it to a job. The mechanic sees the information needed at the bench. The owner can find jobs that need attention without assembling another report.

That scope does not require an AI assistant. Predictable copying can often be replaced with a direct connection or a shared record. If a proposed feature is interpreting messy notes, ask separately how its mistakes would be noticed before those notes affect a repair or customer promise.

A website inquiry could feed this workspace, but an inquiry should not silently become an accepted booking. Decide who checks capacity and confirms the work. Likewise, a connection to accounting needs an agreed owner for invoice amounts and payment status; the repair tool should not invent a second competing answer.

Ask for a price that separates setup, cleaning old data, staff training, subscription or hosting, connections and ongoing support. Check per-user charges, record limits, export options and the features included in the actual plan. This article compares approaches; it does not establish a price or recommend buying a particular account.

The awkward cases belong in the demonstration

Ask the builder to show R-104 and R-105, then receive only one chain. Change a customer detail. Enter the same delivery twice. Let two staff members update the same job. The demonstration should make clear what is saved, what is refused, and what needs someone to resolve—not simply produce an attractive success screen.

Show the screens using the roles people will really have. Someone who can record a part arriving may not need to change prices or see every customer detail. Hiding a column is not a sufficient test of access.

Microsoft explicitly says worksheet protection is not a security feature. It limits editing of locked cells; that is different from protecting a file against being opened. This matters if a team mistakes a locked sheet for permission to share confidential information widely. [3] (opens in a new tab)

There is a similar distinction in database tools. Airtable’s field and table editing permissions control changes, not visibility of the information in a base. Its documentation lists these editing controls for Team, Business and Enterprise Scale plans. Test who can view as well as edit, using the account and sharing arrangement you actually intend to use. [4] (opens in a new tab)

Before switching, keep a protected copy of the original records, reconcile active jobs against the proposed system and demonstrate an export you can understand. Check that the export preserves the relationships needed to reconstruct the work. Decide who maintains backups and prove that a restore works. An export button alone does not establish recovery.

Set a clear changeover point. For a short comparison period, name one place as authoritative and explain how discrepancies get resolved. Leaving two editable systems in use indefinitely would recreate the copying problem you set out to remove.

What should your next employee spend their time doing?

Try one manageable part of the work before moving the entire business. Include routine jobs and exceptions rather than selecting only the easy repairs. Ask the people at the front desk and bench what still interrupts them.

Measure minutes spent retyping and reconciling, jobs delayed by unclear information, and corrections required after a handoff. Include time spent maintaining the new tool. Compare similar work over a useful period and note busy days, staffing changes and unusual jobs; a few smooth examples do not establish a lasting saving.

Hiring may still be exactly right. A busier shop may need more customer care or skilled repair capacity even after the records improve. The question is whether the new person will do valuable work or become the permanent bridge between files.

Kundan HQ in this portfolio connects jewelry inventory, customer claims, labels and fulfillment around the pieces being sold. It is a different business from the imagined repair shop, but it illustrates why connected records can matter. The bicycle example is a proposed design, not a feature claimed for that project.

Before writing a job description for more administration, follow one job all the way through. Keep the decisions that need people. Give the repeated facts a dependable place to live. Then decide what help the business actually needs.