SOLUTIONS
Is AmoCRM cut off from your website and sheets? AmoCRM integration with your website, spreadsheets and apps
I connect AmoCRM (Kommo outside the CIS) to websites, Google Sheets, apps and your own server. Deals stay in AmoCRM, complex logic runs alongside.
Suited toImproving current toolsNew internal system
The topic will already be filled in.
What this looks like in practice
How an AmoCRM integration grew into a system for a car rental business: full booking cycle on the website, calendar logic, documents, inspections and servicing.
ArticleConnecting documents, CRM and tasks reliablyDesign for duplicates, missing information and failed handoffs before adding AI.
DemoCalculator: lost requestsEstimate how much money a month comes back if fewer requests are lost.
AmoCRM works, but everything around it is manual
AmoCRM is a sales CRM widely used in Russia and other CIS countries; outside the region it's sold as Kommo. Your deals and contacts are in AmoCRM, while bookings, prices and schedules sit in a Google Sheet. The website creates a request, and then a manager copies the details over by hand. Your staff app is being built separately and knows little about the CRM. You don't have to replace AmoCRM to fix this.
How this started for me
In October 2024 a car rental company in South Africa asked me to connect AmoCRM to Google Sheets. The company ran its work in a spreadsheet, and the sheet needed to pick up maintenance costs, mileage, the child seat fee and other rental values. I built that integration. Alongside it, I set up sync for selected fields between the company's internal FlutterFlow app, which runs on Firebase, and AmoCRM.
Then I suggested setting up a dedicated server. It can host many integrations and logic more complex than you'd want to configure inside a CRM. The company agreed, and over 2025 a system grew around AmoCRM: a booking website, documents, vehicle inspections, repair tracking. It's in operation now, and I maintain it. The car rental case study has the details.
What I clarify before development
First we sort out which data is authoritative in AmoCRM and which lives elsewhere. Usually the deal, the contact and the pipeline stage stay in the CRM, while schedules, prices or stock sit in a spreadsheet or your own database. For each field we decide who changes it and where the change needs to go.
Then I look at what AmoCRM itself offers: the API, webhooks, custom fields and request limits. If your logic fits into pipeline settings, you don't need an extra server. If there are many rules or several data sources, I'd move the logic to your own server and keep AmoCRM as the place where managers work.
I'll need examples too: an ordinary deal, a repeat request from the same customer, a booking changed after payment.
A possible first stage
One connection you can see working right away. A website request creates a deal with the right fields, or changes in AmoCRM reach the spreadsheet. If calls, messengers or your own app also need to see deals, those come next. See IP telephony and chatbots for Telegram and WhatsApp. We agree the scope and cost of the first stage before development starts.
How we accept the result
We run the agreed examples: a new request, a duplicate, the same record changed in the CRM and in the sheet at once, the API going down. We check where the data ended up, what went into the log and what the manager sees. You get a working connection, a field description and clear steps for when the exchange breaks.
Related pages
CRM integrations, spreadsheet automation and an article on connecting documents, CRM and tasks reliably. Tell me what's connected to your AmoCRM now and where time gets lost.