Property cards on 5 portals by hand: the real estate agency that works for the listings, not for the visits

The agent who plays photographer, copywriter and data entry

Look at a typical day of one of your real estate agents and count the hours. They go to do the photoshoot at the apartment. They come back, download the photos, fix them. They write the listing text — the catchy description, the square meters, the features. Then the real, invisible work begins: they open the first real estate portal, create the listing, upload the photos one by one, paste the text, fill in the fields. Then they open the second portal and do it all over again. Then the third. Then the agency’s website. Then the social page. The same property, the same card, copied five times by hand.

And this is just the first day. Then the price changes, and must be updated on five portals. The property is sold, and must be removed from five portals (and when they forget, calls still arrive for an already sold house, with irritated customers and wasted time). A photo needs to be changed: five times. For every property in the portfolio, multiplied by how many you manage, multiplied by every modification. It’s clerk work that you are having done by the person who should bring home the revenue.

The paradox is brutal: you hired agents to sell houses — meaning to do visits, manage negotiations, close — and you are using them as data entry. Every hour an agent spends manually republishing the same property is an hour they don’t spend with a customer. And the customer doesn’t buy houses from the listing: they buy them after the visit, after the relationship, after someone has accompanied them in the most important decision of their life. This article is for those who own an agency (or a network) and feel that their agents work for the listings instead of the visits. Let’s see how to publish real estate listings automatically starting from a single card, because the true value lies in the visit CRM and not in the listing, and — honestly — when a ready-made vertical software is enough for you and when instead you need something of your own.

One card, many portals: the principle of multilisting

The concept that solves 90% of the pain is simple to say and transformative to apply: a single property card, many publishing channels. The agent enters the property only once, in one place — their card — and from there the property goes, automatically, to all portals, to the agency’s website, wherever it’s needed. This is what in jargon is called multilisting or cross-publishing, and it’s the difference between an agency working for the portals and one that uses them.

How does it work in practice? The single card contains everything: photos, floor plans, text, price, features, availability, status. It is the source of truth of the property. When the agent creates or modifies it, the system takes care of reflecting that truth on every connected portal, each with its formats and rules (because every portal wants data its own way). The agent no longer touches the single portals: they touch the card, and the card propagates.

The benefit is not just the time saved the first time. Above all, it is consistency over time. Change the price on the card: it changes everywhere, immediately. The property is sold: you mark it sold on the card, and it disappears from all portals together — no more calls for already sold houses. Update a photo: it updates everywhere. There is no longer the risk, always present with the manual method, that portal A says one thing and portal B another, with different prices for the same property and a terrible impression with customers who compare.

It is exactly the same principle of the single card that, in other sectors, solves the chaos of scattered data: like for price lists that must have a single source of truth, the point is not “publishing faster”, it is having one place where the information is true and from which everything else descends. Entering once, publishing everywhere: if you only remove this from your agents’ day, you have already paid for the tool.

The math: how much agent time you are burning

Let’s put down some numbers, as always stated as estimates but reproducible on your agency. Let’s say that manually publishing a property on five channels — creating the listing, uploading photos, filling fields, checking — takes on average 40 minutes. Add subsequent modifications: price changes, photo updates, removal upon sale. Let’s add, conservatively, another 30 minutes of manual maintenance scattered throughout the life of the listing. That’s about 70 minutes per property of repeated pure data entry.

Item	Estimate
Manual publishing time (5 channels) per property	~40 min
Manual maintenance (prices, photos, removal)	~30 min
Total data entry per property	~70 min
Properties managed per year (average agency)	~150
Hours/year of repeated data entry	~175 hours
Value of that time as agent time	the true cost is not the hour: it’s the missed visits

175 hours a year, for an average-sized agency. But the true cost is not the hourly value of those hours: it is the opportunity cost. Those 175 hours, spent in visits and negotiations instead of data entry, how many more houses would they sell? Even just a handful of extra closed deals a year is worth, in commissions, much more than any software. This is the point that is missed when looking only at “time saved”: an agent’s time is not a cost to be minimized, it is the resource generating revenue, and wasting it in data entry is the worst allocation.

Then there is the cost of errors and oversights: the sold property still online generating empty calls, the price updated on three portals out of five, the wrong photo left on one channel. Each one is a small blunder with a customer, and in the real estate agent’s profession reputation is everything.

Photos, floor plans, availability, price: what the card contains

For multilisting to work, the single card must be made well, because it’s what feeds everything. Let’s see what it contains, because every piece has its pitfalls.

The photos. They are the commercial heart of the real estate listing — people click on photos. The card must manage them well: easy upload (even in bulk), sorting, choosing the cover, and generating the right formats for each portal (which want different sizes). A good system does this boring work for the agent, who uploads once and that’s it.

The floor plans. Increasingly requested, often in a separate format. The card keeps them together with the property and distributes them where needed.

The price and its history. The current price, but also — for those who work well — its evolution. A property that has changed price three times tells something, and keeping track of it helps the agent in the negotiation. Price is also the data that changes most often, hence the one where multilisting makes the most difference.

Availability and status. Available, under proposal, in negotiation, sold, withdrawn. Status drives everything: a “sold” property disappears from portals, one “under proposal” maybe stays but flagged. Managing status well is what avoids calls for houses no longer available and it’s the piece the manual method always gets wrong.

Structured features. Square meters, rooms, floor, energy class, everything the portals ask for in specific fields. Having them structured in the card means they map automatically onto each portal’s fields, instead of being manually copied every time with the risk of errors.

This discipline — a piece of data entered once, well structured, propagating without retranscription — is the same that makes reliable any operational app removing copy-paste: the value is not the screen, it’s the data model underneath, made so it reflects real work and holds up to exceptions.

The real product is not the listing: it’s the visit CRM

Now the point that distinguishes an agency that grows from one that floats. Automating publishing is necessary, but it’s the easy part. The true value — what closes deals — lies in what happens after the listing: the requests, the visits, the feedback, the proposals. It is the real estate visit CRM, and almost no one manages it well.

Think about the real flow. The listing generates requests (from portals, website, phone). Every request is a potential buyer, and must be handled quickly — in real estate as elsewhere, whoever answers first has a huge advantage. Then visits are organized: who saw what, when, with which agent. After every visit there is feedback: did they like it? what was wrong? is the price the problem? This feedback is gold — to understand how to move the price, to report to the seller, to propose other properties to the customer. Finally the proposals: who offered how much, the negotiation status, the counter-proposal.

A real real estate CRM keeps all this together and makes it useful. It knows Mr. Smith has seen three three-room apartments downtown, that his budget is X, that he said “too dark” to the last one: so when a bright three-room apartment in the area arrives, the agent knows and calls him. It knows which properties collect many visits but no proposals (a signal the price is off-market) and tells the seller with data in hand, not by feeling. It transforms a mass of requests and visits into a machine that matches supply and demand and advances negotiations.

This is the piece that listing automation alone doesn’t give you, and it’s the one that counts most. Because the house isn’t sold by the listing: it’s sold by the well-managed relationship after the listing. An agency that auto-publishes but then loses requests in a shared email inbox, or manages visits on a paper diary and feedback in the agent’s head, has solved the wrong problem. Speed on requests and memory on visits are worth, in closed deals, much more than the time saved on publishing — even if time on publishing is what is seen most.

Own website vs portals only: who do your customers belong to

A strategic reflection few agencies make: if you live only on portals, your customers are not yours. They are the portals’. The potential buyer searches on the portal, finds your property among those of twenty agencies, and the portal — which collects the subscription from you — controls the relationship. Every year you pay more to be visible in someone else’s house, exactly like someone renting a storefront.

Having a strong website of your own, fed automatically by the same single card, changes the balance. Not to abandon portals — they are needed, they bring traffic — but to build yourself a channel that is yours: where the customer finds you, where your data (who searches for what) stays with you, where your reputation and your brand work for you. Multilisting makes this free, in the sense that the website updates with the same effort with which you update portals (i.e. zero extra effort, once set up). It’s the same reasoning about “owning your customers instead of renting them” that applies to those selling on others’ platforms: portals are excellent for distribution, but if they are the only channel, you are a guest in their home.

When a vertical software of the category is enough (the honesty I owe you)

Now the honest part, and in this sector it is particularly important: for many agencies, a ready-made vertical software is the right choice. The real estate management software market is mature: there are purpose-built products, with multilisting to Italian portals already ready, the visit CRM, the single card. They cost a subscription, activate quickly, and for the standard agency they cover the need very well. It would be foolish — and I tell you this even though I build custom software — to have developed from scratch what a vertical already does well for cheap.

When is the vertical enough? When you work in a fairly standard way: properties are properties, portals are the usual ones, the visit-proposal flow is the classic one, and you have no special needs for integration or your own rules. In that case, the vertical gives you 90% of the value (enter once, publish everywhere, manage visits) at 1% of the cost of custom. Take it, use it well, and focus your energy on visits. The message of this article — stop republishing by hand — for you is realized by buying the right vertical, not building anything.

Just pay attention to two things when choosing a vertical: that the multilisting truly covers the portals you use (and keeps them updated when portals change rules, which they often do), and that your data remains exportable — that the day you change software you take your cards, customers and history with you, without being held hostage. These two checks avoid the most common rip-offs.

When instead you need custom

So when does something of your own, custom-built, make sense? When the rules of your network or your model do not fit the tracks of the vertical. Some concrete cases:

You are a network or a franchise with its own rules. Multiple locations, agents with different permissions, internal commissions, sharing properties between network agencies with special logics, a strong brand to be respected everywhere. Verticals are designed for the standard single agency; a network with its rules often makes them creak, and at a certain point custom that models your rules costs less than fighting a product that doesn’t foresee them.

You have integrations the vertical doesn’t do. You want to connect the real estate management to your accounting system, to a customer portal where the seller follows their file, to digital signature flows, to your website with special features. When the integrations you need leave the vertical’s tracks, custom becomes the way.

You want data and an experience that distinguish you. If your competitive advantage is a particular way of working customers or properties — sophisticated matching, a unique customer experience, portfolio analysis nobody does — then you don’t buy that advantage off the shelf, because by definition everyone buying the same vertical has it. There, custom is what makes you different.

The rule, as always, is how much of your way of working fits in that 20% the ready-made doesn’t do. If the core is there — network rules, integrations, competitive advantage — custom is justified. If you are an agency working in a standard way, the vertical wins, and whoever pushes you to custom “always” is selling you a project you don’t need. On this choice — buy ready or build — I made a general reasoning in the guide to portals and restricted areas, because it applies identically in every sector.

The KPIs that count: card time vs visit time

If there’s a way to know if you’re winning, it’s the right numbers — and in your profession almost nobody looks at them. The KPI that summarizes everything is the ratio between time spent on cards and time spent in visits. A healthy agency shifts its agents’ time from the first to the second: less data entry, more meetings with customers. If you measure this and see it improving, you are going in the right direction.

But there are other numbers a good system puts in your hand that transform the agency from “by feeling” to “on data”:

• Requests per property and per channel: which portal brings you true contacts and which only curious onlookers. It tells you where it’s worth paying the subscription and where not.
• Response time to request: how long it takes the agent to call back a potential buyer. It’s the number most correlated to closings, and almost nobody measures it.
• Visits per proposal: how many visits are needed to generate an offer. If a property has many visits and zero proposals, the price is off-market — and now you can tell the seller with numbers.
• Average selling time by area and price range: to give the seller realistic expectations and understand where you are strong.

These KPIs are the same kind of visibility a dashboard gives the owner in other sectors: they transform “it seems to me” into “data says”, and change conversations — with the team, with sellers, with customers. An agency knowing its response time and visit/proposal ratio plays in a different league from one going by nose.

What about AI? Where it really helps (and where it doesn’t)

In the real estate sector the question about artificial intelligence always comes, and the honest answer is: it helps in some concrete points, and in none of those that really count for closing. Let’s look at them, because distinguishing is what prevents you from buying smoke.

Where AI helps: in writing descriptions. From a card with square meters, rooms and features, a model can propose a decent listing text in seconds, which the agent then refines. It’s time saved on a boring job, and it’s fine — provided the agent checks, because AI sometimes “enriches” with details the property doesn’t have, and in real estate a false description is a serious problem. It also helps in tagging and sorting photos (recognizing kitchen, bathroom, exteriors), in suggesting matching between a new property and searching customers (“this bright three-room apartment looks like what Smith was looking for”), and in answering the first questions of contacts on the site, filtering the curious from true potential buyers before they reach the agent.

Where AI must not decide: on the price (automatic valuations are a starting point, not a verdict — the agent makes the price with the market and the negotiation), on the exact matching of fields that portals want precise (that’s deterministic mapping work, not “usually”), and on anything where an error becomes a blunder with the customer or seller. The rule is the usual of all serious software: AI where it helps write, search and filter; the engine and the person where exactness and judgment are needed. Whoever sells you “the agency managed by AI” is selling you a headline, not a tool — the job of closing a house remains human, and AI only serves to remove the boring work around it.

A typical case: from copying to selling

A typical profile, architectural, no names. Agency with a few agents and a managed portfolio of a hundred properties. Every agent published by hand on four-five portals plus the website, and spent — in their words — “half a day a week just uploading and updating listings”. Requests arrived in a shared email inbox where they got lost, visits were on personal diaries, and feedback after visits lived in the head of whoever was there. Result: requests not called back in time, unhappy sellers because “nothing moves” without data to explain why, and agents frustrated playing clerk.

What was tackled, and in what order. First, publishing: single card, enter once, automatic multilisting to portals and website. This alone gave agents back their half day a week. Then — the part worth most — the visit CRM: requests from all channels converged in one place with a measured response time, visits were tracked, feedback recorded and became actions (“look for a bright three-room apartment for Smith”). Finally KPIs: requests per channel, response time, visits per proposal.

Fully operational, the difference wasn’t “we publish faster” (that was the minimum): it was that agents started playing agent again. Requests were called back quickly, customers followed with memory, sellers updated with true data (“your property had twelve visits and no proposal: the market tells us the price needs reviewing”). There was no need to sell more by trying harder: it was enough to stop wasting agents’ time in data entry and stop losing requests. The honest note: in this specific case a good ready-made vertical was also evaluated, and for part of the need it would have sufficed — custom was justified by the special network rules and the integration with the proprietary website, not “because custom is better”.

Timeline, adoption and maintenance

How long does it take and what to expect? If the path is the vertical, it’s a matter of weeks of configuration and portfolio loading, plus the time — not to be underestimated — for agents to adopt the new way of working. If the path is custom, it starts as always from understanding the true rules (of the network, the flow, the integrations), builds the core — single card, multilisting, visit CRM — and tests it on a pilot location or group of agents before expanding.

Adoption, in this sector, is the real challenge. Agents are often reluctant to systems (“I keep my customers in mind”), and a CRM dropped from above gets filled in poorly or bypassed. The secret is the same as any app people must actually use: it must be faster and more useful than the current method, not an extra chore. If recording feedback after a visit takes thirty seconds from the phone and helps the agent close, they do it; if it requires five minutes of forms and looks only like control, they don’t. Adoption is designed, not imposed.

Maintenance has a real estate peculiarity: portals change their rules frequently (formats, required fields, ways of receiving data). A multilisting system must be kept updated to those changes, or it stops publishing correctly. It’s one more reason to choose — vertical or custom — whoever guarantees this continuous maintenance towards portals, and doesn’t leave you with a multilisting that worked last year.

Where to start

If you recognize yourself in the problem, the first step is not choosing a software: it’s measuring two things, and you can do it this week without spending anything.

The first: how much agent time goes into data entry. For a week, ask agents to record (roughly) how much time they spend publishing and updating listings on various channels. Multiply by the weeks in the year. That number, translated into “visits they could have made”, is your business case — and it’s almost always bigger than you imagine.

The second: how many requests you are losing. For two weeks, track requests arriving from all channels and the time passing before someone calls back. If you discover requests sitting for hours or days, or lost entirely in the shared inbox, you have found the hole costing you more than any manual publishing — because every lost request is a potential buyer gifted to another agency.

With these two numbers in hand, the choice becomes concrete. If the problem is mainly the first (data entry) and you work standardly, almost certainly a good vertical software solves your life for cheap: evaluate a couple, checking portal coverage and data exportability. If instead you have network rules, special integrations or want to build an advantage the ready-made doesn’t give, then the conversation on custom starts from solid ground: not “I want a management software”, but “here is how much time I burn, here is how many requests I lose, here are my special rules”. From there the right thing is designed — which sometimes is simply buying the vertical well, and that’s perfectly fine.

Why a single hand is needed (here too)

Whether you go for a vertical or custom, a principle applies that I often explain in other sectors: publishing (frontend), distribution rules to portals (backend) and cards/master records/history (data) are a single system, and must be thought out together. The classic way to fail, in custom, is splitting them: a web agency making “the nice website with properties”, a technician handling portal connections, and nobody owning the visit CRM. The result is a cute website not talking to the multilisting, a multilisting publishing data the CRM doesn’t know, and visit feedback staying on a separate island. When something doesn’t add up — a sold property still online, a lost request — everyone blames each other, and you pay two or three suppliers for an agency running worse than before.

A working real estate system stems from the idea that single card, distribution and customer relationship are the same story told in three points: the property entering, spreading, generating visits and negotiations. Whoever designs the card and whoever builds the visit CRM must think together, or the two pieces detach exactly at the point — the transition from request to visit to proposal — where money is made. A single direction is needed, not three suppliers blaming each other.

It’s for you if / it’s not for you if

It’s for you if: your agents spend hours republishing the same properties on multiple portals by hand; you lose requests in shared email inboxes or manage visits and feedback from memory and on personal diaries; you want your agents to do more visits and less data entry; you are a network with its own rules or have integrations standard verticals do not cover.

It’s not for you if: you are an agency working in a standard way and a good real estate vertical software already covers your need (in that case buy it and use it well, custom would be a waste); you have very few properties and manage them very well this way; you are not willing to have agents adopt a more orderly way of working — because without adoption, no system (vertical or custom) brings results.

Frequently asked questions

Isn’t a ready-made real estate management software enough? For many agencies yes, and it’s the right choice. The real estate vertical market is mature: multilisting, single card and visit CRM are often already there, at an accessible subscription. Custom makes sense when you have network rules, integrations or a competitive advantage the vertical doesn’t cover. Just check that the vertical covers the portals you actually use and your data remains exportable.

How does automatic publishing on portals work? You enter the property once in the single card; the system publishes it and keeps it updated on connected portals, each with its format. Change the price or status once, and it reflects everywhere. Sell the property, and it disappears from all portals together. It’s multilisting, and it’s what eliminates manual copying.

What if a portal changes its rules? It happens often, and it’s why multilisting maintenance is continuous. A good system (or a good supplier) keeps portal connections updated when formats and fields change. It’s something to verify before choosing: who guarantees updates towards portals over time?

What is the part that counts most? Not publishing — that is the easy and “hygienic” part. The part closing deals is the visit CRM: answering requests quickly, remembering what every customer saw and said, managing feedback and proposals. The house is sold by the relationship after the listing, not the listing.

Will my agents use a CRM? Only if it’s faster and more useful than their current method. A CRM requiring long forms and looking like control gets bypassed; one that in thirty seconds from the phone records feedback and helps the agent close gets used. Adoption is designed by making the tool an advantage for the agent, not a chore.

Why should I have my own website if there are portals? Because on portals the customers are the portals’, not yours, and you pay more every year to be visible in someone else’s house. A website of your own, fed by the same single card (so without extra work), gives you a proprietary channel: your data, your brand, your reputation. Not instead of portals, but alongside.

What numbers should I measure? The most useful ones: requests per channel (where paying the subscription pays off), response time to requests (most correlated to closings), visits per proposal (to understand if a price is off-market), average selling time by area. These are the numbers transforming the agency from “by feeling” to “on data”.

If I choose custom, does the data remain mine? Yes, and it must — this also applies when choosing a vertical, where it must be verified. Property cards, customer master records, visit and negotiation history are your asset: they must remain exportable and yours, without vendor lock-in, so you can change tool without starting from zero.

In one line

If your agents spend their days republishing the same properties by hand on five portals, you are using the people who should do visits and close as data entry. The solution starts from a single property card automatically publishing everywhere (multilisting), but the real value is in the visit CRM: answering quickly, remembering every customer, managing feedback and proposals — because the house is sold by the relationship, not the listing. And honesty: for many standard agencies a good vertical software is enough; custom is justified when you have network rules, integrations or a competitive advantage the ready-made doesn’t cover.

If you want to understand if a vertical is enough for you or if your way of working asks for something of your own, look at the projects I’ve built or drop me a couple of lines: we start from how your agency really works and how much agent time you are burning in data entry, not from a demo.