10 Car dealership: uploading listings to Avito and Auto.ru and collecting leads into Bitrix24

The dealership sells through listing platforms, that's its main channel, and the listing there needs to be accurate. But vehicle data lived in the inventory system: part in spreadsheets, part in 1C. Between the inventory and the listing stood a person who carried the specs over by hand, separately for each platform.

This wasn't a one-time task. A car arrives, so it gets published in two places. The price changes, so it gets fixed in two places. It sells, so it gets pulled from two places, and preferably fast. On a dozen cars this is tolerable; on a full lot it's a standing job for an employee who also has other work to do.

A sold car was still listed, the price was yesterday's, and a client called about something that no longer existed. The first impression of the dealership soured at the exact moment someone showed interest.

This is where the main problem came from: listings fell behind reality. A sold car was still listed, the price was yesterday's, and a client called about something that no longer existed. This wasn't just wasted time for the manager, it was the client's first impression of the dealership, and it soured at the exact moment they showed interest.

The second half of the problem was on the incoming side. Leads arrived in the platforms' own accounts, calls came to the phone, messages came through messengers. A CRM existed, Bitrix24 was in place, but an inquiry only landed there if a manager entered it. On a busy day, not everything got entered.

And a third issue followed from the second: it was impossible to tell which platform actually brought in clients. The source was filled in from memory at the end of the day, so the report showed manager diligence, not channel performance.

A closed loop: inventory to platforms to leads to CRM. Each side does what it's good at, and none of them needs a human go-between anymore.

Toward the platforms, the upload does the work. The system takes vehicles from the dealership's inventory data, meaning spreadsheets and 1C, and builds listings in the form each platform requires. Their requirements differ: their own make and model directories, their own set of required fields, their own rules for descriptions and photos. Bringing the dealership's data into these formats is the actual content of the work.

The inventory data became the source, and the listings its reflection. The gap between them stopped being a matter of someone's attentiveness.

Updates run on a schedule, not on a button press. The price changes in the inventory system, and it changes in the listings too. A vehicle sells, so it's taken off the platforms. A new one arrives, so it's published. The inventory data became the source, and the listings its reflection, and the gap between them stopped being a matter of someone's attentiveness.

In the other direction, lead collection does the work. Inquiries from both platforms land in Bitrix24 as deals, with a contact, the vehicle specified, and the source filled in. The manager works in one place instead of checking multiple accounts.

Between how a vehicle is recorded in the dealership's inventory and how a platform requires it to be described lies a gap that has to be crossed on every publication.

The platforms have their own directories: make, model, generation, trim, body type, drivetrain. In the dealership's inventory, the same thing is recorded however was convenient at the time: sometimes in one line, sometimes abbreviated, sometimes with a typo made during intake. Matching these two representations is the core of the work: a listing with a misidentified model will either fail moderation or show up in the wrong section of the site.

A listing with a misidentified model will either fail moderation or show up in the wrong section of the site. Matching the directories is the content of the work.

Required fields are their own story. A platform won't publish a listing without what it considers mandatory, and the two platforms' rules don't match. The system checks completeness before sending: incomplete data shows up as a problem on our side, not as a silent rejection from the platform that someone discovers a week later.

And photos: the dealership has a lot of them, they're stored separately from the inventory system, and each listing needs its own set in the right format. This is the part that took the longest under manual handling.

Listing platforms are external systems, and they go down, rate-limit requests, and return errors. An upload written only for good weather simply won't get through on a day like that, and no one finds out until a client calls.

That's why the sync runs on task queues with retries: a publication that fails goes back into the queue instead of getting lost. A platform rejection based on the listing's content, such as failed moderation, is distinguished from a technical failure and shows up as a separate situation that needs a person.

This matters especially in connection with price and availability. A price update that quietly fails to go through means the dealership is showing the client the wrong figure, and that gets discovered in conversation, at the worst possible moment.

Managing listings stopped being daily manual work. A vehicle arrives, its price goes up, its price goes down, and it sells in the inventory system, and the listing platforms follow along on their own.

Listings now match the actual lot. Sold vehicles come down, prices are current, and calls about cars that no longer exist went away along with their cause.

Leads from both platforms reach the pipeline regardless of how busy the manager is: manual transfer has been removed as a step, so it can no longer be forgotten.

And there's now an honest answer to which platform actually works. The source is filled in by the system the moment the deal is created, so comparing channels rests on data, not on staff memory.