Build your first map
Solutions · Sales and CRM

Maplith for sales and CRM

The CRM is only as good as the keys that tie it to everything else: the customer in the shop, the company in the ledger, the yes in an email. Where those keys are names typed by hand, one customer becomes several and a deal closes days after the customer said yes. Your agent can see through it — if it knows which key joins what, and how far to trust it. Maplith gives it exactly that.
Build your first map, freeSee the workflows

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
One customer, several customer records
3 records for one customer · 4 orders spread across them
LinguaNord ApS · Fjeldrev Outdoor ApS
Where a customer’s facts liveCRMShopLedgerInboxNames typed by hand
Between the systems

Where it goes wrong

Recurring problems between the CRM and the systems a customer also lives in. Each was raised by a scan of a worked example’s exports.
01

One customer, several records

Every new email address becomes a new customer, and the order history and the newsletter consent split with it.
Fjeldrev Outdoor ApS · raised by a scan of its exports
02

The same customer, spelled differently in every system

The project system, the CRM and the ledger each spell the customer their own way, so any join between them by name is fragile.
LinguaNord ApS · raised by a scan of its exports
03

A deal that closes after the customer said yes

The CRM records the win two to six days after the customer accepted by email, so sales-cycle figures read from the CRM alone are late.
LinguaNord ApS · raised by a scan of its exports
Workflows

What your agent does about it

One workflow from the outdoor shop’s recorded scan. Everything in it ships today.
01In the worked example’s map

One customer, several customer records

The same person buys under several email addresses, and each becomes a customer of its own.
3 records for one customer · 4 orders spread across them
Workflow 01

One customer, several customer records

The same person buys under several email addresses, and each becomes a customer of its own.
Without Maplith
  • Trust the customer list, which counts one person as three.
  • Match people by hand, by name.
  • Apply consent to one address and not the others.
With Maplith
  • A finding naming the records and the orders spread across them.
  • The map: which key joins customers to orders and tickets.
  • A decision on merging, by the key’s policy.
  • A record of what was merged.
  1. FindingsThe records that are one person, the orders spread across them, and a recommendation.list_findings
  2. The mapEmail is the only key joining customers, orders and tickets — so any figure per customer carries the split.get_object
  3. AskWhich key identifies a customer, and what not to rely on, answered with citations.ask
  4. The action gateMerging customer records: a person approves each merge, if the business sets it so.request_action
  5. Record and valueWhat was done, so the next agent’s context shows it.record_action

Worked example: Fjeldrev Outdoor ApS

The full workflow, step by step

Without Maplith

The shop makes a new customer for every email address. In the worked example one person holds three customer records under three addresses, with four orders spread across them and the newsletter tag on only one. Every figure per customer — lifetime value, consent, order count — inherits the split, and no system shows it.

With Maplith

  1. Findings

    A scan of the exports raises it as a finding: the customer records that are one person, the orders spread across them, the tag applied to one of them, and a recommendation.

  2. The map

    The map shows that the email address is the only key joining customers, orders and tickets, so an agent reading a figure per customer knows the split travels with it.

  3. Ask

    ask: “which key identifies a customer here, and what should I not rely on?” — answered from the map, citing the objects and joins it rests on.

  4. The action gate

    request_action to merge the records, if the business declared that operation: the business decides per key whether a person approves each merge.

  5. Record and value

    record_action writes what was merged, so the next task context on the same thing shows it.

The pieces

What your agent calls

The map

live
Where each thing lives and how the systems join, with the rate Maplith measured for every join it could test.
get_object

Findings

live
Where the systems disagree, raised by a scan of the exports — each with the evidence it rests on and a recommendation.
list_findings

Ask

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

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
The worked examples

Where these come from

a translation agency

LinguaNord ApS

The findings and processes quoted from it come from a recorded scan of its exports. There is no public map or key for it.
About this worked example
a web shop selling outdoor gear

Fjeldrev Outdoor ApS

The findings quoted from it come from a recorded scan of its exports. There is no public map or key for it.
About this worked example

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 mapEvery department

Markdown version · Worked examples · Docs · llms.txt

May Maplith use the following? Nothing here is loaded until you accept. What we store