Integrating Airkit.ai with Service Cloud

A service architect draws two boxes. One box says Airkit.ai. One box says Salesforce. An arrow joins them. The arrow has no noun. The room treats the arrow as a design. It is a poster. An integration names three things, or it is not an integration. The system that answers the customer. The object that answer must land on. The failure when the landing does not happen. Here the system is a service design in Service Cloud. The object is the Case. The failure is two service designs both answering the same case.

Salesforce completed the acquisition on 16 October 2023. The announcement placed the work in Service Cloud. That sentence tells you the home of the design. It does not draw a screen, and this page will not invent one. It does not name a connector, and this page will not invent one. Releases have landed since the close. A menu remembered from a demo is not a specification. The only sentence this page quotes from the announcement is the completion line. "Salesforce completed its acquisition of Airkit.ai on October 16, 2023."

#The system is the design that answers

Service Cloud is the system the announcement named. Inside it, more than one design can speak to a customer. A flow can send a message. A person on a queue can send a message. An older application, still running, can send a message. An agent built on the platform can send a message. Each of those is a service design. The integration question is which design is allowed to answer, for which contact, on which channel.

Airkit.ai built AI customer-service applications. After the close, that work sits in Service Cloud. Sitting in Service Cloud is not the same as being the only thing that talks. Your org already has macros, email templates, chat deployments, and people. Those are designs too. If you add another design and leave the old one live, you have two speakers. Two speakers are the failure this page is about. They are not a bonus.

Name the design in plain words before you name a tool. "The design that answers order-status on chat" is a system. "Airkit" on a box is a brand. The brand is real. The box is not an integration. Write the channel. Write the hours. Write the language. Write who may change the words the customer hears. That owner is part of the system. A design with no owner will drift, and a second design will be added to compensate. Compensation is how you get two answers.

Do not describe a current screen. If your org has a builder open, the people in the room can look at it. This page was not in that room. A screenshot copied from a slide is not your org. A setting name this page might remember from another product would be an invention. Leave the setting off the diagram. Put the behaviour on the diagram instead. Behaviour is what the customer receives, and what the Case stores.

#The object is the Case

The call lands when a Case holds the answer, the origin, and the next owner. Origin is the channel the customer used. The answer is the text or the outcome you are willing to stand behind. The next owner is a queue, a person, or a status that means a person will take it. If any of those three is missing, the call did not land. It may have been spoken. Speech without a Case is a conversation your organisation cannot audit.

Write the fields you already use. Record type. Origin. Reason. Status. The article you cited, if you cited one, stored as a reference your agents already understand. The handoff note, when a person must continue. You do not need a new object to prove the landing. A new object is a second system of record. A second system of record is how two designs start to disagree. Keep the Case you already report on.

A customer can have many Cases. The integration has to say which Case this contact belongs to. Matching on email alone will attach a new question to an old complaint. Matching on nothing will open a Case every time the customer says hello. Write the match. Write the rule for a second contact about the same order. The rule is either "add to the open Case" or "open a new Case and link it". Both can be right. An unstated third rule, in which both designs decide, is the failure.

History is not the live object. A file of old transcripts can sit in your archive. It is not a Case unless you map it to one, with a status that means closed, and a retention your policy allows. Do not let a diagram show old chats as if they were open work. Open work has an owner. An archive has a date.

#The failure is two designs on one Case

Picture a customer who asks where the order is. Design A replies with a date from the order system you named. Design B replies ten minutes later with a different date, because it read a different field, or because a person used a macro that still says the old shipping window. Both replies sit on the same Case, or they sit on two Cases the customer experiences as one. The customer now has two truths. Your queue has a complaint that the first design caused.

That is the failure. It is not a timeout, and this page will not invent an error code. It is a service design problem. Two designs were both allowed to answer. The integration did not say which one wins, and it did not say that the loser must stop. Stopping is a routing decision. It is also a content decision. The macro has to be retired, or limited to the queue, on the day the new design goes live. If the macro stays, you have two designs.

The same failure appears when a person and an automated design answer together. The person is not the problem. The person is the right design for the exception. The failure is the automated design continuing after the handoff. Write the field that means "a person owns this". Write that the automated design reads that field and stays quiet. If you cannot name the field, you cannot draw the integration. You can draw a poster of a bot and an agent. The poster will not tell you who spoke last.

A second shape of the same failure is two Cases. Design A opens a Case from chat. Design B opens a Case from the email the chat offered the customer. The customer told the story once. Your reports show two. Your queue works both. Deduplicating later is not an integration. The integration is the rule you write before go-live: one contact, one Case, one design allowed to answer until a person takes it.

#What the diagram has to show

Draw three labels, and refuse a fourth label you cannot source. System: the service design, on a named channel, in Service Cloud. Object: the Case, with the fields that prove the landing. Failure: two designs both answering that Case. Around those three, you may write the channel, the queue, and the order or identity system you already run, because those are yours. You may not write a connector product name. You may not write a screen. You may not write a daily cap. None of those appear in the source this page cites.

Read the diagram aloud. If you can say the three names without pointing at a logo, it is an integration sketch. If you need the logo to finish the sentence, it is a poster. Pin the sketch where the queue can see it. The queue will tell you when a second design is still talking. They hear it in the customer's second message.

The implementation page is where you price the path: channels, articles, queues, and the hours your own people spend. This page does not price it. Airkit.ai and Service Cloud is that scope. The ownership page is where you check the date and the fact that no end date was given. What happened to Airkit.ai is that page. Use them for those questions. Do not copy a screen from either of them onto this diagram. They do not publish one.

#What you refuse to invent

A connector name would make the arrow look finished. The source does not give you that name. Writing one would send a team to search for a package you have not verified. Leave the arrow as a behaviour: this design may create or update this Case, and the other design may not. How the platform implements that behaviour is a build choice made in your org, against the licences you already hold. This page has no fee, and it will not borrow one.

A current screen would make the workshop feel concrete. It would also be false if the screen has moved, or if your org has never turned it on. Describe the customer's sentence and the Case fields. A partner who needs a screen can open yours with you. They should not arrive with a picture of someone else's org.

A daily cap is a number. The source has no number. Your operations lead may know how many contacts a channel carries. That band belongs on the implementation brief, as your measurement, not as a limit this page invented. If you do not know the band, measure it. Do not fill the cell with a figure from a blog.

Identity and orders stay as systems you name. "The order system we already run" is enough until you write its real name in your brief. This page will not guess the vendor. Guessing the vendor is the same mistake as guessing the connector. Both send people to the wrong documentation.

#How you test that the call landed

Pick one contact type. Order status is enough. Run it on the pilot channel in a sandbox your service lead trusts. Send one customer sentence. Then check the Case, not the chat window. Is there one Case. Does it carry the origin, the reason, and the text you are willing to defend. Did a second design also write. If a macro, a person, and an automated reply all wrote, the test failed, even if the customer got an answer.

Run the test again after a handoff. A supervisor takes the Case. Send another customer sentence. The automated design should stay quiet. The person's reply should be the only new public comment. If both appear, the field that means "a person owns this" is not being read. Fix that before you add a second topic. A second topic multiplies the failure. It does not explain it.

Read five real handoffs from the pilot, with names removed if your policy requires it. You are looking for a second voice. A second voice is a sentence the customer did not need, from a design that should have stopped. Log it as a defect against the diagram, not as a training tip. Training the queue to ignore a second answer leaves the second answer in place.

Keep a way back for the channel. The way back is routing the contact to the design you had before, which is usually a person. Write who may invoke that routing. Write it as a change you have rehearsed. An integration that cannot be quiet is not ready for a Monday.

When the pilot topic is dull, add the next one. Dull means one Case, one public answer, and a queue note a person can use. Excitement in the first week is usually a second design you forgot to switch off. Switch it off. Then look at the Case again.

The voice path is a different integration. A caller who cannot see a form is not this diagram. Keep telephony off this page. The implementation page already tells you to keep that quote separate. This page agrees. One channel. One design. One Case.

#What good looks like on a Tuesday

A Tuesday contact about a shipping window produces one Case. The status shows whether the design finished or a person owns it. The article cited is the one the queue would have used. No second reply arrives from a macro. The customer does not receive two dates. The architect can point at the diagram and use the same three nouns the Case uses.

That is the integration. It is smaller than a platform story, and it is the story you can operate. If a later release changes a menu, your diagram still stands, because it never depended on the menu. It depended on the Case and on the rule that only one design answers.

Write the diagram in the brief before you ask a partner to build. Ask them to repeat the three names back. Ask them which design they will turn off. A partner who adds a connector name you did not supply has left the source. Send that name back. The work you want is the landing, visible on the Case, with one voice.