Solutions · Customer service

Maplith for customer service

A support answer needs facts from several systems at once: the order in the shop, the parcel at the carrier, the conversation in the helpdesk and the policy in a document. Your agent can put them together — if it knows where each one lives, how the business handles the case and whether it may act. Maplith gives it exactly that; your agent acts in your systems with your credentials.

Build your first map, free See the workflows

Acme Commerce is a fictional web shop built for our demo: the company, its people, its customers, the device brands, the suppliers and the competing chains are all invented, and nothing in the data comes from any customer. LinguaNord ApS is a fictional translation agency built as our first test company: the company, its people, its customers and its translators are all invented, and nothing in the data comes from any customer. Fjeldrev Outdoor ApS is a fictional web shop built as a test company: the company, its people and its customers are all invented, and nothing in the data comes from any customer.

The workflowsfigures from the worked examples

A parcel is late: tell the customer before they ask: Worked example: 859 where-is-my-order conversations in a year
A support agent asks the map how to handle a case: 6 late refunds paid with no exception recorded

Acme Commerce · LinguaNord ApS · Fjeldrev Outdoor ApS

Where a support answer’s facts liveHelpdeskShared inboxShopCarrierPolicies nobody opens

Between the systems

Where it goes wrong

Recurring problems between the systems a support team works in.

Emails that never become cases

Customers write to a shared inbox, and the helpdesk only knows what someone copies into it. In one worked example three customer emails got no reply and never became a ticket; in another, three enquiries to the shared inbox got no reply at all. In both, a scan of the exports raised it as a finding.

Fjeldrev Outdoor ApS and LinguaNord ApS · raised by a scan of their exports

A policy the case never meets

The returns policy is a document; the refund is a button in the shop. In the worked example six refunds were requested 44 to 62 days after delivery, against a 30-day window, and paid with no exception recorded.

Acme Commerce · in its exported data

Workflows

What your agent does about it

Both workflows below are told in full on the e-commerce page, where their worked example lives. The late parcel starts with live rules, which are in early access and being built now; everything else ships today.

01Pattern · uses watches

A parcel is late: tell the customer before they ask

An order misses its delivery promise; the customer has not written yet.

Worked example: 859 where-is-my-order conversations in a year

02In the worked example

A support agent asks the map how to handle a case

A customer wants to return an item after the window has closed.

6 late refunds paid with no exception recorded

Workflow 01

A parcel is late: tell the customer before they ask

An order misses its delivery promise; the customer has not written yet.

Without Maplith

The helpdesk hears about a late parcel when the customer writes.
Find the order in the shop, the delivery in the carrier’s data and the customer in the helpdesk, by hand.
Answer after the customer is already worried.

With Maplith

A live rule reports the order that crossed the line (early access).
A route from the order to the conversation, with the rate of each hop.
The playbook for delayed parcels, inside the task context.
A reply whose approval the shop decides per key.

Live rulesMaplith compiles what counts as late; the shop’s shipping automation reports the order that crossed the line.early access
SignalsWith live rules, the observation becomes a signal for that order.list_signals
RouteFrom the order to the helpdesk conversation: which system, by which key, the measured rate of each hop.route
PlaybooksThe shop’s own words on what to say and what to offer, inside get_task_context.
The action gateReply to the case: per key, a person approves every message, or only those whose offer is above a limit.request_action
Record and valueWhat was sent; the action log shows the request, the decision and the outcome.record_action

Worked example: Acme Commerce · told in full on Maplith for e-commerce

The full workflow, step by step

Without Maplith

The helpdesk hears about a late parcel when the customer writes. In the worked example, where-is-my-order is the most frequent tag in the helpdesk export — on 859 conversations over the year. Each answer means finding the order in the shop, the delivery in the carrier’s data, the customer in the helpdesk and the tone the shop uses, by hand, after the customer is already worried.

With Maplith

Live rules · early access
Maplith compiles from the map what counts as late for this shop; the shop’s own shipping automation checks it and reports back the order that crossed the line — an observation, not a copy of the order.
Signals
With live rules, Maplith turns the observation into a signal for that order.
Route
route from the order to the helpdesk conversation tells the agent which system holds each, by which key, and the rate Maplith measured for each hop. The agent reads the order and the customer in those systems, with its own credentials.
Playbooks
The playbook for delayed parcels — the shop’s own words on what to say and what to offer — arrives inside get_task_context.
The action gate
request_action to reply to the case: the shop decides per key whether a person approves every message, or only those whose offer is above a limit.
Record and value
record_action writes what was sent; the action log shows the request, the decision and the outcome.

Workflow 02

A support agent asks the map how to handle a case

A customer wants to return an item after the window has closed.

Without Maplith

Know that the returns policy exists, and find it.
Find the order and its delivery date.
Decide alone whether a late return is an exception.

With Maplith

The returns playbook, drafted from the shop’s own policy.
An answer on where the delivery date lives, never from rows.
A person’s approval, when the shop sets refunds to need one.
A record of what was done and who approved it.

PlaybooksDrafted by Maplith from the shop’s returns policy and put in use by an admin; it reaches the helpdesk’s AI over MCP or as a skill file.
AskWhere the delivery date for an order lives and what to check first, answered from the map, never from rows.ask
RouteFrom the conversation to the order: where the delivery date lives, by which key.route
The action gateWith refunds set to need approval, the request waits until a workspace admin decides. Maplith never issues the refund.request_action
Record and valueWhat was done; the action log shows who approved it.record_action

Worked example: Acme Commerce · told in full on Maplith for e-commerce

The full workflow, step by step

Without Maplith

A customer asks to return an item 50 days after delivery. The policy says 30 days, with an exception only when the customer service lead tags the conversation and writes the reason. In the worked example six refunds were requested 44 to 62 days after delivery and paid anyway, with no exception recorded; nine other late requests were refused, as the policy says. Without a map, a support agent — a person or an AI — has to know the policy exists, find it, find the order and its delivery date, and decide alone.

With Maplith

Playbooks
The returns playbook — drafted by Maplith from the shop’s own returns policy and put in use by an admin — reaches the helpdesk’s AI as an MCP prompt or resource, or as a skill file.
Ask
ask: “where do I find the delivery date for an order, and what do I check before a late return?” — answered from the part of the map the key may see, never from rows.
Route
route from the conversation to the order says where the delivery date lives and by which key; the agent reads it in the shop.
The action gate
A refund outside the window is an exception. The shop sets issuing a refund to need a person’s approval — always, or above an amount — so the request waits as pending until a workspace admin decides, and the agent learns the decision by asking again. Maplith never issues the refund: the agent does, when the answer is yes — and where Maplith signs grants, with a grant bound to that order and amount.
Record and value
record_action writes what was done; the action log shows who approved it.

The pieces

What your agent calls

Signals

live

What needs doing, as typed events to poll instead of re-reading the map.

list_signals

Ask

live

One question in plain language, answered from the map with citations — never from rows.

ask

Route

live

The shortest verified join path from a start object to a target: which system, which key, how much to trust each hop.

route

Playbooks

live

How the business handles it, in its own words — as MCP resources, prompts and a skill file.

The action gate

live

Allowed, pending a person, or denied — before the agent acts, with a grant good once.

request_action

Record and value

live

What was done, so the next judging does not raise it as though nobody had looked — and counted in “What you got”.

record_action

Live rules

early access

Maplith compiles what to check live; the business’s own automation reports only what it observed; Maplith turns it into a signal within minutes.

The worked examples

Where these come from

a web shop selling phone and tablet accessories

Map your exports. The first map is free.

Your systems stay the source of truth; your agent acts in them with your credentials.

Build your first map Every department

Markdown version · Worked examples · Docs · llms.txt