Prioritizing a digital transformation project means choosing which change deserves the business's money, time and attention first. The decision begins before buying a system. A small retailer may need fewer inventory errors; a service business may need faster responses to quotation requests; a distributor may want additional sales channels without losing control of orders. These businesses could purchase similar technology while facing different problems and needing different measures of success.
Start with the result that needs to change
Describe the problem as something observable: orders are canceled because recorded stock differs from available stock, or quotations receive no follow-up because responsibility is unclear. Connect that situation to a consequence, such as rework, lost contribution margin, delayed receipts or excessive workload. Saying that the business needs to modernize does not help compare options. A useful problem statement identifies the process, how often the problem occurs, who experiences it and the result that should improve. It should also make clear what evidence would show that improvement.
Keep the objective separate from the proposed solution. Increasing sales does not automatically mean opening an online store, and reducing manual work does not necessarily require replacing the entire business management system. Connecting existing tools, cleaning up product records or changing a service rule may be a better first step. Commit initially to a verifiable improvement. Treat the technology as a proposed way to achieve it, whose suitability and feasibility must be assessed against the business's actual resources and constraints.
Observe the process before estimating the benefit
Follow how work actually happens, from the first customer contact through delivery and collection. Look for points where someone copies information, waits for authorization, searches a spreadsheet or corrects a record. Speak with the people doing the work and those affected by it. A report might show dispatch delays, while observation reveals an earlier cause: a salesperson confirmed an order for an unavailable product. Fixing the dispatch screen would leave that cause untouched.
Build a baseline over a period that reasonably represents the operation. Record order volumes, cancellations, overtime actually paid, correction expenses and time between stages. Include busy periods and explain what the sample excludes. Where demand is seasonal, compare equivalent periods or state the limitation. A quiet week cannot support a confident claim about capacity during a sales campaign. Preserve the sources, calculation rules and sample boundaries so another person can reproduce the figures and understand what they cover.
Distinguish recorded facts from estimates and assumptions. An expense can be treated as an observed fact when supported by evidence and classified consistently; reducing that expense in the future remains an assumption. A salesperson's account of a lost sale is a useful lead, but technology may not have been the only reason. Check whether the price was acceptable, the customer intended to buy and the business could deliver. Otherwise, the project may be credited with benefits that require separate commercial or operational changes.
Build a short list of comparable alternatives
Once the problem is clear, identify a few alternatives competing for similar resources. A retailer might compare integrating orders with inventory, opening another sales channel and automating customer follow-up. Include a modest improvement to the current process. This provides a practical reference: if a routine change removes much of the problem, a technology proposal must explain what additional benefit justifies its additional cost. Keeping the current process also has consequences, which should be made visible.
Describe every alternative using the same categories: expected outcome, people involved, initial investment, recurring expense, time to first benefit, dependencies and main uncertainty. Do not compare a fully costed proposal with an idea described only through its upside. A new channel can appear stronger when its forecast includes every imagined sale, while the inventory project includes implementation and maintenance costs. Apply equivalent scrutiny to revenue assumptions, operating demands, costs and failure conditions across the shortlist.
Identify dependencies between projects. A new channel may require reliable product records and a delivery policy; automated collection reminders require accurate payment information. A project that establishes those foundations can deserve priority despite a lower standalone return. Record its enabling role without claiming all the benefits of later projects in advance. Building a capability creates an option to expand. It does not establish that the expansion will happen, that customers will want it or that it will generate an adequate margin.
Use explicit criteria and limits that scores cannot override
A simple scoring matrix makes the reasoning easier to examine. Give each alternative a score from one to five for economic impact, strength of evidence, speed of testing, execution capacity and contribution to the business objective. Define the scale first. For evidence, an unsupported impression might score one, while a measured, reproducible pilot might score five. Weights should reflect the business's situation. They should not give uncertain judgments the appearance of scientific precision or hide disagreement behind a decimal.
Consider hypothetical weights of 30% for impact, 25% for evidence and 15% for each remaining criterion. Inventory integration scores four, four, four, three and four, producing a weighted average of 3.85: 1.20 + 1.00 + 0.60 + 0.45 + 0.60. A new channel scores five, two, two, two and four, producing 3.20: 1.50 + 0.50 + 0.30 + 0.30 + 0.60. Integration ranks higher because its impact is supported by stronger evidence and more achievable execution. These scores document the team's reasoning; they are not market facts.
Apply mandatory limits before ranking. A proposal without an accountable owner, enough cash to survive implementation or adequate control over data exposure should not win because of a high average. Test sensitivity too: if a small change in weights reverses the ranking, the case for a large commitment is fragile. A short investigation may be the appropriate next investment. The matrix organizes arguments, but the decision still requires judgment, recognition of constraints and willingness to revise assumptions.
A worked example: integrating orders and inventory
Consider a fictional Brazilian homewares business selling over the counter and through messaging. All monetary figures and operating quantities in this example are hypothetical, rather than market benchmarks. It handles 400 orders a month at an average value of R$ 250, generating R$ 100,000 in revenue. Each order contributes R$ 75 after R$ 175 in variable costs and expenses. That contribution still helps cover fixed expenses. It is not the business's net profit, and it should not be described as cash available for unrestricted use.
Observation identifies R$ 1,800 a month in rework expenses and R$ 800 in overtime associated with reconciling orders. The proposal integrates orders and inventory for an implementation cost of R$ 18,000, followed by R$ 1,200 a month once the solution is operating. The central assumption is that rework expense falls to R$ 600, the identified overtime payments disappear and the business recovers 20 monthly orders currently lost through availability errors or slow confirmation. Each change requires its own evidence.
The estimated monthly benefit combines R$ 1,200 less rework, R$ 800 in avoided overtime and R$ 1,500 in contribution from the 20 additional orders. Subtracting R$ 1,200 to operate the solution leaves R$ 2,300 a month. Those extra orders generate R$ 5,000 in revenue, but only R$ 1,500 enters this benefit calculation. The remaining R$ 3,500 covers their variable costs. Keeping revenue, contribution and savings distinct prevents the proposal from looking attractive simply because costs were omitted or revenue was mistaken for profit.
Check what actually becomes available cash
The R$ 2,300 benefit depends on three changes supported by different evidence. Lower rework must appear in expenses, overtime payments must actually stop and additional orders must be completed without unexpected cancellations or variable costs. Spending less time checking orders releases capacity, but does not necessarily save cash. That time may create value elsewhere if there is demand and a specific use for it. State whether the proposal expects fewer payments, additional contribution or capacity for another activity, rather than treating these as interchangeable benefits.
In this example, R$ 800 represents overtime payments that cease, not an arbitrary share of salaries for employees who remain on the payroll. Similarly, the R$ 1,200 reduction in rework must exclude expenses that continue. If rework involves return freight and replacement materials, use records of those outflows. Avoid counting them again in the contribution from recovered orders. Give each benefit a distinct source and an owner responsible for checking whether it materialized. A shared reconciliation of these categories helps expose overlaps.
Timing matters as well. Profitable orders may require merchandise purchases before customer payments arrive. To simplify the example, the business estimates that another R$ 2,000 will remain tied up in its operating cycle after implementation. This working capital is separate from implementation expenditure and remains committed throughout the period analyzed. In practice, the amount depends on inventory, supplier terms, customer payment methods and returns. Recognized revenue does not necessarily provide cash for the next bill, and a positive margin does not remove a temporary funding gap.
Put investment, reserve and benefits on one timeline
The business sets a R$ 26,000 project funding limit: R$ 18,000 for implementation, R$ 2,000 for working capital and R$ 6,000 as a contingency reserve. Implementation payments are R$ 4,000 in the first month, R$ 6,000 in the second and R$ 8,000 in the third. The example assumes that the contract includes the resources needed for testing within those amounts. The R$ 1,200 recurring charge and operational benefits begin only in the fourth month, when the solution enters use.
By the end of the third month, R$ 18,000 has been spent, R$ 2,000 is committed to the operating cycle and the R$ 6,000 reserve remains available. From the fourth through the twelfth month, nine months of net benefits at R$ 2,300 total R$ 20,700. Benefits exceed implementation spending by R$ 2,700. After also accounting for the R$ 2,000 still tied up in working capital, the project's cumulative balance is positive by R$ 700. The unused reserve is neither an expense incurred nor a benefit earned: it is money set aside that was not needed.
Simple payback on implementation is approximately eight months of full operation, calculated as R$ 18,000 divided by R$ 2,300. Including committed working capital brings it to approximately nine months. These operating periods follow the initial implementation period; they do not start with the first payment. Simple payback ignores the time value of money, monthly fluctuations and financing costs. It also does not turn the reserve into a return. The key question is whether the business can meet its obligations through the initial period and survive benefits arriving later than expected.
Make the project face unfavorable scenarios
A useful forecast shows how the case can weaken. Under a hypothetical weak-adoption scenario, suppose only ten orders are recovered, rework savings reach R$ 600, all overtime continues and the solution costs R$ 1,500 a month. Additional contribution is R$ 750. Adding R$ 600 in savings and subtracting R$ 1,500 produces a monthly operating loss of R$ 150. There is no investment payback while those conditions persist. A functioning system can therefore remain an economically unsuccessful project.
In a separate scenario, retain the central monthly benefit of R$ 2,300 but add R$ 4,000 to implementation and delay operation by two months. Implementation now costs R$ 22,000 and benefits start in the sixth month. Through the twelfth month, seven monthly benefits total R$ 16,100. Subtracting implementation and R$ 2,000 still committed to working capital leaves a negative cumulative balance of R$ 7,900. The extra implementation cost consumes R$ 4,000 of the original R$ 6,000 reserve, leaving R$ 2,000. These assumptions are independent of the weak-adoption scenario.
Use scenarios to change decisions. The business might limit custom development, require an integration test before the largest payment and monitor whether operators use the workflow. Set a review point if recurring expenses rise or expected benefits fail to appear. Combined scenarios, such as delay plus weak adoption, may be worse than either case alone. A reserve creates time to respond, but cannot make a persistent monthly loss sustainable. Review the timing of obligations as well as the final balance, because cash shortages can occur before the analysis period ends.
Compare automation and sales channels against the business constraint
An additional channel can broaden commercial reach while amplifying an existing weakness. If the business sells unavailable products and confirms orders slowly, attracting more buyers may increase cancellations and complaints. Inventory integration can then deserve priority even when the entrepreneur wants rapid growth. The relevant constraint is the operation's ability to handle extra volume with acceptable contribution, timing and service quality. More demand is useful only when the business can fulfill it under conditions that support its economics.
The conclusion changes if there is unused capacity, reliable service and too little customer demand. A limited commercial test may then teach more than extensive internal automation. Assess channel commissions, customer acquisition, payment processing, picking, delivery, returns and support. Also identify customers who would have bought through an existing route. Moving an existing sale into a more expensive channel can increase revenue attributed to the new channel without improving the total result. Compare what changes for the business as a whole, including displaced sales and additional workload.
The integration example assumes recovery of 20 previously lost orders. Do not claim those same orders again as the full benefit of a later channel project. Where projects depend on overlapping gains, make that overlap explicit. One sequence is to stabilize operations, measure actual contribution and then test a channel with a small product range and an order limit. If the test reveals profitable demand, expansion competes for funding with stronger evidence. Apparent market size alone does not establish accessible demand, fulfillment capacity or an attractive margin.
Design a pilot that can challenge the proposal
A pilot should test the mechanism expected to create the benefit. For inventory integration, choose a product category and operators that represent both routine and difficult situations: cancellations, exchanges, simultaneous orders and products with variants. Decide in advance what records will be collected. Demonstrating one successful sale confirms the basic path works, but says little about the exceptions responsible for daily rework. Include cases where information arrives late or must be corrected, since these often reveal whether the workflow can be trusted.
Use process and outcome measures together. Process measures include inventory discrepancies, duplicate data entry and confirmation time. Outcome measures include rework expense, overtime and contribution from completed orders. Record observed volume so a quieter period is not mistaken for improvement. If discrepancies fall because staff avoid difficult products, the solution has not been validated for the whole catalog. Explain differences between the pilot and the intended rollout, including people, product mix and workload. Better process measures support the benefit hypothesis without automatically proving its full financial value.
Agree on conditions for advancing, correcting and stopping before testing begins. A discrepancy causing a duplicate charge should suspend that workflow for investigation; an unclear screen might allow a correction while use remains restricted. Maintain a way to continue essential work during recovery, with assigned responsibilities and subsequent reconciliation. The pilot need not prove every future return, but should reduce the most dangerous uncertainties before larger commitments. Evidence against the proposal can preserve money and support a better choice. Record unsuccessful cases as carefully as successful demonstrations.
Negotiate scope, acceptance and exit with the supplier
Turn the commercial proposal into verifiable deliverables. Instead of accepting a promise of complete integration, specify which events move between systems, expected transmission times, error handling and responsibility for each system. Include cancellations, stock updates and reconciliation of interrupted orders. Define what the business must provide and what depends on third parties. An unclear boundary often reappears as additional time, customization costs or a dispute about responsibility. Acceptance should test the agreed behavior, including relevant exceptions, rather than merely confirm that software was installed.
The example's R$ 4,000, R$ 6,000 and R$ 8,000 installments could be linked to approved process mapping, tested configuration and accepted operation. Actual payments should follow the negotiated contract, with objective acceptance criteria and a correction procedure. Examine the R$ 1,200 recurring expense: which volumes it covers, how charges change with users or orders and what services are excluded. A low initial subscription can leave substantial charges for support, connectors or data extraction. Identify these conditions before relying on a stable monthly cost in the forecast.
Negotiate an exit route too. Understand the format, timing and cost of data exports, termination rules, available documentation and transition assistance. Request demonstrations using comparable cases without sending unnecessary personal data. If a supplier challenges a requirement, investigate why: it may have identified complexity the business underestimated. Negotiation should allocate obligations and uncertainty clearly. A general promise to resolve everything provides little guidance when costs rise, a dependency fails or the business needs to move to another provider.
Give the team real responsibilities and address disagreements
Even a small project needs clear roles. The entrepreneur or responsible manager decides budget and priority. An operations representative defines the process and follows exceptions. The supplier is accountable for contracted technical deliverables. Someone checks cost and benefit figures, and representative users participate in testing. One person may hold several roles, but authority must remain explicit: who accepts a delivery, approves a scope change and suspends a problematic workflow? Participation without decision rights can leave urgent issues unresolved.
Allocate working time to these tasks. If the inventory supervisor attends meetings and tests without cover, implementation may harm the operation it is meant to improve. Plan training around real situations and provide a support route during the transition. Investigate workarounds. Parallel spreadsheets may indicate resistance, but can also perform a necessary function the new solution lacks. Understanding that function is usually more productive than simply banning the old tool. Resolve the operational need and define how records will be reconciled while the transition continues.
Translate disagreements into testable conditions. Sales may prioritize speed while dispatch fears accepting orders without stock. Record what each team considers acceptable and test simultaneous orders before expanding use. Disclose referral commissions, supplier relationships or personal interests in a solution to those making the decision. Acceptance criteria and recorded reasons help limit decisions based on influence. They do not remove the need for someone to own the choice and its consequences. Responsibility cannot be transferred to a spreadsheet score or a supplier's recommendation.
Include data, access and continuity in the project cost
An integration moves information and enables actions across systems. Map the necessary data, who may view it and who may change it. Customer service access need not include price changes or export of the entire database. Individual accounts help identify actions, while access removal should follow the departure of employees and suppliers. Assess authentication, activity records, backups and recovery according to potential operational impact. Include the effort to administer these controls, rather than budgeting only for their initial configuration.
Build personal data protection into the process. Avoid copying personal documents into test environments when fictional data meets the need. Define purposes, retention, responsibilities and handling of personal data requests with support appropriate to the activity. Guidance from Brazil's ANPD, the national data protection authority, can provide a starting point for study; it does not replace analysis of the specific operation. Budget for necessary controls. Postponing them may create rework or leave an exposure that nobody consciously accepted. Collecting more information than the process needs also creates avoidable handling obligations.
Test a concrete failure: the connection drops after an order is created but before inventory updates. Can the operation be retried without duplicating a charge or stock reservation? Who detects the pending item and reconciles records? Technical integrity has limits. Even if blockchain is used, a preserved record does not establish that the original information was true, prove legal title, demonstrate the solvency of reserves or guarantee payment. Private documents should not be placed on public blockchains as a way to create trust. Traceability must support appropriate controls and evidence, rather than substitute for them.
Organize documentation for decisions and funding discussions
Assemble a concise problem statement, baseline, alternatives, budget, schedule, responsibilities and testing criteria. Add proportionate evidence: expense records, the supplier's proposal, pilot results and a record of assumptions. Mark confirmed information separately from points still requiring validation. This helps management decide and allows a potential funder to ask specific questions about cash use, uncertainty and execution. A polished document does not establish sound economics or eliminate loss. Its value depends on whether the underlying evidence is coherent, accessible to appropriate reviewers and candid about its limits.
KEZS connects entrepreneurial projects and potential funders through technology and intermediation. A project-based approach can help make objectives, use of funds, risks and documentation clearer in those discussions. Investors conduct their own due diligence and make their own decisions; KEZS does not assign a credit score. The method's potential usefulness lies in clearer information and assumptions that can be examined. It implies no approval, repayment, profitability, liquidity, capital protection or availability of funding. A funding discussion also needs transparent consideration of costs and relevant conflicts of interest.
Distinguish instruments before discussing external funding terms. Loans create repayment obligations. Receivables transactions depend on existing, eligible payment claims, which differ from hoped-for future sales. Equity and convertible instruments carry their own rights, conditions and risks, including possible loss. A donation to a nonprofit is neither an equity investment nor a promise of financial return. A Brazilian MEI cannot admit equity partners while remaining a MEI. Public securities distribution and regulated financial activities require appropriate structures and providers. Technology or a CNAE business activity classification does not grant permission to conduct those activities. Regulatory sources are reference entry points, not evidence of KEZS authorization.
Track results and correct the right error
After the solution enters operation, compare actual and forecast results using consistent definitions. Track recovered orders, their contribution, rework, overtime and recurring cost separately. Order volume may rise while contribution falls because of discounts or additional freight. That growth would not confirm the expected R$ 1,500 in contribution. Record price and demand changes that make attribution harder. A useful review distinguishes what improved operationally, what changed financially and how confidently either change can be connected to the integration.
When a target is missed, investigate the causal sequence. If operators use the system but inventory remains inaccurate, the problem may be product records, physical stock movements or the integration itself. If information is correct and confirmations are faster but orders do not increase, the commercial assumption may have been wrong. Buying more modules before diagnosing this sequence adds cost without establishing a remedy. Correct the identified step and observe its effect. Different causes require different responses, even when they produce the same disappointing headline result.
Revise errors in the analysis too. Remove double-counted savings and add omitted costs, even when the correction makes the original decision look less favorable. Preserve the original forecast and explain revisions so learning remains possible. At each review, decide whether to maintain, adjust, restrict or end the project, considering future benefits, contractual obligations and transition costs. Acknowledge money already spent, but do not use it alone to justify further payments for a solution with no reasonable prospect of usefulness. The remaining decision concerns future consequences.
Finish with a decision that can be executed
The final decision can fit on one page if supported by the necessary records. State which problem comes first, which alternative was chosen and why. Specify the spending limit, reserve, accountable owner and next verifiable deliverable. List the conditions that must remain true for work to continue. For the example business, these include technically feasible integration, adoption by operators, controlled recurring cost and evidence that the problems supporting the forecast benefit are declining. Identify who will check those conditions and what decision follows if they fail.
Record what is deferred. The new sales channel might remain conditional on inventory reliability and the pilot's results, with a review tied to a delivery milestone. This prevents each commercial opportunity from turning the project into a larger implementation. Allow room for urgent decisions while requiring equivalent clarity about costs and consequences. When scope changes, update the schedule, cash requirements and acceptance criteria. Simply adding tasks to the team's workload hides the trade-off and can undermine an otherwise achievable plan.
A sound priority authorizes the next commitment and explains how it will be judged. Begin with missing evidence, advance in stages the business can fund and expand when operations support the expected result. If testing challenges the assumption, revise the choice and preserve the learning. Digital transformation creates value when it improves how the business works in a useful, sustainable way. Buying the tool is one step. Delivery means a demonstrable improvement whose costs, responsibilities, uncertainty and risks the entrepreneur can continue to monitor.
Frequently asked questions.
How should a business prioritize when it has very few indicators?
Choose an important process and make a simple baseline assessment before purchasing a broad solution. Record inputs, outputs, exceptions and cash outflows using consistent definitions. Start with information that could change the decision, such as cancellation frequency or correction costs. Identify the sample and its limitations, including unusual demand or excluded cases. If uncertainty remains substantial, prioritize a small test that produces evidence. Filling a forecast with unsupported numbers gives the decision an appearance of completeness without improving its reliability.
Does a security or continuity requirement need to prove a financial return?
Some changes are necessary to maintain an acceptable operation even when additional sales or savings are difficult to measure. Explain the exposure being reduced, its possible impact and the minimum control needed. Compare ways of meeting the requirement, including their costs and implementation times. Do not invent extra revenue to justify the work. The project may deserve priority as an operating condition, with its own budget and accountable owner. Its scope should still be proportionate to the need, and the proposed control should be checked in practice.
When is a spreadsheet still a good solution?
A spreadsheet can support a low-volume process involving few people and limited consequences of error, provided there are clear owners, version controls and appropriate backups. Replacement becomes more relevant when editing conflicts, excessive access, repeated duplication or difficulty tracing changes create material problems. Assess the real cost and consequences of those issues. Moving away from a spreadsheet without defining data entry and checking rules can transfer the same disorder into a more expensive system. Compare a controlled improvement to the existing process with the full cost of replacement.
What if a supplier says it can estimate the price only after starting?
Separate out a diagnostic stage with its own scope, maximum price and deliverables. It should produce enough information to decide on implementation, including integration mapping, identified difficulties and a budget with explicit assumptions. Agree on access to the resulting documentation and the conditions for ending the engagement. Authorizing investigation should not automatically authorize implementation. If material uncertainty remains, negotiate stage limits and clear change rules. The purpose is to buy useful information before accepting a larger commitment, while recognizing that discovery may reveal a reason not to proceed.
How can additional sales be measured without attributing all growth to the project?
Record order sources and compare similar periods or groups while considering campaigns, prices, seasonality and product availability. Investigate customers who would otherwise have purchased through another channel. Where comparisons are not sufficiently reliable, report a range and acknowledge the attribution limit. Base expansion decisions on contribution from completed orders and their associated costs, rather than channel revenue growth alone. Separate evidence that a sale occurred from evidence that the project caused it. This also helps prevent two projects from claiming the same recovered demand.
Is it better to finance implementation or use the business's own money?
Compare the project's cash flow with the business's total obligations. Internal funds preserve contractual flexibility but may reduce cash needed for everyday operations. External funding adds costs, rights and commitments that differ by instrument. Test delayed benefits and weaker results before accepting obligations, and account for financing costs that the simple payback example excludes. The choice depends on liquidity, terms and the risk the business can bear. A favorable projection guarantees neither repayment nor access to capital. This is a business funding assessment, not a prescription for personal asset allocation.
When should a project end after consuming part of its budget?
Consider stopping or reducing it when an essential assumption is disproved, the remaining cost exceeds plausible future benefit or a significant failure has no viable remedy. Calculate exit obligations, data recovery needs, transition costs and operational continuity. Money already spent does not return merely because the business keeps investing. Record why the decision was made and preserve useful knowledge and reusable assets. Arrange continued support for essential processes so that termination does not create an avoidable operational failure. Compare realistic next steps, including a restricted version, rather than treating continuation as the automatic default.
References and context
Institutional reference points for checking applicable rules and guidance. Calculations and scenarios are original examples, not quotes, historical results or individualized recommendations.
- Banco Central — correspondentes no País ↗
- CVM — Resolução 88, texto e alterações ↗
- CVM — Resolução 175, fundos de investimento ↗
- Portal do Empreendedor — perguntas sobre MEI ↗
- ANPD — orientações e perguntas frequentes ↗
AI-assisted educational content. Decisions require verification of the information, instruments and providers in each actual case.
