# How to Choose Technology Vendors and Define Acceptance Criteria | KEZ$

Canonical: https://kezs.com.br/en/learn/digital-transformation/how-to-choose-technology-vendors-and-define-acceptance-criteria
Language: en-US

Learn to compare technology vendors, negotiate contracts, and define acceptance criteria using tests, full costs, clear responsibilities, and evidence.

[Digital transformation](https://kezs.com.br/en/learn/digital-transformation)

# How to Choose Technology Vendors and Define Acceptance Criteria

Learn to compare technology vendors, negotiate contracts, and define acceptance criteria using tests, full costs, clear responsibilities, and evidence.

KEZS team · Educational guide

[Vendor selection](https://kezs.com.br/en/learn?tag=Vendor%20selection)[Acceptance criteria](https://kezs.com.br/en/learn?tag=Acceptance%20criteria)[Digital transformation](https://kezs.com.br/en/learn?tag=Digital%20transformation)[Automation](https://kezs.com.br/en/learn?tag=Automation)[Sales channels](https://kezs.com.br/en/learn?tag=Sales%20channels)[Project management](https://kezs.com.br/en/learn?tag=Project%20management)[Technology contracts](https://kezs.com.br/en/learn?tag=Technology%20contracts)

[← Digital transformation](https://kezs.com.br/en/learn/digital-transformation)[1. Start with the business decision the technology must support](https://kezs.com.br/en/learn/digital-transformation/how-to-choose-technology-vendors-and-define-acceptance-criteria#topic-1)[2. Turn business needs into a comparable scope](https://kezs.com.br/en/learn/digital-transformation/how-to-choose-technology-vendors-and-define-acceptance-criteria#topic-2)[3. Use a numerical example to see the full cost](https://kezs.com.br/en/learn/digital-transformation/how-to-choose-technology-vendors-and-define-acceptance-criteria#topic-3)[4. Investigate the vendor with evidence proportionate to the risk](https://kezs.com.br/en/learn/digital-transformation/how-to-choose-technology-vendors-and-define-acceptance-criteria#topic-4)[5. Compare proposals without hiding decisions inside a score](https://kezs.com.br/en/learn/digital-transformation/how-to-choose-technology-vendors-and-define-acceptance-criteria#topic-5)[6. Make the demonstration reproduce your company's work](https://kezs.com.br/en/learn/digital-transformation/how-to-choose-technology-vendors-and-define-acceptance-criteria#topic-6)[7. Write acceptance criteria as verifiable situations](https://kezs.com.br/en/learn/digital-transformation/how-to-choose-technology-vendors-and-define-acceptance-criteria#topic-7)[8. Define performance, data, and security through test conditions](https://kezs.com.br/en/learn/digital-transformation/how-to-choose-technology-vendors-and-define-acceptance-criteria#topic-8)[9. Assign responsibilities so acceptance has an owner](https://kezs.com.br/en/learn/digital-transformation/how-to-choose-technology-vendors-and-define-acceptance-criteria#topic-9)[10. Negotiate payments, changes, and defect correction](https://kezs.com.br/en/learn/digital-transformation/how-to-choose-technology-vendors-and-define-acceptance-criteria#topic-10)[11. Build the schedule alongside the cash flow](https://kezs.com.br/en/learn/digital-transformation/how-to-choose-technology-vendors-and-define-acceptance-criteria#topic-11)[12. Address disagreements and adverse scenarios before urgency takes over](https://kezs.com.br/en/learn/digital-transformation/how-to-choose-technology-vendors-and-define-acceptance-criteria#topic-12)[13. Plan operational launch and a workable rollback](https://kezs.com.br/en/learn/digital-transformation/how-to-choose-technology-vendors-and-define-acceptance-criteria#topic-13)[14. Separate technical acceptance from economic results](https://kezs.com.br/en/learn/digital-transformation/how-to-choose-technology-vendors-and-define-acceptance-criteria#topic-14)[15. Preserve data, continuity, and the freedom to leave](https://kezs.com.br/en/learn/digital-transformation/how-to-choose-technology-vendors-and-define-acceptance-criteria#topic-15)[16. Complete the contract with a documented project and explicit decisions](https://kezs.com.br/en/learn/digital-transformation/how-to-choose-technology-vendors-and-define-acceptance-criteria#topic-16)[Frequently asked questions](https://kezs.com.br/en/learn/digital-transformation/how-to-choose-technology-vendors-and-define-acceptance-criteria#faq)[References](https://kezs.com.br/en/learn/digital-transformation/how-to-choose-technology-vendors-and-define-acceptance-criteria#references)

What you will find 

Choosing a vendor to digitize a business starts before requesting proposals. First, identify the operational change that justifies the purchase. A retailer may want an online sales channel, a distributor may need fewer picking errors, and a service business may want less rework when scheduling appointments. These objectives require different capabilities. Buying a system because it offers many features can shift attention away from the original problem: the company starts reshaping its work around the vendor's catalog without establishing whether the investment addresses the need.

01 

## Start with the business decision the technology must support

Describe the problem through an observable situation, its frequency, and its consequences. Instead of saying that customer service needs improvement, explain that orders arrive through three channels, require manual reentry, and sometimes receive confirmation when stock is unavailable. Separate measurements from impressions. A record of orders actually corrected is evidence; the expectation that automation will eliminate almost every error is a hypothesis. Both can inform procurement, but they deserve different weight. Establishing a baseline also makes it possible to compare later results with the situation that prompted the purchase.

Identify decisions that remain the company's responsibility. A system can flag insufficient stock, but someone must decide whether to allow a backorder. A tool can distribute customer inquiries among salespeople, but management must establish the priority rules. If these choices remain unresolved, the vendor may make commercial decisions for technical convenience. The demonstration may work while the real operation encounters disputes over an important customer, an urgent order, or an exceptional price. Document who can authorize exceptions so that the software implements an agreed policy rather than becoming an accidental source of policy.

02 

## Turn business needs into a comparable scope

A useful scope describes complete workflows. For a new sales channel, follow the process from a product inquiry through confirmation, stock deduction, issuance of applicable documents, and handling a return. Identify where each system's responsibility begins and ends. The phrase 'inventory integration' is insufficient: it does not explain which data moves, when it moves, how balances change, or what happens if communication fails. Differences in these details account for many pricing surprises. A connector that only displays stock may require substantially different work from one that also reserves stock and reconciles canceled orders.

Divide requirements into essentials for operation, items for a later stage, and desirable additions. An essential requirement must have a concrete consequence: without it, the business cannot start safely or achieve the contracted objective. Avoid turning personal preferences into launch blockers. A button's position may be negotiable; preventing the sale of unavailable stock may be essential. Ask each vendor to classify every requirement as already available, configurable, requiring development, or unsupported, with the corresponding cost. This exposes assumptions that a simple yes-or-no checklist can hide and allows proposals to be compared on equivalent terms.

State exclusions explicitly. Product photography, description editing, data cleanup, connectivity, and answering customers may fall outside the technology service even though the project needs them. A stated exclusion allows the company to assign an owner and budget; an exclusion discovered during implementation becomes a dispute. Establish a procedure for future changes: describe the request, assess its effect on price and schedule, approve it, and update the agreed scope. Informal conversations should not silently change the standard used for acceptance. Keep the current approved version accessible so both parties know which obligations apply to each delivery.

03 

## Use a numerical example to see the full cost

Consider a fictional distributor connecting its catalog, orders, and inventory. Every amount in this example is hypothetical arithmetic, not a market price. Proposal A charges R$ 30,000 for implementation, R$ 1,800 per month, and R$ 4,800 for data migration. Over a planning horizon containing implementation and twelve monthly service payments, expected external spending is R$ 56,400: R$ 30,000 plus R$ 21,600 plus R$ 4,800. A lower implementation charge therefore does not necessarily mean a lower cost over the chosen period. The recurring commitment must be considered alongside the initial purchase.

Proposal B charges R$ 36,000 for implementation, R$ 1,200 per month, and R$ 6,000 for migration. Its external total is also R$ 56,400: R$ 36,000 plus R$ 14,400 plus R$ 6,000. For either option, the distributor estimates R$ 6,000 of internal work and sets aside R$ 6,000 for contingencies, producing a planning envelope of R$ 68,400. The contingency reserve is not an expense already incurred. It is financial capacity reserved for deviations identified during the project. If no qualifying deviation occurs, setting the money aside does not mean it has been spent.

This comparison is valid only if the proposals cover equivalent content. Confirm user numbers, order volumes, storage, support, training, taxes included in each quotation, and price adjustment terms. Transaction fees or a mandatory connector can change the result. Check what happens when usage exceeds the quoted allowance and whether additional services require separate contracts. The planning horizon includes implementation and twelve operating payments; it is not automatically a calendar year or twelve months after signature. Analyze payment timing separately, because total cost measures the commitment while cash flow shows when the company needs funds available.

04 

## Investigate the vendor with evidence proportionate to the risk

Commercial due diligence should establish who will sign the contract, perform the work, and respond when problems arise. Verify the business's identity, the people responsible for the agreement, and the proposed delivery team. Ask which activities will be subcontracted and which depend on a single individual. A small provider can deliver a project suited to its capacity, while a familiar brand can assign an inadequate team. Company size is no substitute for examining availability, relevant experience, and continuity. Confirm whether the people presented during sales discussions are actually committed to the delivery.

Request demonstrations tied to your scope and references that may be contacted with permission. When speaking to another customer, ask how delays, scope changes, and production defects were handled. An implementation without incidents may reveal less about recovery than a difficult situation managed well. Marketing materials and selected testimonials can help generate questions, but they do not establish that your company will receive the same team, architecture, or contractual terms. Record the circumstances behind a reference so that a successful small installation is not treated as evidence for a much more demanding operation.

The depth of investigation should reflect the dependency being created. A standalone design tool requires different scrutiny from a system concentrating orders, customer information, and commercial rules. For the latter, request evidence of access controls, data recovery, incident handling, and export capability. Summaries or demonstrations may be appropriate when full documents are confidential. Record what was demonstrated, what remains unverified, and how that uncertainty affects selection. An unanswered question need not automatically disqualify a vendor, but accepting the uncertainty should be an explicit business decision with a consequence and an owner.

05 

## Compare proposals without hiding decisions inside a score

An evaluation matrix helps when criteria are established before a preference for a seller develops. For the distributor, a hypothetical model might assign 30 points to functional fit, 20 to implementation and migration, 20 to continuity and data protection, 15 to cost, and 15 to support and exit arrangements. These weights total 100 and express this company's priorities, not a universal ranking. Every score needs a verifiable explanation, such as a demonstrated function, a contractual provision, or a completed test. A number unsupported by evidence merely gives an opinion a more formal appearance.

Some requirements should be eligibility conditions that cannot be offset by points elsewhere. If the company must recover its orders in a usable format, a vendor that blocks exports may be excluded despite a low price. The same applies to an indispensable integration or an essential access restriction. Allowing a polished presentation to compensate for a critical failure creates the appearance of mathematical rigor while retaining a risk management already considered unacceptable. Distinguish a requirement that must pass from an attribute on which the company is willing to make a tradeoff.

Record disagreements among evaluators. Sales may prefer speed, operations may prioritize stability, and finance may favor a lower initial payment. The decision improves when each area identifies the consequence it fears and the compromise it accepts. In this example, A and B have the same external cost over the selected horizon. Choosing B would require additional evidence, such as stronger integration test results or more suitable continuity terms. Do not invent superiority to fill a spreadsheet. If the evidence does not distinguish the proposals, identify what further demonstration or negotiation would resolve the uncertainty.

06 

## Make the demonstration reproduce your company's work

A presentation directed entirely by the seller usually follows the product's most favorable path. Prepare your own script and send scenarios in advance. Ask the vendor to demonstrate a normal order, insufficient stock, a quantity change, a partial return, and an access attempt by someone without permission. Ask it to interrupt an integration and show recovery as well. The purpose is to observe behavior and limitations, including steps that require manual intervention. Record those interventions because a process described as automated may still require staff time and a clear responsibility for handling exceptions.

A proof of concept can reduce specific uncertainties when it has a defined question and duration. For the distributor, it could test whether the existing system accepts stock updates and whether repeated order submissions create duplicates. A visual prototype does not answer either question. Conversely, building the entire operation before contracting can create substantial work without sufficient agreement. Define the proof's deliverables, usage rights, data handling, and criteria for concluding whether feasibility has been demonstrated. Its purpose is to resolve a bounded uncertainty, not to replace an implementation contract through an open-ended sequence of unpaid or undefined tasks.

Use fictional data or an authorized, minimized dataset. Do not hand over the entire customer database simply to make a demonstration easier. At the end, record the versions and configurations used, the steps simulated, and anything dependent on unfinished work. A result in a controlled environment is evidence of that test, not a promise of performance at every volume. If a material limitation appears, adjust scope and price before treating it as resolved. Distinguish an observed capability from a proposed workaround so the purchasing decision reflects what was actually shown.

07 

## Write acceptance criteria as verifiable situations

Acceptance criteria should allow different people to reach the same conclusion from the same evidence. 'Integration working' is weak wording because it identifies neither the input, the expected result, nor the exceptions. A clearer criterion would state that confirming an order for available items creates one order, updates the corresponding stock balances, and displays the transaction identifier. The agreement should identify participating systems, required data, and how the result will be demonstrated. Define the starting conditions too: otherwise, a disagreement about the test setup can be mistaken for a disagreement about the delivered behavior.

Include adverse scenarios. Resending a confirmation after a communication failure must not duplicate the order. If stock is insufficient, the system must apply the reservation or blocking rule approved by the business. If an external service is unavailable, the issue must be visible to the responsible person, with a way to retry processing. Each scenario requires prepared data and an expected outcome. This turns a word such as 'reliable' into behavior that can be tested and corrected. It also clarifies which failures the system handles automatically and which require a person to decide what happens next.

The distributor might prepare 40 acceptance scenarios covering sales, cancellations, returns, and integration failures. To approve the functional milestone, every critical scenario must pass, and no defect causing duplicate or lost orders may remain open. Lesser defects may be accepted only with an identifier, an agreed deadline, and a responsible person. The number 40 defines this hypothetical plan; it does not establish that testing is sufficient. Coverage of business decisions matters more than a long list of similar cases. Retain the results and identify the tested version so later changes do not obscure what was approved.

08 

## Define performance, data, and security through test conditions

Nonfunctional criteria also need context. 'Fast response' does not identify the operation or the workload. As a hypothesis to validate, the distributor might require 95 out of every 100 catalog queries to complete within three seconds, with twenty concurrent sessions, in the environment and connection described in the test plan. Separate processing controlled by the vendor from external dependencies. Record durations and failures rather than selecting only successful attempts. These conditions make the result interpretable: passing under the stated load does not establish performance for a larger workload that was never tested.

For migration, compare both counts and content. Suppose the source contains 2,000 products, including 50 inactive ones. The company must decide whether to migrate all products or only the 1,950 active products, and how to preserve the required history. Check identifiers, units, prices, and relationships, and investigate duplicates. A correct count can conceal swapped products or incorrect field values. Where fields are transformed, retain a mapping between source and destination and resolve discrepancies before operational use. Record deliberate exclusions separately from errors so that an approved omission is not confused with a missing record.

For data protection, test access profiles, removal of user access, and restoration of a backup in a separate environment. Request clarity about the personal data processed, purposes, involved providers, and incident communications, with specialist support where needed and attention to applicable Brazilian requirements. For performance and recovery, distinguish measurements actually obtained from commitments that remain contractual. A security presentation is not an executed restoration, and the existence of a backup does not prove operational recovery. Identify who evaluates the evidence and what unresolved weakness would prevent the company from starting to use the system.

09 

## Assign responsibilities so acceptance has an owner

The vendor cannot independently approve a rule that depends on the business. Name a company representative to coordinate priorities and, where possible, another person to validate operational workflows. Identify who prepares records, provides access, decides exceptions, and authorizes payments. In a small business, one person may hold several roles, but the responsibilities should remain distinguishable. A missing owner often appears to be a vendor delay when an internal decision is actually pending. The schedule should show those dependencies so the parties can distinguish unfinished technical work from information or authorization still owed by the company.

The vendor should identify the delivery lead, the technical contact, and their substitutes. For each milestone, record the evidence it must submit and the customer's review period. Avoid relying on scattered messages to reconstruct decisions. A simple register can include the requirement, delivered version, test result, identified defect, responsible person, and acceptance decision. This history reduces disputes based on different recollections and preserves context when team members change. It also helps distinguish a correction that was promised from one that was delivered and retested, which are separate states with different implications for acceptance.

People who know the daily work must participate before launch, with time reserved for preparation. If the distributor budgets R$ 6,000 for internal effort, that estimate should represent real data preparation, testing, and training, even if no additional employee is hired. Separate technical validation from commercial authorization as well. Someone who negotiated a discount may feel pressure to declare success; acceptance should follow the evidence and the effects reported by the people who will operate the process. A low quotation does not remove the need to allocate staff time to make implementation usable.

10 

## Negotiate payments, changes, and defect correction

Milestone payments can align spending with delivery, but only when each milestone has verifiable content. For proposal B's R$ 36,000 implementation charge, a hypothetical arrangement is 20% on mobilization, 30% after validated configuration, 30% after integration acceptance testing, and 20% after operational launch and final acceptance. The amounts are R$ 7,200, R$ 10,800, R$ 10,800, and R$ 7,200. The first installment pays for mobilization; it is not evidence of a delivery that has not occurred. Specify which materials or preparations accompany that initial step without confusing preparation with functional completion.

Negotiate how the vendor will receive feedback. A review period supports planning, but automatic acceptance through silence can be problematic if the customer lacks access or sufficient evidence. Discuss the wording with appropriate advisers and define when the review clock starts, how objections are communicated, and how defects are corrected. The commercial objective is to avoid both approval through inattention and indefinite withholding over preferences outside the agreement. Connect an objection to a requirement and an observed result so that the parties can determine whether payment conditions have been met.

Distinguish a defect correction from a change request. If the system was required to prevent duplicates and does not, correction belongs to the contracted scope. Adding a newly requested commission rule may require additional work. Every request should identify the related requirement and its impact. Negotiate the period and limits for correction, post-implementation support, and recurring failure handling. A generic warranty promise does not explain who responds, how quickly, or which charges remain. A response commitment also differs from a resolution commitment: acknowledging an incident does not mean the underlying problem has been fixed.

11 

## Build the schedule alongside the cash flow

In the hypothetical case, implementation under proposal B takes eight weeks. Mobilization occurs in week zero, configuration is validated in week three, integrations in week six, and final acceptance in week eight. If those deliveries occur as planned, implementation payments follow the four amounts already defined. The R$ 6,000 migration charge may be split into R$ 3,000 after the test import in week four and R$ 3,000 after the checked final import in week eight. These are negotiated assumptions for the example, not market rules. Each payment remains connected to the delivery specified for it.

The company therefore needs R$ 7,200 in week zero, R$ 10,800 in week three, R$ 3,000 in week four, R$ 10,800 in week six, and R$ 10,200 in week eight. These payments total R$ 42,000 for implementation and migration. The R$ 6,000 of internal effort is distributed as the work occurs, while the R$ 6,000 contingency remains available. Under the assumed contractual terms, twelve monthly payments of R$ 1,200 begin after final acceptance, totaling the R$ 14,400 already included. Keep this operating commitment visible even though it starts after the implementation milestones.

Consider what happens if a stage slips. If integration acceptance moves from week six to week ten because of a vendor defect, its linked payment should follow the milestone as provided in the contract. Nevertheless, the company may continue paying for old tools and assigning staff to the project. If the delay results from records the customer failed to provide, responsibility changes. A useful schedule exposes dependencies and waiting costs, helping management choose between fixing the cause, narrowing scope, or reorganizing launch. A deferred invoice alone does not mean the delay has no economic effect.

12 

## Address disagreements and adverse scenarios before urgency takes over

Difficult disputes often begin when both parties use the same word differently. To the vendor, 'delivered' may mean available in a test environment; to the company, it may mean usable by trained employees with checked data. Define those states separately and maintain an open-item register. When disputing a result, describe the reproducible scenario, observed behavior, expected requirement, and operational consequence. This provides a basis for a decision without turning every defect into an argument about intentions. It also allows the parties to recognize progress without prematurely treating an unfinished implementation as accepted.

Suppose that in week six the external system lacks the stock-query mechanism assumed in the proposal. First establish what information was provided and who was supposed to validate that dependency. Then compare options: obtain appropriate access, build another connector, update at intervals, or temporarily remove the workflow. Each option changes cost, timing, and risk. If periodic updates allow sales without available stock, do not accept the alternative merely to preserve the schedule. The operation's owner must assess the consequence, including who handles any affected orders and whether the revised process still meets the project's essential objective.

Also consider prolonged downtime, departure of a key specialist, and an unexpected increase in volume. Agree on warning signs, a responsible person, and possible responses for each case. Contracts cannot eliminate every risk, and vendors may refuse commitments incompatible with their price. Negotiation becomes clearer when the company distinguishes acceptable concessions from essential conditions. If a limitation defeats the main objective, ending or restructuring the contract may preserve more resources than continuing to avoid acknowledging money already spent. Prior expenditure is part of the history, but it does not establish that further expenditure will be useful.

13 

## Plan operational launch and a workable rollback

Accepting a solution does not necessarily require moving the entire operation at once. Where feasible, start with a limited set of products, users, or orders and establish conditions for expansion. The pilot should include relevant difficulties rather than only the easiest scenario. For the distributor, it could cover a product with a unit variation, a return, and a customer with specific commercial terms. The aim is to learn with controlled exposure before creating more dependency. Define what evidence allows expansion and what finding would require correction or suspension, rather than assuming a pilot automatically proceeds to full deployment.

Specify when changes in the old database stop, when the final import occurs, and how the data is checked. If both systems operate in parallel, establish the authoritative source for each type of information and prevent duplicate entries. Rollback must account for transactions completed after the switch: restoring an old backup without reconciling new orders can erase valid work. The return plan therefore needs to describe recovery and reconciliation of those transactions. Identify who records activity during an interruption so that returning to the previous system does not create an unexplained gap in the business record.

Final acceptance should bring together passed tests, reconciled data, prepared users, and support available during stabilization. Tolerated outstanding items must be specific and compatible with operation. A visual alignment issue may wait; intermittent order loss may block release. Record who authorized launch, which evidence supported the decision, and which conditions would require interruption. This record cannot eliminate incidents, but it organizes the response and prevents commercial urgency from replacing a considered assessment. Any temporary workaround should have an owner and a review point so that it does not quietly become a permanent, unsupported operating dependency.

14 

## Separate technical acceptance from economic results

A solution can meet its contract yet deliver less benefit than expected. Suppose the distributor processes 1,200 orders per month and spends six minutes per order on administrative work. That is 7,200 minutes, or 120 hours. Reducing the time to four minutes would mean 4,800 minutes, or 80 hours, releasing 40 hours per month. Valuing that capacity at a hypothetical R$ 30 per hour gives R$ 1,200 of potential benefit. It does not establish an equivalent cash saving. The calculation values available working time; whether that time produces a financial benefit depends on what actually changes.

If the same employees continue receiving the same pay, released capacity may support better service, additional volume, or less overtime. Each use requires its own evidence. Also suppose corrections fall from 24 to six per month, with every avoided correction eliminating R$ 40 of actual cost. Eighteen fewer corrections would represent R$ 720. Before adding this to the time benefit, confirm that the R$ 40 does not include the same hours already counted. Otherwise, the calculation values one improvement twice. Distinguish observed reductions from expectations, and check whether new tasks introduced by the system consume some of the time released.

If both benefits materialized independently, the monthly total would be R$ 1,920. Subtracting the R$ 1,200 subscription leaves R$ 720 before other costs. Against R$ 48,000 for implementation, migration, and internal effort, simple division suggests approximately 66.7 months of recovery, ignoring the time value of money and further spending. That R$ 48,000 excludes the unspent contingency. If only fewer corrections became a cash saving, the monthly balance would instead be negative R$ 480. These conditional calculations show why higher sales, saved time, and cash generation are different outcomes; none is established merely by technical acceptance.

15 

## Preserve data, continuity, and the freedom to leave

Vendor selection also determines how difficult switching vendors will be. Check export formats, data coverage, field documentation, and charges for transition assistance. A file full of unexplained codes may be insufficient to reconstruct orders and history. Negotiate delivery of configurations and materials created specifically for the project where that forms part of the agreement. Distinguish them from the vendor's preexisting software, whose ownership and usage terms must be clear. Test an export while implementation is under way: finding a missing relationship or unusable format then gives both parties a chance to resolve it before exit becomes urgent.

Establish how domains, accounts, and access to external services will be managed. Essential resources should have known ownership and responsible contacts, avoiding dependence on the personal email address of whoever implemented the solution. This does not mean collecting passwords indiscriminately. Use individual accounts, proportionate permissions, and secure recovery methods. When someone leaves, revoke access and preserve necessary records. The company should be able to show who is authorized to operate the service, purchase additions, and receive incident communications. Include account recovery and contact changes in continuity planning so a staff departure does not make essential resources inaccessible.

Where personal data is involved, clarify processing responsibilities, protection measures, and data handling at termination under the applicable Brazilian framework, with appropriate advice. Never publish private documents on a public blockchain as delivery evidence. An integrity record may help show that content has not changed; it does not establish truth, legal title, reserve solvency, or a payment guarantee. Blockchain use does not resolve those separate questions. For acceptance, prefer evidence accessible to the parties and protected from unnecessary exposure. Keep only the information required to support the decision, with access and retention arrangements suited to its sensitivity.

16 

## Complete the contract with a documented project and explicit decisions

Before signing, assemble a coherent version of the problem, scope, financial proposal, acceptance criteria, schedule, and responsibilities. Check whether the sales demonstration promised anything missing from the agreement. Reassess whether contingency remains sufficient for the uncertainties uncovered. If the budget cannot cover everything, reduce the project to a smaller but complete operational workflow. Removing failure handling to preserve eye-catching features may lower the quotation while increasing operating costs. Record why the vendor was selected, unresolved uncertainties, who may approve changes, and any commercial or referral conflicts that could influence the recommendation.

If the company seeks funding, this documentation can help potential funders understand the intended use of funds, payment milestones, and benefit assumptions. KEZS connects entrepreneurial projects and potential funders through technology and intermediation; investors conduct their own diligence and make their own decisions, and KEZS does not assign a credit score. Documentation guarantees neither approval nor repayment, profitability, liquidity, or preservation of capital. Loans, receivables arrangements, equity, convertibles, and donations create different rights, obligations, costs, and loss risks. Existing eligible receivables differ from hoped-for sales, and a donation to a nonprofit is neither equity nor a promise of financial return.

Use structures and providers appropriate to the activities involved. Public securities distribution and regulated financial activities require the applicable arrangements and permissions; technology or a Brazilian CNAE economic activity classification is not authorization. An MEI cannot admit equity partners while remaining MEI. Consider funding conditions, conflicts, uncertainty, and potential loss alongside usefulness, without treating a documented technology project as a funding recommendation. Use acceptance to confirm deliveries and operational measurement to assess benefits. If an assumption fails, reconsider the process or investment and preserve the learning rather than treating signature as an obligation to declare success.

FAQ 

## Frequently asked questions.

### Should I choose the cheapest vendor when the budget is tight?

First compare the cost of equivalent scope and the cash required at each stage. A low implementation price may come with mandatory additions, more internal work, or higher monthly charges. Confirm usage limits, migration, training, support, and exit costs before deciding that one proposal is cheaper. If none fits, consider a smaller project that still delivers a complete usable workflow. Preserve requirements that prevent data loss, incorrect orders, and dependence without a workable exit. A discount improves the decision only when delivery conditions remain suitable for the operation; it does not compensate for a missing essential capability.

### How do acceptance criteria, service levels, and business outcome indicators differ?

An acceptance criterion verifies a delivery, such as correctly processing a cancellation in defined scenarios. A service level sets conditions for ongoing operation or support, such as response times and incident handling, with contractual definitions and measurement rules. A business outcome indicator tracks effects such as administrative time per order or monthly corrections. These measures are related but answer different questions. Technical acceptance does not establish increased sales or realized savings, and a support response does not establish that a defect was resolved. Define the evidence and responsible person for each measure so a favorable result in one category does not conceal a problem in another.

### Can I accept implementation while defects remain open?

That can be reasonable when defects are known, limited in impact, and covered by an agreed correction plan. Record each issue, its temporary workaround, deadline, responsible person, and any restriction on use. A defect that occasionally loses orders, changes amounts, or allows unauthorized access should not be treated as minor simply because it occurs infrequently. Partial acceptance must identify exactly what has been approved and which obligations remain. Consider whether the workaround creates additional staff effort or another risk. Urgency does not remove a consequence already identified, and acceptance should not obscure the evidence needed to confirm that the remaining correction was completed.

### What should I do when the vendor says a problem is a scope change?

Compare the request with the approved requirement and expected behavior. Provide a reproducible example and evidence of what should happen. If the obligation was already specified, there is a basis for discussing defect correction; if the company introduced a new rule, additional work may be justified. Where the original wording is ambiguous, negotiate an explicit solution and its effect on price and timing. Record the agreement in the scope reference used for future acceptance. The aim is to resolve the actual obligation and operational consequence, rather than assume that every disagreement is either free correction or automatically chargeable development.

### How can a small business perform acceptance testing without an IT team?

The person who understands daily operations can validate commercial scenarios and check results if given time and guidance. Prepare test orders, expected values, stock conditions, cancellations, and exception cases, then record what happened. Ask the vendor to demonstrate its work and explain limitations in usable language. For matters difficult to assess internally, such as recovery, permissions, and critical integrations, consider independent technical help with a defined scope. That support has a cost and should address specific uncertainties. The company's acceptance decision must still reflect its own workflows and priorities, rather than relying entirely on the vendor's statement that implementation is complete.

### How can I avoid excessive dependence without demanding all the source code?

Start with usable data exports, documentation, clearly owned accounts, transition terms, and continuity alternatives. In many services, these are more useful than receiving code without a team able to maintain it. Test an export during implementation and check whether orders, relationships, and history can actually be interpreted. For custom development, negotiate delivery materials and usage rights appropriate to the contractual model, distinguishing them from the vendor's preexisting software. Source code ownership alone does not supply hosting, operational knowledge, or maintenance capacity. A workable exit combines rights, information, access, assistance, and a realistic understanding of what a replacement provider would need.

### Is it appropriate to link vendor payment to increased sales?

It requires care because sales also depend on prices, demand, inventory, customer service, and commercial investment. Variable payment can be negotiated when there is a verifiable metric, a comparison baseline, and agreed treatment of outside influences and cancellations. Discuss what data supports the calculation and how disagreements will be resolved. Do not replace functional acceptance with a general promise of growth. For many projects, it is clearer to pay for verified deliveries and separately assess whether economic results justify continuing, expanding, or correcting the investment. Increased revenue also does not automatically establish profit or cash generation, so the selected metric must match the intended business outcome.

## 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 ↗](https://www.bcb.gov.br/estabilidadefinanceira/exibenormativo?tipo=Resolu%C3%A7%C3%A3o%20CMN&numero=4935)
- [CVM — Resolução 88, texto e alterações ↗](https://conteudo.cvm.gov.br/legislacao/resolucoes/resol088.html)
- [CVM — Resolução 175, fundos de investimento ↗](https://conteudo.cvm.gov.br/legislacao/resolucoes/resol175.html)
- [Portal do Empreendedor — perguntas sobre MEI ↗](https://www.gov.br/empresas-e-negocios/pt-br/empreendedor/perguntas-frequentes)
- [ANPD — orientações e perguntas frequentes ↗](https://www.gov.br/anpd/pt-br/acesso-a-informacao/perguntas-frequentes)

AI-assisted educational content. Decisions require verification of the information, instruments and providers in each actual case.

## Keep learning.[Explore the category ↗](https://kezs.com.br/en/learn/digital-transformation)

[

Digital transformation 

### How to Prioritize a Digital Transformation Project

Choose technology, automation and sales channel projects by weighing business impact, cash needs, evidence, risk and your team's capacity to deliver.Explore the article ↗  ](https://kezs.com.br/en/learn/digital-transformation/how-to-prioritize-a-digital-transformation-project)

[

Digital transformation 

### Software budgeting: planning implementation, integration and operations

Learn how to budget software, integrations and ongoing operations, compare supplier proposals, and plan cash flow against measurable business outcomes.Explore the article ↗  ](https://kezs.com.br/en/learn/digital-transformation/software-budgeting-planning-implementation-integration-and-operations)

[

Digital transformation 

### Automation with Measurable Operational Returns

Learn how to choose automation projects, measure benefits and costs, test assumptions, and track cash without confusing efficiency with financial returns.Explore the article ↗  ](https://kezs.com.br/en/learn/digital-transformation/automation-with-measurable-operational-returns)

From knowledge to decisions 

## Plan your next step with more clarity.[Get started ↗](https://kezs.net/?lang=en)