Essay / Digital Systems & Commerce
Digital Operations Is Where Strategy Meets the Spreadsheet
Product data, approvals and exception queues turn strategy into daily work. Make decisions explicit before automating the spreadsheet that holds them.
A strategy presentation says the business will offer a broader catalogue with more reliable availability. The spreadsheet says one supplier uses different identifiers, another sends incomplete descriptions, and several products need a manual pricing exception. Both describe the same business, but only one reveals what happens on Tuesday morning.
I do not see the spreadsheet as evidence that the strategy failed. It is often where the organization has made the missing rules visible enough to keep working. The problem begins when those rules remain informal while more people and systems depend on them.
Digital operations is the work of turning intentions into repeatable decisions. It sits between software, information, and the people who handle the cases that the standard process does not explain.
Operations is strategy after it meets reality.Read the spreadsheet as a process map
Before replacing an operational spreadsheet, I would ask someone to walk through a recent real task. Which row did they open? Which cells did they trust? What did the colors mean? Which value came from another system, and which value represented a judgment?
A column labeled “ready” may encode several different checks. A note may contain the only explanation for an exception. A formula may combine a commercial rule with a temporary workaround. None of these details is obvious from the column names alone.
The goal is not to preserve every accidental convention. It is to discover which decisions the current artifact supports. A new interface that copies the fields but loses the decision context can make the operation less reliable even if it looks more professional.
Separate observations from policies. A supplier’s reported price is an observation. A minimum acceptable margin is a policy. A manual override is a decision with a reason. Mixing all three into one editable cell makes later investigation unnecessarily difficult.
Turn strategic language into operational questions
“Improve catalogue quality” is a reasonable direction, but it does not tell an operator whether a product can be published. The process needs a more concrete definition: which information is required, which omissions are acceptable, and who can approve an exception?
Strategyzer’s guidance on strong hypotheses emphasizes making assumptions testable, precise, and discrete. That discipline is useful when translating an operating ambition into something a team can examine. Avoid combining several unrelated outcomes into one statement that cannot fail clearly.
For example, instead of assuming that a new import tool will improve both speed and accuracy, investigate those outcomes separately. It may reduce handling time while allowing more incorrect descriptions through. A single success label would hide the tradeoff.
Choose a bounded workflow and observe it before changing it. Record the missing information, repeated decisions, and points where work waits for someone else. This produces a more useful starting point than selecting an automation platform from a list of features.
Ownership should follow the decision
An operational task can pass through several people without anybody owning its final state. One person imports data, another checks prices, and a third publishes products. When something is wrong, each can truthfully say they completed their step.
Give important decisions an owner and an explicit handoff. Who decides that the product is ready? What evidence must be present? Who can reopen the decision after new information arrives? The answer should be visible in the process rather than inferred from who happens to be available.
Ownership does not require one person to perform every action. It means there is a clear responsibility for resolving uncertainty and maintaining the rule. A shared queue can work well when its members know how work is assigned and what completion means.
The same principle applies to data. If both the supplier feed and the merchandising team can overwrite a description, the system needs a precedence rule. Without one, a conflict becomes a recurring human negotiation disguised as a synchronization bug.
Exceptions deserve a designed path
An exception is not always an error. A special commercial agreement, an unusual product, or a legitimate customer request may require a different decision. The system should distinguish those cases from malformed input or a failed integration.
For a pricing exception, record the scope, reason, approver, and duration. Is it valid for one product, one order, or a period of time? What happens when it expires? A permanent checkbox is a poor representation of a temporary agreement.
Make the next action clear. An exception queue should explain what information is missing and who can resolve it. “Needs attention” is useful only if the operator can determine what attention means without searching several unrelated tools.
Review recurring exceptions. A case that appears every week may indicate a missing standard rule. Automating each individual workaround without revisiting the policy can produce a complicated system that faithfully preserves an outdated process.
Automate a decision you can explain
Automation is attractive because it removes repetitive handling. It can also repeat an ambiguous decision faster and at a larger scale. Before automating a step, write examples of accepted, rejected, and uncertain cases.
Suppose a catalogue import should reject incomplete products. Which fields are genuinely required? Does the rule differ by product category? Can an existing public product remain visible while an update awaits clarification? These are domain decisions, not configuration details to improvise inside the importer.
A useful first automation may prepare a proposed change rather than apply it immediately. An operator can compare the proposal with the current state and inspect the reason. This creates evidence about the rule while limiting the effect of a mistaken assumption.
As confidence grows, some cases can move to automatic handling. Keep the uncertain cases visible and retain a way to stop the process. Workflow tooling needs clear boundaries when it begins making decisions that other parts of the business rely on.
Measure the wait as well as the work
A process can contain quick individual steps and still take a long time overall. Much of the delay may occur between steps, while a request waits for missing information or an approval. Measuring only active handling time can miss the main constraint.
Track a small set of meaningful states and timestamps. When did the request arrive? When was it ready for review? When did it become blocked? When was the intended outcome achieved? These records help distinguish a slow task from a slow handoff.
Use the information to improve the process, not to turn every activity into a performance score. A person handling the most difficult exceptions may appear slower precisely because they are doing important work that the ordinary path cannot complete.
A useful operating view highlights aging work, repeated failure categories, and unresolved ownership. It should make the next improvement easier to choose. Adding more charts without changing a decision creates reporting work rather than operational clarity.
The best automation removes repeated handling while preserving the reasons behind the decision.
Replace the artifact carefully
Once the rules are understood, replacing the spreadsheet may be worthwhile. The replacement could be a better structured file, a small internal application, or a capability in an existing system. The right choice depends on the workflow, not on whether spreadsheets look sufficiently modern.
Plan the transition around continuity. Preserve identifiers, explain changed fields, and decide how old records remain accessible. Run representative cases through the new process before relying on it for all work. Compare decisions, not just whether the rows imported successfully.
Keep an explicit route for reporting discrepancies during the transition. The people doing the work will often discover cases that the initial model missed. Treat those discoveries as information about the process rather than resistance to the new tool.
A successful change leaves the organization with clearer rules and less dependence on private memory. The interface matters, but the more durable result is that another person can understand why work moves forward, why it stops, and how an exception gets resolved. That is where strategy becomes an operation the business can actually sustain.