How to choose an e-commerce agency that takes responsibility after go-live

You have several quotes on the table. They all describe a new e-commerce site, better product data and a customer portal connected to the business system. The prices differ, but it is hard to tell whether you are comparing the same commitment.

When you choose an e-commerce agency, you need to be clear about who carries the uncertainty after go-live. That means who fixes an order that gets stuck, who keeps the connection working after an upgrade and what the supplier can charge when the scope changes.

The answers lie in the pricing logic, the integrations and the contracts. That is where you need to start, before you judge the storefront.

Six questions that decide whether the e-commerce agency is right for you

Ask every supplier to answer the same questions in writing. That way the CFO can compare costs while the IT manager reviews dependencies. The e-commerce manager can check that the day-to-day work actually fits within the delivery.

In 2024, 36.7 percent of Swedish companies with at least ten employees sold online via the web or EDI, according to Statistics Sweden's figures on IT use in businesses. The figures cover both web-based sales and automated business transactions between systems. For your assessment, the whole order path therefore needs to be visible in the quote.

Every answer should be backed by a demo, a contract clause or a relevant customer reference.

Which business systems do you have ready-built integrations for, and who owns the connection? Ask for documentation of integrations with Business Central, Monitor or Jeeves, and a clear statement of responsibility after go-live. The answer shows whether orders, prices and stock are covered by defined product ownership.

How do fixed price and time and materials work? Ask for a written scope, rules for changes and a clear statement of when the price becomes binding. The answer shows whether you risk having the same work priced twice.

Who is responsible for ongoing management after launch? Ask for contract terms covering bugs, security and operations, and for when a new quote is required. The answer shows whether the supplier's responsibility continues after launch day.

What is included in upgrades? Ask whether new versions of the platform and the business system are covered by the contract. The answer shows whether every upgrade could turn into a new project.

How are the platform and PIM handled? Ask for named owners for enriching and approving product data for all channels. The answer shows whether the channels can show consistent information.

Which references resemble your business? Ask for business customers with the same business system and customer-specific prices. The answer shows whether the supplier's experience covers your business rules.

A clear no is useful. It lets you price what is missing or drop a function. A general assurance that everything can be solved leaves more decisions open.

Compare the exclusions in the quotes before you compare the totals. Mark what you have to deliver yourselves, which assumptions the price is based on and who approves the result. Two similar totals can carry very different risks for you.

Also ask for the demos to follow a business case of your own. Use a real customer type, a representative item and an agreed pricing rule. That gives you material you can assess together with sales and finance.

The business system shows who owns the integration

An order can look correct in the customer portal and still need manual correction in the business system. The customer may have the right discount but the wrong delivery address. The order may also lack a reference that your finance department needs for invoicing.

So start with your current business system. Ask the supplier to name ready-built connectors for, for example, Business Central, Monitor and Jeeves. Then move on to the system and the version you actually use.

A ready-built integration needs to mean something you can check. Scope, prerequisites and price should be described. The documentation should state which data is transferred, in which direction and what happens when the recipient rejects it.

Have the supplier show products, customer-specific prices, stock levels and orders through the whole flow. Not all data needs to go both ways. But every piece of data needs a defined source and a documented route to the recipient.

Test tiered discounts, blocked customers, back-ordered items and different delivery addresses. Also check how the system handles an interruption after the customer has submitted the order. Retries must be possible without the same order being registered again.

When you review ready-built integrations, you need to see exactly which of these rules are covered. The discussion of e-commerce and the business system helps you keep the focus on the whole business flow. Follow an order from a logged-in customer to a registered order in the business system, and introduce a deliberate error along the way.

You need to provide a test environment, access and someone who knows the pricing logic. Someone on your side also has to decide which exceptions to keep. Otherwise the developer ends up making business decisions through technical assumptions.

Finish the review by naming the integration owner after go-live. The contract needs to state who troubleshoots when the platform and the business system show different data. A demo of the web flow leaves that question unanswered.

A fixed price holds when the scope is known before you start

The price is often set while parts of the work are still unknown. The uncertainty then stays in the delivery. Either the customer or the supplier will carry it, depending on what the contract says.

A low entry price can be followed by a new quote once pricing rules, data migration or permissions are examined more closely. That is why you need to separate a cost for discovery from a binding price for delivery.

Ask the supplier to describe what is included, what counts as a change and who is allowed to order additions. A change should be approved before the work starts. The same rule needs to apply when someone on your side passes a request straight to the developer.

A phrase like "customer-specific prices" is rarely enough as an acceptance criterion. Describe where the price is calculated, which discounts are combined and what the user sees when a price is missing. Then the function can be tested before approval.

We use ready-built, tested and compatible functions through the Function Library. Standard has a fixed scope and a fixed price. Adapted starts from the same foundation with agreed changes, while Customer-unique is isolated so the rest can be upgraded without being affected.

The contract needs to include a delivery description that states what behaviour you will approve, prerequisites that state which data and decisions you must provide, a change rule that states who approves cost and impact on the timeline, and exclusions that state which work falls outside the price.

A fixed price requires you to show your current website, portal and business system before pricing. You also need to choose which requests belong in the first delivery. An undecided request can rarely be priced responsibly.

Time and materials suits you when you are deliberately exploring a way of working or a function. You then need to be able to prioritise the work continuously and accept that the final cost is open. Ask for frequent reporting on the remaining uncertainties, so that budget decisions follow what you actually know.

Ongoing management decides the cost after go-live

After launch, both the platform and the business system keep changing. Your customer portal depends on the technical conditions of both. Microsoft, for example, releases major updates to Business Central twice a year. So someone needs to read the release notes, assess the impact and test that pricing and order flows still work.

Split responsibility for bugs, security fixes and operations. They need different actions and can sit with different parties. A general line about support tells you too little when an order stops.

Bug fixing covers errors in what you have already bought. Security work covers vulnerabilities and updated dependencies, among other things. Operations covers the environment the solution runs in, plus monitoring and handling of outages.

The contract needs to distinguish between receiving a ticket and being responsible for getting the error fixed.

Ask for the contract to describe version tracking and compatibility through upgrades of both the platform and the business system. It also needs to state who books the test environment, runs the tests and approves the release to production.

An upgrade can take more than installing a new version. Permissions, price calculations and order transfer need to be tested with relevant business cases. Also document how you roll back if the production release fails.

The contract needs to name who fixes bugs and how tickets are prioritised, who assesses and applies security fixes, who monitors operations and acts on outages, and who ensures compatibility and approves the test results during upgrades.

A rule of thumb based on the build price says little about these commitments. In your TCO calculation, you need to be able to track both the agreed monthly cost and any work that may be added. The description of ongoing management and upgrade responsibility is relevant when you look at where ongoing responsibility ends and further development begins.

On your side, you need a named recipient and time to approve production releases. Your own code changes need to follow the same agreed way of working. Finally, the contract should name the responsible party, the systems covered and the conditions for work that requires a new quote.

PIM decides whether your channels show the same product

A technically working connection can publish the wrong product data. If nobody owns the attributes, the website, customer portal and reseller channel can show different names. Each channel may also have its own manual fixes that disappear at the next transfer.

Start by stating where each piece of data belongs. Product descriptions and technical attributes can be managed in PIM. Prices and stock can come from the business system. Also decide which system is allowed to overwrite an existing value.

Ask the supplier to show which fields must be complete before migration and publishing. State who on your side approves technical specifications, translations and local variations. For ranges shared across a group, decision rights between the companies also need to be clear.

A useful way of working is to enrich the data where it is owned and then publish it to the relevant channels. Manual enrichment suits copy that needs product knowledge. Automation suits data that already exists in a reliable source. An item missing mandatory attributes should get a clear owner and a visible error message.

Say a spare part gets the wrong name but the right item number. The customer chooses by name and orders the wrong part. The order transfer works, but you still have to handle a return and a support case.

So let your review of PIM and data quality cover both publishing rules and responsibility for fixes. Track missing mandatory fields, rejected items and manual corrections. Then you can prioritise the errors that affect orders.

PIM work takes time from your product managers during implementation. A smaller range with few channels can manage with simpler product administration. Choose the scope based on who will maintain the data and how often it changes.

Three questions reveal whether the reference resembles you

References become useful when you know what was actually delivered. A well-made storefront shows how the interface works. For your decision, you also need to understand the pricing rules, the system connection and what the customer still does manually.

Which two business customers can you name that use the same business system as we do, and how are their customer-specific prices and orders handled? The answer shows how close the supplier's experience is to your own business.

What was a ready-built function, what was adapted and what was customer-unique, and how was the customer-unique part handled during upgrades? The answer shows whether the solution can be built on while keeping the same foundation.

Ask to find out what scope was delivered and what the customer actually uses, which steps the customer still does manually, how changes after launch were ordered and paid for, and which party handles errors today.

Who does the customer call when an order stops after go-live, and is that help covered by the contract? The answer shows whether the reference still has a working management commitment.

Ask to speak with the customer and keep the conversation on everyday work. Find out how errors are reported, who coordinates troubleshooting and how changes are approved. The customer should be able to describe both what works and what takes their own time.

A published customer case is rarely enough to judge who carries responsibility when the systems show different data.

Accept that some details are confidential. The supplier should still be able to describe the system, the delivered scope and the division of responsibility at a relevant level. If the system can never be named, you have limited grounds for judging the experience.

Have someone from the business join the reference call together with IT. Sales hears whether the pricing logic works day to day. IT can judge whether the customer still coordinates suppliers on their own.

Set aside two hours before you sign

Before you sign, you need to be able to show how the solution works today and what has to change. Bring your website or portal, a representative range and examples of pricing exceptions. Also gather your existing contracts, so responsibility for operations, integration and development can be assessed.

Your current solution helps you decide what can be kept and what needs to change. Pricing and order exceptions show which functions must be included from the start. Existing contracts show which responsibilities need to be moved or added.

Use this material to separate functions that can be reused from work that needs development. That makes it clearer whether a ready-built integration covers your rules or whether the scope needs adjusting. You can also judge whether a product website is enough as a first step and can later be extended into a portal.

A fixed setup suits you when you can describe the scope and give the supplier a chance to examine the dependencies before a binding commitment. If you have no business system to connect to, the integration questions may carry less weight. A temporary campaign page may also need a simpler commitment. If you want to change code often without an agreed scope, time and materials may better reflect the uncertainty.

For Litium and Business Central, there is a ready-built connector in the Function Library, but the scope still needs to be checked against your pricing rules and exceptions. In a 72-hour analysis, you set aside two hours, and within 72 hours you get an inventory of functions and integrations, a functional specification, a prototype and a complete cost picture with a timeline, free of charge.