Airkit.ai and Service Cloud: what belongs on the quote

A service manager pastes a spreadsheet into a brief and asks for an Airkit.ai data migration quote. The sheet has topic names, a channel column, and a note that says the bot should handle it. It has no Case record type. It has no queue. It has no article. A fee built from that sheet is a guess. The organisation already runs service, or it is about to. People still take the work a topic could not finish. Those people are the scope. The spreadsheet is only a clue about what someone once tried to automate.

Airkit.ai built AI customer-service applications. The announcement said the company would become part of Service Cloud. That sentence places the work. It does not draw a screen, and this page will not invent one. Releases sit between the close and a quote written now. Scope from the org you have and from the channels you still run. The line you can date is short. "Salesforce completed its acquisition of Airkit.ai on October 16, 2023."

#A topic name is not a scope

Take one row that every service team recognises. The customer asks where the order is. In the old application that question was a topic. In Service Cloud it is a path with an owner at each step. Someone collects an order number and an email. Something reads the order. A Case opens with an origin, a reason, and a status. An article covers the shipping window the business is willing to state. A queue receives the contact when the order system returns nothing, when the email does not match, or when the person asks for a person.

If the spreadsheet only says "order status", you cannot price the path. You can price a workshop that writes the path down. Those are different purchases. Put the workshop in the quote as time. Put the build in the quote only after the path has owners. A partner who prices the build from the topic name has skipped the only page that makes the number real.

Write the path in the language of records. Origin is chat, email, or messaging, and you already know which of those you pay to run. Reason is a value your agents already use, or a value you are about to add, and adding a value is a small change with a report that must be updated. The article has an owner who can change the shipping window without a release. The queue has a roster. If any of those four is missing, the topic is a label. Labels migrate in an afternoon. Service does not.

The same test applies to a complaint, a return, and a password reset. Each one looks small on a slide. Each one hides a rule about identity, a rule about money, or a rule about who may see the account. List the rule before you list the topic as in scope. A topic with no rule is a conversation you have not designed. You can still migrate the history of those conversations, as text on a Case or as a file your policy allows you to keep. History is an archive. It is not the new path.

#What the quote has to name

Ask for a quote only after the brief can answer a short set of questions in your own nouns. Which channels are live, and which are wished for. Which Case record types the work will use. Which entitlements or milestones already run, if you use them. Which knowledge articles are current, and who is allowed to publish. Which queues exist, and which hours they cover. Which systems must be read before a person can answer, named by you, such as the order system or the identity provider you already operate.

Add the refusals. The agent, or the flow behind it, may collect a return reason and must not issue the refund. It may read a shipping status and must not invent a date. It may offer a person and must not argue. Write the refusals as behaviour, with the field that records the handoff. A refusal that lives only in a slide will be priced as if it were already built, and then discovered in the first week of real contacts.

Volume belongs on the brief as a band you fill in, not as a figure this page supplies. Contacts a day, by channel. The share that already reaches a person. The topics that dominate the week. Your operations lead knows these bands. A partner needs them to staff the work and to choose what to pilot. A partner does not need a borrowed rate from another company's traffic. If you do not know the band, the first line of the quote is the time to measure it.

#What cost means before anyone prices it

Cost, on this page, is the list a buyer should finish before asking for a number. Start with the licences you already hold. Service Cloud is the home the announcement named. Digital engagement, voice, or an agent licence may already be on the contract, or may be absent. Name each product you pay for. Leave the price cell blank until your own agreement is open. This page has no fee schedule, and a fee schedule from another org would be the wrong schedule.

Then list the work. Design of the paths. Build of the actions, flows, and articles. Integration to the systems you named. A sandbox that matches the sharing rules you intend to run, not a wide-open copy. Training for the people on the queue. Internal hours for the service lead, the admin, and the person who owns the articles. Cutover, including the hour you stop the old application and the hour you can start it again if the new path fails. Hypercare for the first weeks, with a named person reading the handoffs.

Put out of scope in the same list. A full rewrite of every macro. A new telephony platform. A commerce rebuild. A promise that every old topic becomes an autonomous action. Those projects can be real. They are separate quotes. Folding them into an Airkit.ai line makes the number large and the acceptance test vague. A vague acceptance test is how a project ends in a dispute about what "migrated" meant.

Internal hours are part of the cost even when a partner's fee looks tidy. Someone must confirm that the article is still true. Someone must sit with the queue and read twenty handoffs. Someone must decide that a topic stays with a person. If those hours are missing from the brief, the quote will assume they are free. They are not free. They are the reason the path matches the business.

#Migration services, stated as records

Migration here means a map, not a slogan. For each topic you keep, name the record it writes, the fields it must fill, the article it may cite, and the queue it uses when it stops. For each topic you drop, say so, and say what the customer hears instead. For history, name the retention you are willing to keep and the object that will hold it. A file of old transcripts is a different object from a live Case. Treat it as a different line.

A paste of topic names into a new instruction recreates a menu. Service Cloud can hold a menu. It can also hold a Case, an entitlement, and a person. If the point of the move is the menu, say that, and price a small configuration. If the point of the move is that a person receives a better handoff than they did last year, price the handoff. The two projects use the same brand name in a search box and almost nothing else in common.

Channels need their own lines. Chat that already runs on a website has a deployment, a security setting, and a pre-chat form. Email-to-case has a routing address and a set of filters. Messaging has a consent and a template problem that email does not. A single "channel migration" row hides three designs. Split them. Then ask which one is the pilot. A pilot on one channel, with five topics, is a scope a team can finish and judge. A pilot on every channel is a launch with a softer name.

Identity sits underneath all three. How do you know the person is the customer. What you ask for. What you do when the answer fails. A service application that skipped this step will have taught customers to expect an answer anyway. The new path has to be stricter or it has to be explicit that it is not. Write that choice. It changes the build, and it changes the training, because the queue will hear the people who fail the check.

#The hiring test

People search for the best Airkit.ai Salesforce integration agency, and for a consultant to hire. Treat the adjective as a request for a test. Run the test on one live topic before you sign a statement of work. Hand the partner the topic, the channel, and nothing else. Ask them to write the Case fields, the article, the stop, and the queue. Ask them what they will not build. Ask them which licence they need to see on your contract before they estimate. Ask them who on your side accepts the cutover.

A pass names owners. The Case has a record type. The article has a person. The queue has a roster you already recognise. The stop is a field, not a mood. The partner asks for the bands you have not supplied. The partner refuses to describe a product screen they have not been shown, and refuses to price the work from a topic list alone.

A fail quotes a fee from the spreadsheet. It promises that the old topics will behave as they did. It walks you through a menu nobody in the room can open. It calls itself the best agency, or it asks you to take that on trust. Confidence is not a deliverable. The deliverable is the path, written in records, with your nouns in it.

Use the same test on a second topic that involves money, such as a refund request. The partner should slow down. The handoff should be obvious. If the second topic is priced as a copy of the first, the partner has not noticed that money is a different owner. You want that notice before the build, while changing the scope is still a sentence and not a change request.

#Cutover is a queue, not a flip

Plan the cutover as a service change. Pick the channel. Pick the hour. Tell the queue what the note on a handoff will contain. For the first days, read every handoff on the pilot topics, not a dashboard. A dashboard can say that volume moved. It cannot say that the note was empty. An empty note is the old contact, done twice.

Keep a way back for that channel. The way back is a routing change you have rehearsed, not a hope that the vendor can undo the week. Write who may invoke it. Write what you tell customers who are mid-conversation when you do. This is ordinary operational care. It belongs in the quote as time, because unrehearsed reversals consume the hypercare week you thought you had saved.

When the pilot topics are dull, add the next handful. Dull means the handoff note is full, the article is the one the queue would have used, and the old topic list has not been pasted in as a second policy. Excitement in the first week is usually a topic that escaped its rule. Treat that escape as a finding. Pull the topic back to a person until the rule is written.

The voice path is a different quote, with a caller who cannot see a form. Tenyx and the service voice quote is that page. Keep it off this estimate. A phone line added "while you are in there" is how a case design becomes a telephony project.

Send the sheet. Ask for questions before you ask for a fee. A partner who can work from this sheet can also tell you which rows they will not take. That refusal is a good sign. It means the rest of the number refers to something you can accept at the end, topic by topic, in the queue you already staff.

#The other searches

The project quote is on airkit.ai implementation cost. That page does not print a figure. Who bought the company is on what happened to airkit.ai. The connector is on integrating airkit.ai with Salesforce. Whether to move is on should I migrate from airkit.ai. The customer fee is on airkit.ai licence cost. Who to hire is on hiring for airkit.ai. This page does not rank an agency.