Crisp and CodeWords: automating the work around customer conversations

Crisp puts every customer conversation in one inbox, which solves the problem of messages arriving in five places. What it does not solve is everything that happens either side of the conversation: working out which ones matter, getting the right context in front of whoever answers, and making sure what was agreed actually reaches the systems where it has to happen.

This page covers the automation worth building around Crisp, what the API reaches, and where a person should stay firmly in the loop.

What we'll cover

• Where the time actually goes
• What the Crisp API reaches
• Connecting it to CodeWords
• Six automations worth building
• Where a person has to stay
• Building it so it survives
• Limits worth knowing about
• Frequently asked questions

Where the time actually goes

Support teams rarely lose time to typing. They lose it to everything surrounding the reply.

Working out what a message is about. A shared inbox arrives unsorted. Somebody reads each one to decide whether it is a bug, a billing question, a sales enquiry, or a person who needs their password resetting.

Assembling context. Answering properly means knowing what this customer pays for, what they last bought, whether they have an open issue elsewhere, and what they asked last time. That is three tabs before anyone types a word.

Getting the outcome recorded. A conversation ends with something agreed — a refund, a bug to file, a feature request worth noting. Whether that reaches the ledger, the tracker, or the roadmap depends on somebody remembering.

Answering the same thing repeatedly. Every support inbox has a handful of questions that arrive weekly and have a settled answer.

Noticing patterns. Five people asking about the same thing in a week is a signal, and it is invisible when each is handled individually by whoever picked it up.

What the Crisp API reaches

Conversations can be listed, read, and updated, including their state, and messages can be sent into them. This is the core of any support automation.

Messages within a conversation can be read and created, with the sender type distinguishing an operator from the customer.

People are Crisp's contact records, with profile data and custom fields that can be read and written. This is where enrichment from other systems belongs.

Segments and data attached to a conversation let you tag and classify, which is how routing decisions get recorded rather than held in someone's head.

Webhooks fire on message received, conversation state changes, and similar events, which is what allows an automation to react the moment something arrives.

The useful shape: you can read everything, write context onto records, classify conversations, and post messages. That last capability is the one to be careful with, and the section on human involvement covers why.

Connecting it to CodeWords

CodeWords connects to more than 3,000 integrations, and the connection is made once and reused.

1. Open CodeWords and start a new automation.
2. Describe what should happen in plain language to Cody, the automation builder, naming Crisp and the other systems involved.
3. Authorize the connection when prompted. Crisp authenticates with API identifier and key credentials from your account settings, scoped to a website.
4. Describe the exceptions alongside the happy path: an unknown contact, a conversation already assigned, a downstream system that is unavailable.
5. Run it against real conversations in a test website before pointing it at production.

You describe the outcome; Cody builds it, connects it, and deploys it. When the process changes you describe the change. The free plan covers light use, with Pro at $39 per month and Business at $100 per month as usage grows; details are on the pricing page.

Six automations worth building

Classification and routing. Read an incoming message, decide what it is about and how urgent it is, tag the conversation accordingly, and assign it to the right person or queue. This is the highest-return automation in support and the easiest to verify, because a wrong routing decision is visible and cheap to correct.

Context assembly. When a conversation opens, pull what you know about that person from your billing system, your product database, and your issue tracker, and write a summary into the conversation as an internal note. The person answering starts informed instead of starting with three tabs.

Escalation on signal. A conversation from a high-value account, or one where the customer has come back a third time, or one where the tone has clearly deteriorated, raised somewhere a human will see it promptly rather than sitting in queue order.

Outcome capture. When a conversation is resolved, extract what was agreed and create the corresponding record: an issue in your tracker, a note on the customer, a row in a refunds log. This is the one that stops things being forgotten.

Weekly theme digest. Group the week's conversations by topic and report the shape: what came up most, what was new, what is trending upward. Individually handled tickets hide patterns that are obvious in aggregate.

Draft replies for review. For the questions that recur, prepare a draft answer with the customer's specifics filled in, and leave it for an operator to read and send.

Where a person has to stay

Worth being explicit, because the temptation with a support inbox is to let the automation answer.

Anything that commits you. Refunds, discounts, deadlines, and promises about what the product will do. An automation may prepare these; a person should approve them.

Anything where being wrong is expensive. Account changes, cancellations, and anything touching money or access.

Complaints and anything emotionally charged. A frustrated customer receiving a machine-generated reply becomes a more frustrated customer, and the cost of that is not visible in your resolution metrics.

Anything the classifier was uncertain about. The useful pattern is to act automatically where the classification is clear and route to a person where it is not, rather than choosing one mode for everything.

Distinguish three things that get lumped together as "handoff": giving a customer contact instructions, notifying an owner with a summary, and transferring to a verified operator. They have different costs and different failure modes, and an automation should be specified in terms of which one it is doing.

Building it so it survives

Make it safe to run twice. Webhooks retry. An automation that posts a message needs a guard, or a customer receives the same reply twice and the conversation looks unattended.

Decide what happens on an unknown contact. Create the record, proceed without enrichment, or flag it. All defensible; no answer means a failure at the worst moment.

Report the outcome. A daily line confirming how many conversations were classified and how many were routed to a person is what makes silence meaningful.

Keep one automation to one job. Classification, enrichment, and outcome capture are three automations, not one, and separating them means a failure tells you which part broke.

Log what the classifier decided and why. When somebody questions a routing decision three weeks later, that log is the difference between an answer and a shrug.

Measuring whether it helped

Support automation is unusually easy to fool yourself about, because the metrics that improve first are not the ones that matter.

Resolution time falls whether or not anything improved, since routing a conversation faster moves the clock without changing the answer. Track time to useful reply rather than time to first touch.

Reopen rate is the honest number. A conversation resolved and then reopened by the customer was not resolved. If automation is pushing resolution time down while reopens climb, it is producing speed rather than answers.

Check the routing accuracy monthly. Sample twenty conversations and ask whether each went to the right place. This takes ten minutes and catches drift that no dashboard will show you, particularly after you have changed the classification rules.

Watch what your team stops doing. The clearest signal that context assembly is working is that people stop opening the billing dashboard before replying. If they are still opening it, the summary is not carrying what they actually need, and the fix is to ask them what is missing.

Count what went to a person and why. A system that routes ninety percent to humans has not saved much. One that routes two percent may be acting confidently on cases it should not. The proportion is a dial worth watching rather than a number to optimize.

Limits worth knowing about

Rate limits apply, so bulk operations across conversation history need pacing rather than a tight loop.

Message ordering at speed. An automation that posts while a customer is typing can produce an odd sequence. Where timing matters, check conversation state before posting.

Credential scope. Crisp credentials are scoped to a website, so an automation covering several properties needs that handled deliberately rather than assumed.

Personal data. Support conversations contain a great deal of it, often including things customers did not intend to share. Copy what the process needs rather than everything available, and keep retention in mind, since every field you write elsewhere is a field subject to a deletion request.

Frequently asked questions

Can an automation reply to customers directly?

Technically yes, and the question worth asking is which messages should. Recurring factual questions with settled answers are reasonable candidates. Anything that commits you, involves money, or arrives from an unhappy customer should be prepared and reviewed rather than sent.

How accurate is automatic classification?

Good enough to route with, on most support inboxes, and worth measuring rather than assuming. Run it alongside your existing process for a fortnight and compare what it decided against what people decided. That gives you a real number on your own data, which no benchmark will.

What happens when a customer writes in a language we do not support?

Classification generally copes; replying is the question. Detect the language, route to whoever can answer, and be careful about automatic translation for anything binding, since a mistranslated commitment is still a commitment.

Can I connect Crisp to our issue tracker?

Yes, and outcome capture is one of the better reasons to automate support at all. A resolved conversation that mentions a bug can create the issue with the relevant transcript attached, which stops reports being lost between the inbox and the backlog.

Does this replace Crisp's own automations?

No, and it is not meant to. Crisp's built-in triggers handle things inside Crisp well, and you should use them where they suffice. The reason to reach outside is when the logic depends on data Crisp does not hold, which is most of the interesting cases.

How do I stop an automation from making support feel automated?

Put it on the work around the conversation rather than on the conversation itself. Context assembly, routing, and outcome capture are invisible to the customer and make the human reply faster and better informed. That improves the experience; a machine-written reply usually does not.

What should I build first?

Classification and routing, because the output is immediately visible, a mistake is cheap, and it removes the daily triage that nobody enjoys. Context assembly is a natural second, since the routing work has already taught you which systems hold the useful data.

Can I use this alongside Crisp's own chatbot?

Yes, and the boundary is worth drawing deliberately. Crisp's bot handles scripted flows inside Crisp well. An external automation is the right tool when the decision depends on data Crisp does not hold, or when the outcome has to land in another system. Running both without deciding which owns what produces conversations where two things try to reply.

How much history should the automation look at?

Enough to see the pattern, which for classification is usually the current conversation plus whether this person has written before. Pulling a customer's entire history into every classification is expensive and rarely changes the decision. Where history matters, the useful signal is generally recency and repetition rather than volume.

Related reading

• Intercom and CodeWords
• Freshdesk and CodeWords
• CodeWords integrations and templates