High volume, low variation
The same questions arrive all day: order status, returns, refunds, cancellations, wrong items, address changes, stock. Each ticket is simple. Collectively they consume the team.
Custom software for e-commerce operations
Automate the support work your team still has to do by hand
We build AI-powered customer support systems for e-commerce companies that can understand a request, read the relevant order context, and take action in the systems you already use, refunds, returns, tracking, cancellations, and the rest of the repetitive operational load.
For e-commerce teams whose ticket volume grows with order volume, and whose agents spend most of the day in the same handful of workflows.
The economics
Support cost scales with orders. Headcount should not have to.
Most e-commerce support volume is not complex. It is repetitive operational work performed by people because the systems that hold the answer are scattered, and traditional chatbots only produce text.
What this looks like in a real support week
Expensive people on cheap tasks
Trained agents spend their time copying order numbers between a helpdesk, a shop, a WMS, and a carrier portal. The work is necessary. It is not a good use of a salary.
Context switching between systems
Resolving one ticket often means three or four logins. The customer waits while the agent reconstructs a picture the company already has, just not in one place.
Chatbots that answer without resolving
A bot can say “please provide your order number” and paste a policy. The refund still has to be issued by a person. The return still has to be created by a person. The ticket is not closed; it is delayed.
Volume grows with the business
More orders produce more “where is my order” tickets. Peak season hires are hard to find, expensive to train, and idle in February. The operating model does not scale cleanly.
Slow resolution, not just slow replies
A same-day reply that still requires two more emails to finish the return is not a finished job. Customers care about the outcome: cancelled, refunded, tracked, replaced.
Hours and languages the team cannot cover
Evening and weekend tickets sit until morning. Expanding into another market means hiring for another language, or leaving those customers waiting.
Fragmented systems
Shop, ERP, helpdesk, shipping, returns, inventory, and email rarely share a single operational picture. Automation that cannot see across them cannot do the work.
Typical requests, and what happens today
“Where is my order?”
Agent opens the helpdesk, searches the shop, then the carrier, then writes back a status the customer could have had immediately if those systems were queried together.
“I want to return this.”
Agent checks the return window and product rules, creates a return in another tool, generates a label, and emails instructions. Several clicks. Same sequence, hundreds of times.
“Can I cancel my order?”
Agent checks whether the warehouse has already started picking. If not, they cancel in the shop and reverse the payment. If yes, they explain why and start a return instead.
“I received the wrong product.”
Agent collects photos or SKUs, checks the original order, opens a replacement or refund path, and coordinates warehouse intake. Policy is clear. Execution is manual.
“Can I get a refund?”
Agent verifies payment, delivery, and refund rules, then issues the refund in the commerce or payment system and confirms to the customer.
“Can you change my shipping address?”
Agent checks fulfillment state. If the parcel has not left, they update the address. If it has, they explain the constraint. The rule is simple. The lookup is not.
“Is this product in stock?”
Agent leaves the conversation, checks inventory, and comes back. A stock figure already exists in a system the customer cannot see.
If this is your support week, see how an action-based flow handles the same requests.
The distinction
The problem is not that you need another chatbot. The problem is that someone still has to do the work.
If the AI only drafts a reply, your team still has to retrieve the order, apply the policy, click the refund, create the return, and write the confirmation. That is where the cost sits.
Traditional chatbot
- 1Understands the question
- 2Generates a response
- 3Escalates the actual work to a human
Action-based system
- 1Understands the request
- 2Retrieves the relevant context
- 3Decides what is allowed
- 4Executes the action
- 5Confirms the resolution
The difference is resolution, not another reply. Explore the demo or tell us your stack.
What we build
A custom automation layer on the stack you already run
We do not ask you to rip out the shop, the helpdesk, or the warehouse tools. We connect an automation layer to the systems your business already uses, with the permissions and rules you define.
We connect the automation layer to the systems your business already uses.
Possible integrations depend on the engagement. Examples of systems we can connect to, not a claim that every platform is already supported out of the box:
Commerce
- Shopify
- WooCommerce
- Magento / Adobe Commerce
- Custom storefronts
Operations
- ERP systems
- Inventory / WMS
- Shipping platforms
- Returns platforms
Customer systems
- Helpdesk / ticketing
- CRM
- Customer databases
Internal
- Internal APIs
- Existing databases
- Payment providers
- Custom business tools
The implementation is tailored to your stack, data model, and the actions you are prepared to automate. If a system has an API or a stable integration path, it can usually be connected. If it does not, we say so in discovery.
Use cases
Requests that can be resolved, not just answered
Exact actions depend on the client's systems, permissions, business rules, and the implementation we agree. The examples below are the workflows we typically design first because they are high-volume and well-bounded.
Order tracking
The customer asks where the order is. The system retrieves order and shipping data and returns the current status, carrier, and tracking reference, without an agent reconstructing it by hand.
Returns
The customer requests a return. The system checks eligibility, opens the return workflow, and provides instructions or a label through the returns platform you already use.
Refunds
The customer requests a refund. The system checks order state and refund conditions, then initiates the refund workflow when the rules allow, or queues it for human approval when they do not.
Order cancellation
The system checks whether cancellation is still possible given fulfillment state, then executes the cancellation and payment reversal when permitted.
Order modification
The customer wants to change a shipping address or another eligible attribute. The system checks whether the order can still be changed and performs the update when the rules allow it.
Product and inventory questions
The system retrieves current product information and stock from the inventory source of truth, instead of an agent leaving the conversation to look it up.
Carrier delays and parcels that stop moving are a different workflow from ticket handling. See proactive shipment monitoring
These are the workflows we typically automate first. Which ones cost you the most today?
Architecture
How a request becomes a completed action
The AI layer is not a black box sitting on your helpdesk. It is software with explicit steps: retrieve context, evaluate permissions and business rules, execute through APIs, log what happened, and escalate when it should not proceed.
Customer
Email, chat, or existing helpdesk channel
AI support layer
Understands intent and required entities
Business logic
Permissions, policies, and allowed actions
Existing systems
Shop, ERP, shipping, returns, CRM, APIs
Action
Read, write, or human-approval queue
Resolution
Customer receives the outcome, with an audit trail
What the implementation typically includes
Context retrieval
Order, customer, shipment, inventory, and ticket history loaded so the system is not guessing from the message text alone.
Authentication and permissions
The automation acts with credentials and scopes you approve. It cannot do more than the role you grant it.
Business rules
Return windows, refund caps, cancellation cut-offs, VIP exceptions, encoded as rules, not improvised by the model.
API integrations
Reads and writes go through the same interfaces your operations already depend on, with error handling for partial failures.
Action execution
Eligible actions run automatically. Ineligible or ambiguous ones stop and escalate instead of inventing a workaround.
Logging and auditability
What was retrieved, what was decided, what was executed, recorded so operations and finance can reconstruct a case.
Human escalation
Uncertain, high-value, or policy-sensitive requests are handed to an agent with the context already assembled.
Monitoring
Failed API calls, unusual refund patterns, and queue depth are observable. Automation without monitoring is not an operational system.
We do not claim a universal connector for every platform. Discovery determines what can be integrated, what should stay manual, and where a human approval step is the responsible default.
Operating models
Autopilot and copilot. Increase automation on purpose.
Companies rarely want to hand every action to software on day one. Two operating models let you raise automation as trust, rules, and monitoring mature.
Autopilot
Eligible requests are handled end-to-end: understood, checked, executed, and confirmed. Humans stay on exceptions, high-value cases, and anything the rules do not cover.
Copilot
The system prepares the recommended action, the supporting context, and a draft message. A human approves before anything is written to a commerce or payment system.
Most implementations start with copilot on sensitive actions (refunds, goodwill, delivery disputes) and autopilot on bounded ones (tracking, stock, in-policy returns). The mix is a business decision, not a technical ultimatum.
Economics
Why this is worth engineering, not another subscription experiment
If a large share of tickets is the same operational sequence, the cost of continuing to staff that sequence grows with order volume. Custom automation is a capital expense against that recurring labor, and against the opportunity cost of agents who never get to the cases that actually need judgment.
The ROI logic, without invented numbers
Reduced support labor on repetitive work
Hours currently spent on tracking, in-policy returns, and straightforward cancellations can be removed from the daily queue when those workflows are eligible for automation.
Capacity without proportional hiring
Order growth no longer requires a matching increase in headcount for the same ticket mix. Peak season becomes a volume problem for software, not only a recruiting problem.
Faster resolution
A lookup-and-action cycle that takes an agent several minutes can complete in the time it takes to query the APIs, including outside staffed hours, where the rules allow.
Less backlog, clearer exceptions
When the repetitive tickets leave the queue, the remaining work is the work that needed a person anyway. That is a better use of the team you already have.
Market data
What the public numbers show
Online retailers that automated a large share of their support, with the figures they made public. They give a sense of what deep automation of repetitive tickets can be worth.
Nordic online retailer
85% of tickets handled automatically
Approximately 1.2 million DKK saved per year.
Direct-to-consumer retailer
84% of tickets handled automatically
Approximately 231,000 DKK saved per year, reached in 36 days.
Multi-country online retailer
92% handled automatically
From 400 unanswered emails to one person covering 5,000+ tickets per month across seven countries.
The comparison is about the economic shape of the problem: high automation of repetitive e-commerce tickets can be worth serious investment, not about matching a specific percentage for your catalogue.
When custom work in the €5k–€25k range is rational
If automation removes thousands of repetitive tickets per year, the avoided labor, overtime, peak-season hiring, and delay cost often exceeds the engineering investment within a planning cycle. Whether it does for you depends on ticket mix, wage cost, and which workflows are actually automatable. That is what discovery is for.
Curious what your ticket mix would free up? Bring volume and stack details to a short discussion.
Build vs buy
When custom software is the better economic decision
Sometimes an off-the-shelf product is the right answer. If a SaaS tool already covers your workflows, integrations, and approval model at an acceptable price, you should use it. Custom software is for when the work is specific enough that adapting the company to the tool costs more than adapting the software to the company.
Off-the-shelf SaaS
- Predefined workflows
- Recurring subscription
- Standardized integrations
- Limited customization
- The company adapts to the software
Custom implementation
- Built around existing workflows
- Integrates with systems you already run
- Custom business rules and actions
- Permissions and escalation you specify
- You own and control the implementation
- Optional maintenance after handover
We will say so if a packaged tool is the more honest recommendation. We are not trying to win a subscription comparison. We are trying to build the system your operations actually need.
Engagement
How the work is delivered without a big-bang bet
Implementation can proceed in slices: one high-volume workflow first, then the next, rather than requiring the entire support operation to change on a single go-live date.
- 01
Discovery
Channels, ticket mix, systems, constraints, and what “resolved” means for you.
- 02
Workflow audit
We map the actual steps agents take today, including the unofficial ones.
- 03
Opportunity selection
High-volume, well-bounded workflows first. Sensitive ones later, often in copilot.
- 04
Technical architecture
Integrations, permissions, data flows, failure handling, and audit approach.
- 05
Build and integration
The automation layer, the rules, and the connection to the live or staging systems you designate, with scoped credentials.
- 06
Testing
Replay real ticket shapes. Confirm actions, refusals, and escalations behave as specified.
- 07
Client feedback
Operations reviews the edge cases. Rules are adjusted before volume hits the system.
- 08
Deployment
Progressive rollout: copilot, then autopilot on eligible categories.
- 09
Optimization
Tune rules and coverage against live ticket mix after go-live. Optional maintenance if you want us to stay on.
We do not quote a universal timeline or a fixed package price on this page. Duration follows the number of systems, the clarity of the rules, and how many workflows you want in the first release.
Start with one workflow. Expand when it works. Book a call or walk through the demo.
Control
AI that can act on business systems needs brakes, not slogans
If software can issue a refund, it must also be possible to prevent it, inspect it, and hand it to a person. The implementation is designed around control, not around maximum autonomy.
Human approval where required
Copilot on any action you are not ready to run unattended: refunds, goodwill, identity edge cases, delivery disputes.
Permissions
The automation uses scoped API access. It should not have a broader role than the job you hired it to do.
Business rules
Policies live as explicit conditions. The model does not get to invent a refund exception because the customer asked firmly.
Auditability and logging
Decisions and side effects are recorded. You should be able to answer “why did this order change?” from the log.
Failure handling
If an API call fails halfway, the system should not pretend the action succeeded. Partial states escalate.
Escalation to humans
Low confidence, missing data, conflicting records, or out-of-policy requests go to an agent with context attached.
Data handling
We only connect to the systems and fields required for the workflows in scope. Data handling arrangements are agreed in the engagement, we do not publish blanket compliance badges we cannot substantiate here.
Monitoring
Operators need to see volume, automation rate, escalations, and errors. A silent integration is not a finished system.
Questions
Direct answers
Let's identify what your support team is still doing manually
Bring a ticket mix, a stack list, and the workflows you would most like to stop performing by hand. We will tell you what is realistically automatable, what should stay on copilot, and what is not worth building.