# Maplith for customer service

How the AI agent a support team already uses answers by the business’s own policy, asks before it refunds and — with live rules, in early access — tells a customer about a late parcel before they ask; each workflow a before and after, shown on fictional companies’ exports.

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.

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.

## Between the systems

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

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.

### 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. 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:**

1. **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.
2. **Signals** — With live rules, Maplith turns the observation into a signal for that order.
3. **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.
4. **Playbooks** — The playbook for delayed parcels — the shop’s own words on what to say and what to offer — arrives inside `get_task_context`.
5. **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.
6. **Record and value** — `record_action` writes what was sent; the action log shows the request, the decision and the outcome.

Worked example: [Acme Commerce](/industries#acme) — told in full on [Maplith for e-commerce](/industries/e-commerce#late-parcel).

### 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.** 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:**

1. **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.
2. **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.
3. **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.
4. **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.
5. **Record and value** — `record_action` writes what was done; the action log shows who approved it.

Worked example: [Acme Commerce](/industries#acme) — told in full on [Maplith for e-commerce](/industries/e-commerce#support-case).

## The pieces

| Piece | Tool | What it gives the agent | Status |
|---|---|---|---|
| Signals | `list_signals` | What needs doing, as typed events to poll instead of re-reading the map. | live |
| Ask | `ask` | One question in plain language, answered from the map with citations — never from rows. | live |
| Route | `route` | The shortest verified join path from a start object to a target: which system, which key, how much to trust each hop. | live |
| Playbooks | — | How the business handles it, in its own words — as MCP resources, prompts and a skill file. | live |
| The action gate | `request_action` | Allowed, pending a person, or denied — before the agent acts, with a grant good once. | live |
| Record and value | `record_action` | What was done, so the next judging does not raise it as though nobody had looked — and counted in “What you got”. | live |
| Live rules | — | Maplith compiles what to check live; the business’s own automation reports only what it observed; Maplith turns it into a signal within minutes. | early access |

## The worked examples

- **[Acme Commerce](/industries#acme)**, a web shop selling phone and tablet accessories. Its situations are in twelve months of exported data, checked against the files by a script with no model involved. These pages say what is in the data, and publish no score for what a scan of it finds. [Maplith for e-commerce](/industries/e-commerce).
- **[LinguaNord ApS](/industries#linguanord)**, a translation agency. The findings and processes quoted from it come from a recorded scan of its exports. There is no public map or key for it.
- **[Fjeldrev Outdoor ApS](/industries#fjeldrev)**, a web shop selling outdoor gear. The findings quoted from it come from a recorded scan of its exports. There is no public map or key for it.

Every department: [Solutions](/solutions). The worked examples: [Worked examples](/industries).