If Your Spreadsheet Had a Job Description, What Would It Say?

Start with the verbs, not the columns

Open the spreadsheet and ignore its filename for a moment. Ask each regular user to finish this sentence: “I open this sheet to…” Write down the verbs. Calculate, assign, remember, summarize, approve, notify, schedule, and reconcile are more revealing than tab names.

Next, ask what would happen if the file were unavailable for one workday. A minor inconvenience suggests a supporting tool. Missed orders, uncertain approvals, or stalled customer work suggest an operational system, whether anyone intended to build one or not.

This is Poygan’s practical classification exercise, not a formal software standard. One workbook may perform several roles. Circle the role that carries the greatest consequence when something is late, missing, duplicated, or wrong.

• Who enters information?
• Who changes it later?
• Who needs an answer from it?
• What decision or handoff happens next?
• What mistake is hardest to notice?

The calculator: inputs go in, an answer comes out

A calculator spreadsheet turns known inputs into an estimate, price, schedule, quantity, or comparison. Its strength is visible math. Its risk grows when nobody can distinguish input cells from formulas, when copied versions use different logic, or when a result is treated as approved simply because the sheet produced it.

The smallest sensible next step is usually not an app. Protect formula cells, mark the intended inputs, document assumptions beside the calculation, and create one maintained template. Add a sample calculation with an expected answer so changes can be checked.

Consider an app when many people need the calculator, inputs must come from another system, calculation versions must be traceable, or the answer triggers a larger workflow.

The queue: rows are waiting for somebody

A queue spreadsheet holds work that has arrived but is not finished: leads to call, jobs to schedule, invoices to review, or exceptions to resolve. You can recognize it by status colors, initials, due dates, and frequent questions about who has the next move.

Its problem is rarely the grid itself. The problem is coordination. Two people can claim the same row, an urgent item can disappear below the fold, and a status can change without notifying the next owner.

Start by adding one accountable owner, one plain-language status, one next action, and one due date. Define what each status means. If the team still depends on manual checking to discover new or overdue work, a focused workflow app or configured task system may be the next reasonable step.

The database: the sheet is becoming organizational memory

A database-like spreadsheet stores durable records about customers, products, equipment, jobs, or transactions. Warning signs include duplicate names, multiple spellings for the same value, hidden lookup tabs, and uncertainty about which row is authoritative.

SQLite’s official guidance draws a useful boundary: spreadsheets work well for tabular data and human interaction, while a database provides stronger tools for structured querying, data integrity, and coordinated application access. SQLite also notes that a client-server database is generally a better fit when many computers write to the same database over a network. Those are the source’s technical observations. The choice for a particular business still depends on its workflow, risks, and existing systems.

Before building anything, choose a stable identifier for each record, decide which system is the source of truth, remove fields nobody uses, and standardize the few values that drive decisions. If several processes must reliably read and update the same records, investigate an existing CRM, ERP, or database-backed app before commissioning custom software.

The report: people look, but should not edit

A report spreadsheet exists to answer recurring questions: What sold? What is late? Where is capacity tight? It may contain exports, pivot tables, formulas, and charts, but its real job is helping someone decide.

The smallest improvement is to write the decision beside the report definition. State who reviews it, how often, what period it covers, when the data was refreshed, and what action a concerning number should prompt. Remove decorative metrics that never change a decision.

A dashboard or automated report becomes useful when assembling the same view consumes repeated effort, readers need consistent definitions, or stale exports create avoidable confusion. A prettier chart alone is not a system upgrade.

The approval log: a decision needs a trustworthy record

An approval log records who accepted a quote, discount, purchase, schedule change, or exception. Initials and green cells may feel efficient, but they can become ambiguous when edits overwrite history or the surrounding context lives in email.

First, define what is being approved. Record the item, decision, decision-maker, date, and relevant version or reference. Limit editing where practical. If approvals affect money, customer promises, access, or compliance obligations, use a system that preserves identity, timestamps, context, and change history appropriate to the risk. This article does not determine any legal or regulatory requirement.

The accidental application: all the roles meet in one workbook

A spreadsheet has become an accidental application when it stores records, calculates outcomes, routes work, controls approvals, and produces reports. Other clues include macros only one person understands, instructions such as “never sort this tab,” and a ritual of copying yesterday’s file to make today’s.

That does not mean the workbook failed. It may have successfully revealed the application the business actually needs. Treat it as a working prototype. Map its inputs, rules, roles, outputs, and exceptions before discussing replacement technology.

Then choose the smallest next step. Stabilize the workbook if the problem is unclear ownership. Connect it to an existing system if duplicate entry is the main burden. Configure a mature product if the workflow is common. Build a focused app only when the process is valuable, reasonably stable, and poorly served by available tools.

A useful migration can also happen one responsibility at a time. Keep the trusted calculator while moving the queue into a shared workflow tool. Leave the report in place while establishing a cleaner source of truth. The goal is not to win a war against spreadsheets. It is to give each important job a tool that can carry it without depending on memory and caution alone.