Should I migrate from Airkit.ai

A service director has two designs on one whiteboard. One is the case path the queue already runs. The other is a list of topics from an application the team used before the acquisition. Someone has drawn an arrow from the list to the case and written migrate. The arrow does not say which design answers the customer. If both answer, the customer can receive two replies, and the queue cannot tell which reply is the record. The decision on this page is whether to migrate. It starts by naming one design. If you cannot name it, you do not migrate it.

Airkit.ai built customer-service applications. Salesforce completed the acquisition. The announcement placed that work in Service Cloud. What the software is now, on the evidence this page will use, is that placement. It is not a menu. This page does not describe a current screen. Releases have landed since the close. A remembered demo is not a specification you can migrate onto. The only sentence this page quotes from the announcement is the completion line. "Salesforce completed its acquisition of Airkit.ai on October 16, 2023."

#Should you migrate

Migrate when you can point at one service design and say what it does on a Monday. The channel is chat, email, or messaging, and you already run it. The design writes a Case. The Case has an origin, a reason, a status, and an owner. A queue receives the contact when the design stops. An article, if the design cites one, has a person who can change it. That is a design you can name. You can then write the path in records and make every other speaker silent for that same case.

Do not migrate a topic list. A topic list is a set of labels. Labels do not say who answers, what they may say, or where the exception goes. A partner who prices the list has skipped the design. Keep the list as a clue about what someone once tried to automate. Put the design in the brief, or accept that you are not migrating yet. You are still deciding which case is in scope.

The acquisition does not, on this page, force the move. The cited page does not publish a shutdown date. You are not late against a quarter this page invented. You are early if you move a design you cannot describe. Stay on the path the queue already trusts until the new path is written down, including the hour you can switch the channel back. A date on a programme plan is your date. It is not a date from the announcement.

#Two designs must not answer the same case

A case is one issue. One design answers it. A second design that also answers it is not a backup. It is a conflict. The customer hears two voices. The record shows one owner, or it shows a scramble. Agents then spend the contact working out which answer was real. That work is the cost of a move that did not choose.

Before you move anything, list the designs that can already speak on that channel. A macro. An email template. A person on the queue. A flow that sends a message. An older application you have not switched off. If two of them can answer where the order is, you already have the failure. Adding another speaker will not repair it. Pick one. Write the others down as silent for that case. Silent means they do not send the reply. It does not mean you delete history.

If you cannot name the design you intend to migrate, stop. An unnamed design will be rebuilt from memory, and memory will collide with the design you already run. The collision is two answers to one case. The rule is easy to skip when a slide says all topics. All topics is how the second design arrives without a name. Name a handful of topics for a pilot, on one channel, and mark the rest as later. Later is a decision. It is not a failure to be brave.

#What the software is now

Salesforce owns Airkit.ai. The completion date is 16 October 2023. The announcement placed the work in Service Cloud. That is the current fact this page will stand on. It will not add a product name for a screen it has not been shown. It will not add an end date. It will not add a price. The cited page does not publish a price. Your licence cost, if you pay one, lives on your contract. It does not live on this page.

What the software is now is not a picture of the application as it looked on the day of the close. For a buyer, it is a service capability whose home was named as Service Cloud, scoped from the channels and cases you run today. If your org still has a login under the old brand, that login is an operational fact for the person who owns it. This page will not redraw it. If your org does not have that login, do not invent one in the plan so the slide has a box.

#The three pages, and the jobs they refuse

This page answers whether you should migrate, what the software is now, how that compares with the native Case, and which alternatives sit beside each other without a rank. It does not price the build. It does not narrate the close beyond the date and the home. It does not pretend an integration is done because two logos share a slide.

The implementation page is Airkit.ai and Service Cloud. Use it when the question becomes a quote: channels, Case fields, knowledge, and the queue a person still owns. The what-happened page is What happened to Airkit.ai. Use it for ownership, the date, the blank price, and the absent end date. The integration page is Integrating Airkit.ai with Salesforce. Use it when you need the failure named as two designs answering the same case, and the object named as the Case. A brief that asks this page for a fee, the implementation page for a purchase price, or the integration page for a menu, has picked the wrong job.

#Versus the Case you already have

A Case already records one customer issue. It stores an origin, which is how the contact arrived, using the channels your org has configured. It stores a status, which is where the issue sits, in the values your service team defined. It stores an owner, which is a user or a queue. It can relate to a Contact and an Account. It can hold comments a colleague can read. It can be linked to a Knowledge article a person published, with that article's own owner and publication status. It can sit against an entitlement if you already use entitlements. That is the native object. It already answers a plain operational question: what is this issue, and who has it.

Only after that description does a comparison count. Airkit.ai answered customers through service applications organised as topics. A topic is not a Case. A topic is a migration only when you name the Case it writes, the fields it fills, the article it may cite, and the queue it uses when it stops. If you skip that naming, you have placed two brands in a table. Brands do not answer the customer. The Case does, or a design that writes one Case does.

Native features already cover the record, the queue, and the published article. They do not know your shipping window, your refund rule, or the identity check you accept. Those are your content. Moving from the acquired application does not install that content. You bring it, or you do not yet have a design worth migrating. A comparison that calls the Case empty has forgotten what the Case is for. It is a record with an owner.

#What you must not move

Do not migrate a case design you cannot name. If the brief says the bot, ask which channel, which reason, and which queue. If nobody in the room can answer, the design is not ready. Leave it off the move. You can still keep old transcripts as files, under a retention rule your counsel already uses. An archive is not a live design. Do not turn the archive into a second speaker that replies because the text is still in a folder.

Do not let two service designs both answer the same case, including during a pilot that was meant to feel safe. The old design is off for the cases in the pilot, or the new design is off. Both on is the failure mode. Write the switch as a routing change you have rehearsed on the channel you picked. Write who may turn it back, and what a customer in mid-conversation is told. An unrehearsed reversal is how the second design returns on a Friday afternoon.

Do not describe a current screen in the plan. A step that depends on a button nobody has opened is a story. The sequence further down is a set of decisions on paper.

#Alternatives, without a rank

People search for alternatives after the acquisition, and for an alternative on AppExchange. This page has not been shown an AppExchange listing. It will not invent a listing, a rating, or a rank. Alternatives are ways to do the service job. They sit beside each other. This page does not order them, and it does not call one of them the destination.

One way is to stay with the Case design the queue already runs, and to treat the acquired brand as history rather than as a rebuild. Another way is to move one named design onto the Case, the article, and the queue, and to make every other design silent for that case. Another way is to keep a service application you still operate, if you truly still operate one, and to integrate only the handoff described on the integration page. Another way is to choose a different service tool under your own evaluation, with your security review and your contract, outside any claim this page makes.

None of these is placed first. A proposal that ranks them has added a judgement this page will not sign. Your constraints select a way. Can you name a design. Does a Case already answer that case. Do you still have a separate application with an owner. If you cannot name a design, staying is the way that does not invent one. That is a gate. A gate is not a ranking of products.

#A walkthrough you can finish on paper

A search for a migration walkthrough often expects clicks. This page will not provide clicks. It has not been shown a screen to click. Finish the sequence on paper before anyone opens a setup page in an org.

Write the case in the customer's words. Write the channel. Write the Case record type and the reason. Write the fields the design must fill, and the fields it must not change, especially anything that moves money. Write the article title and the person who may edit it. Write the queue and the hours it is staffed. Write every design that can currently answer this case, and mark all but one as silent. Write the history you will keep, and whether it is a file or a Case. Write the way back for that channel. Stop when a line is blank. A blank line means you are not ready to migrate that design. You are ready to book the hour that fills the line.

Take a complete sheet to the implementation page. Leave price and shutdown blank, and point those questions at the what-happened page. Take the failure mode, two designs answering one case, to the integration page. The test fails when a second reply goes out. The sequence does not include a screenshot, a fee, or a sunset quarter.

#The first fortnight after you do move

If you pass the gates and move one design, judge the fortnight by the queue's notes, not by a count of contacts deflected. Read the handoffs. A useful note says what was asked, what was read, and why a person now has the case. An empty note means the customer will repeat themselves. That is the old contact, done twice, which is not a successful move.

Keep the second design silent for the whole fortnight. If someone switches it back on because a count dipped, you are back to two answers. A dip is a finding. It is not permission to restore a second speaker. Add a second case only when the first note is full and the article is the one the queue would have used.

Bring the table to the meeting. If a row fails, you are not migrating. You are still naming the design. A move that starts before the table passes will create a second answer. The implementation page can price a named design. It cannot price a collision. Fix the collision on paper, then ask for the quote.