Cookbook
Capture your customer email automatically
Every CRM you have used had a mailbox sync. Indraft does not, and will not. Here is how you get the outcome anyway, and why the version you end up with is better than the one you had.
The situation
Your team emails customers all day. In a traditional CRM you connect the mailbox, a background job copies messages in, and every thread lands on the record. It is the single most-used integration in the category and the first thing anybody asks about.
Indraft never connects to your mail. Not as a limitation to route around but as a decision: connecting a mailbox means holding a credential that reads everything a person has ever written, including the messages that have nothing to do with customers, and copying the bodies into a second system that now has to defend them. We would rather not hold that, and you would rather we did not.
Which leaves the real question. The thing you actually wanted was never "copy my email into the CRM". It was "when I open an account I want to know what has been said". That is achievable without anybody handing us a mailbox, and the result is smaller, more useful, and quite a lot less frightening.
What must be true when you are done
- Opening an account shows what has been said, in order, in sentences.
- The job can run every night without duplicating a thing.
- Nothing holds a copy of the messages themselves. Indraft stores your agent's summary and, if you want it, one short quote.
- You can see which threads the agent logged and which it skipped.
Which side holds the credential
This is the part to get straight before anything else, because it is the whole security story.
Your agent reads the mailbox. It already has the access, because it is your agent: Claude with a mail connector, a script with an OAuth token you issued, an n8n workflow, whatever you already run. That credential belongs to you and stays with you.
Indraft receives sentences. It gets a summary, a timestamp, a message id, and what the thread is about. It never sees the body, never holds an attachment, and cannot go and fetch the rest, because it has nothing to fetch it with.
The practical consequence: if you turn the agent off, nothing continues reading your mail, and there is no third party to ask. If somebody compromises your Indraft workspace they get a list of summaries, not a mailbox.
What one message looks like
Your agent records an interaction per message. These are the fields that matter.
| Field | What it is for |
|---|---|
| externalId | The provider's own message id. This is the one that matters: it is what makes running the job twice safe. |
| provider | Where it came from. gmail, outlook, front, whatever you read. |
| direction | inbound or outbound. Who started it changes what the thread means. |
| occurredAt | When the message was sent, not when your agent got round to reading it. |
| subject | The subject line, as it was. |
| summary | What happened, in a sentence or two. Written by the agent, not pasted. |
| evidenceText | A short quote the summary rests on. Optional, bounded, and worth having. |
| contactIds, companyIds, opportunityIds | What the thread is about. An agent that already read the message knows this. |
The instruction
You
Every night, go through the customer threads in my inbox from the last day and log them in Indraft.
One interaction per message. Use the provider's message id as the external id and as the idempotency key, so running this again cannot duplicate anything. Set occurredAt to when the message was sent, not when you read it.
Summarise in one or two sentences: what they asked for, what was agreed, what happens next. Include one short quote as evidence where the summary rests on a specific phrase. Do not paste the message.
Match the sender to a contact by email address. If there is no contact, create one. If you cannot tell which account a thread belongs to, skip it and tell me at the end.
Mark everything as observed, because you read it.
Why the message id is the whole trick
The job runs nightly and your agent will see yesterday's messages again, because inbox queries overlap and because it will sometimes crash halfway and be re-run. Keyed on the message id, that is free:
Agent
The second run wrote nothing and told you which record the message already is, so the agent can still link a follow-up to a thread it logged last week. This is the difference between an idempotent job and one you are afraid to re-run: you can point it at the last thirty days after an outage and the only thing that happens is the messages you missed.
Reusing the same id for a materially different message is refused rather than applied, which is the case that would otherwise corrupt a thread quietly.
What you get that a mailbox sync never gave you
A traditional sync copies everything and leaves the reading to you. Six months in, an account has four hundred messages on it, and the question "what did we agree about pricing" is a search rather than an answer.
Here the agent has already read the thread, so what lands is the part that mattered. An account shows a dozen sentences instead of four hundred messages, and each one says who said what and when. The evidence quote keeps it honest: if a summary looks wrong you can see the phrase it came from.
Every one of those is marked as the agent's own observation, so you can always ask which of these a person has actually checked.
The two things worth deciding up front
What counts as a customer thread. Your agent needs a rule, and the rule should be conservative: threads with a contact you already have, or with an address at a domain you already have. Everything else it lists at the end rather than guessing. An over-eager first run that files an internal thread on a customer record is annoying to unpick.
How far back to go on the first run. Ninety days is usually enough to make an account feel populated without turning the first run into an afternoon. You can always widen it later, and re-running over a period you have already covered costs nothing.
Verify the job
- Run it twice in a row. The second run should report replays and write nothing. If the count of interactions goes up, the message id is not being used as the key and you will get duplicates forever.
- Open an account you know well. The thread you remember should be there, summarised in a way you would have written yourself. If the summaries are vague, the instruction needs to say what to capture, not the agent needs replacing.
- Read the skipped list. The threads the agent could not place are the interesting ones: usually a contact you never created, or a customer using a personal address.
Run it again
Nightly. This is the job where the schedule matters most, and it is the one job in this cookbook that should not sit on your agent's own scheduler.
Claude and ChatGPT will both run a task on a timer, and both will reach Indraft while doing it. Neither retries a run that failed and neither tells you it failed. For the Monday summary that is fine, because you notice the missing email and ask for it. Here, a run that quietly did not happen is a Tuesday with no conversations in it, and no later run goes back for Tuesday unless you make it.
So put this one behind something that retries and complains, which is what an automation tool is for and what your agent's scheduler is not. Then give it an overlap: ask for the last seven days rather than the last one, every night, on purpose.
You
The message id is the identity, so six of those seven days cost nothing and change nothing. A night that fails is covered by the next one before you have noticed. Where the schedule lives covers the wiring and what each agent's scheduler will and will not do.