Otodom, Morizon, Gratka: one listing source, no retyping

A developer selling apartments through Otodom, Morizon and Gratka, Poland's main property portals, usually has the same offer in several places at once: on each portal, on the development website and in the sales team's spreadsheet. With a dozen units you can manage it by hand. With several developments and frequent price changes, every change means retyping, and every slip means a unit that is sold on the website but still available on a portal. Below we look at how to export listings from a single source, keep prices and statuses in sync, and collect portal statistics and enquiries in one place.

The problem: one offer in five places

The usual picture: the unit description is written in a text document, the photos and floor plans sit on a shared drive, and someone in marketing or sales posts the listing on each portal separately. When a price changes, it has to be updated in every portal's panel, on the development website and in the price list. Enquiries arrive by email from each portal separately and land in different people's inboxes.

The results are predictable:

• prices and statuses drift apart, and a buyer calls about a unit that has been reserved for a week,
• listing quality varies, because each one was written by someone else at a different time,
• nobody knows which portal works, because the view counts sit in several panels and the enquiries in several inboxes.

One listing source

The fix starts with a rule: the unit data lives in one place, and everything else takes it from there. That place can be a CRM, a listing export tool or a system built around the company's own process. The source holds:

• the unit data: number, floor, floor area, number of rooms, price, status,
• the listing text, ideally from a template, so every offer has the same layout and the full set of information,
• the photos, visualisations and floor plans linked to the unit,
• which portals the unit should go to.

It also pays to check each listing before it goes out: does it have a floor plan, is the description long enough, do the price and floor area match? Gaps then show up in one place before publishing, not a week later on a portal.

How listings reach the portals

Property portals take listings from outside software in two ways: through an API or through XML files. The details differ from portal to portal, so check them at the source before choosing a tool.

Otodom. On its partner page (in Polish), Otodom describes both routes and recommends the API. According to the portal, with the API listings reach Otodom in real time, data flows both ways, and the software gets the listing's status a few seconds after the export. An XML export runs once every few hours, and Otodom does not provide technical support for it. Otodom's API belongs to the OLX Group and is publicly documented: it covers creating, updating and removing listings, and the documentation also describes receiving buyer enquiries through notifications (webhooks). Availability of that feature varies by marketplace, and the API itself requires access credentials from the operator.

Morizon and Gratka. Both portals belong to the Morizon-Gratka group. Its offer for estate agencies (in Polish) lists integration with popular CRM programs and a panel with listing statistics. We did not find public technical documentation for the import, so the format and terms need to be agreed with the portal or with the vendor of the software you export from.

One intermediary instead of many integrations. Many companies do not connect to each portal separately. They use a program that already has ready-made exports to many portals. Their own system sends offers to that program, and it passes them on to the portals. That is usually faster than building and maintaining several integrations at once.

Prices and statuses: change once, update everywhere

A single listing source only makes sense if a change in it really reaches everywhere. An adviser who marks a unit as reserved should not have to remember three portal panels and the development website. A price or status change goes from the source to the export and to the website.

Two things are worth agreeing on at the start:

• what happens to the listing of a sold unit: it disappears from the portals at once, or stays with a "sold" status if the portal allows it,
• how quickly a change has to show. With an export every few hours, two versions of a price can exist for a while. The sales team is better off knowing that than being surprised by it.

Statistics and enquiries in one place

Each portal shows listing statistics in its own panel and sends enquiries in its own format. Instead of logging in to several panels, collect this data next to the listings:

• views and enquiries linked to a specific listing, not just to a portal,
• portal enquiries together with enquiries from the development website, in one list, with the source marked,
• assignment to an adviser, just like enquiries from the website form,
• the buyer's history: if the same person asked through a portal and through the website, the adviser sees one contact.

Some of this data can be pulled automatically, some only from email notifications or an export from the portal's panel. That depends on the portal and the type of account, so check the scope before you build.

Which portal brings enquiries

Views say little. What counts is how many enquiries each portal brings and how many of them lead to a call, a viewing or a reservation. That takes two things: a source attached to every lead, and lead statuses kept in one system.

Once that works, you can compare portals on the same data: enquiries per listing, the share of enquiries that reached a viewing, and the subscription cost per enquiry. You can also test the listing itself: two versions of the description or of the main photo, and see which one brings more enquiries.

An example: Listing Manager

For the Koneser Group sales team we built Listing Manager, an internal system that brings these pieces together. Listing descriptions are built from templates, and the system grades every listing and checks it before publishing. Finished offers go to the Agencja5000 system and from there to the property portals. Views, enquiries and leads sit in one view, linked to the specific offer, and A/B tests show which version of a listing brings more enquiries. A WordPress plugin keeps the development websites up to date: a unit's price or status is changed once, in Listing Manager.

If your team still posts offers on each portal separately, see what we do under internal systems, or tell us how your process works today.