Heimster Pro in ChatGPT and Claude.

Which active listings need attention: time online, demand snapshots (searches, profiles, dossiers) and number of applications per listing, with thresholds applied; returns the listings that stand out.

Lists the applications the agency received for one of its own listings, ordered by the Heimster score (how complete and verified the dossier is and how well it meets the listing's stated requirements), with each application's status. It helps the agent decide which dossiers to review first; it makes no decision and changes nothing – the agent reviews every dossier and decides.

Ranks the interested parties and buyers registered for an object by Heimster's matching score – who fits best.

A compact daily briefing in one call: today's viewings, the latest applications, acquisition leads under review and how many listings need attention.

Checks one application: what is missing, why the score is capped, which documents are present and what to request next. Returns gaps and next steps, not the documents themselves.

Dry run of a portal export: shows which listings would be published or withdrawn on which portal right now, without sending anything, and reveals listings that would be skipped (e.g. missing price).

Collects the verified facts for a social-media post about an object (title, price, rooms, number of photos), the connected accounts and recent posts about it. Use the facts verbatim; posting stays manual.

Shows inbox messages not yet filed to a record and suggests, per message, the matching object, listing or project from Heimster's matching.

Writes an AI-generated sales pitch for an object and saves it as a draft. Uses AI credits, so it only runs with confirm=true; without it you get a free preview of what would be created. Nothing is sent or published.

Owners in the organisation's CRM who need attention this week: stated intent to sell, mandates ending within 90 days, due follow-ups and self-managed lettings. Ordered by urgency from the CRM data.

Reverse matching: which objects fit a given contact – including pre-market objects not yet public and investment properties – using Heimster's matching score with travel-time correction, and marks where the contact is already in a process.

The strongest evidence-based arguments for an object, e.g. to win a sales mandate – only signals above documented thresholds (building reserve, neighbourhood scores, sun, solar, taxes, active demand, scarcity in the building register). No generated text and no price estimate.

Anonymous demand for an object from the Heimster network: matching search alerts and profiles, strong dossiers, the weekly trend and how many people a pre-market alert could reach. Counts only, never identities.

How engaged the interested parties of an object are: data-room logins and downloads, e-mail opens and clicks, portal sync status, contact requests, reach (page views and conversion) and the top interested parties by interest score (0–100). Flags anomalies such as unused access, portal errors or unanswered enquiries.

Which active listings are not yet ready to show: checks each one against a completeness list (enough photos, current translations, tags, location scores, price, description) and lists those with the biggest gaps first.

Where the application funnel is stuck and needs a decision, across all listings: strong applications open for long, shortlisted without a viewing invitation, accepted without an offer, contract sent without signature. Grouped by urgency.

The organisation's viewing cockpit: upcoming viewings with free places, waiting lists and the public booking link, viewings waiting for the owner's approval, open follow-ups and the last 60 days including visitor feedback. Counts only, no names. Invitations, bookings and sending stay a manual step.

Whether all active listings are live on the connected portals or one was rejected: the credential status per portal and the listings whose sync failed, with the error message, errors first.

Scorecard of a new-build project: units (sale, rent, sold), listings (draft, active), applications, registered interested parties, pre-market registrations and whether a custom domain is active.

The full agenda in one call: viewings, handovers, expiring offers, lease ends, investment-property dates and manual appointments – merged and in chronological order for the next days.

Which e-mails still need a reply: open threads where the last message came from outside and the team hasn't answered yet, oldest first, with sender, subject, days waiting and the suggested record. Needs the agent's own sign-in (personal mailbox).

Who should be followed up because they went quiet: a read-only preview of the automatic follow-ups (open document requests, unanswered rental offers, data-room access granted but never opened), excluding cases already reminded. Sends nothing.

Yield figures of an investment property from its rent roll: target rent per year, gross yield (rent ÷ purchase price), multiplier (purchase price ÷ rent) and the asset class. Yield and multiplier are n/a without an internal price anchor.

Status of the bidding process for an investment property: bids ranked by amount (binding vs. indicative), % against the internal price anchor, gap to the second bid and whether it has been awarded. Display only – does not award.

Deal funnel of an investment property (longlist → teaser → interest → NDA → data room → non-binding offer → binding) with stage cohorts and conversion, plus data-room activity and unused or revoked access.

Which investors in the organisation's CRM fit an investment property: ranks contacts with an investor profile by the fewest deviations (asset class, canton, budget), excluding those already invited, with their consent status.

Triage across all investment properties: open data-room requests, unanswered enquiries, NDA signed but no data-room access yet, and undecided bids.

How many recipients a mailing really has: contacts in the segments vs. those that can be e-mailed (e-mail address and marketing consent) vs. those skipped. Counts only.

Creates a mailing as a draft and returns the edit link. It is never sent from here; sending stays a manual step in Heimster.

Prepares sending the exposé of an object: lists the registered interested parties who haven't received it yet, ranked by fit, and suggests the channel per recipient (in-app message or e-mail). Only the plan – sending stays a manual step.

The verified facts for replying to an incoming enquiry: the linked listing or object (price, rooms, area, open viewings), whether the sender is a known contact, and for investment properties that prices are only shared under NDA.

Saves a social-media post about an object as a draft for approval. It is not published; a person approves it in Heimster. Checks that the target account is connected.

Renders a marketing image (e.g. a square «just listed» post) from a design template with the object's facts, photos and branding, and returns the image URL for review. Template rendering, no generative AI. Nothing is published.

Creates a handover protocol (move-in, move-out or pre-inspection) as a draft, with the rooms of the object and the parties of the current tenancy. Nothing is approved, sent or signed – that happens in the editor. Returns the edit link.

Two steps. Without a confirmation token it only previews who the change reaches (applicants, saved-listing users, matching search alerts) and whether suppression rules apply; nothing changes and a 5-minute token is returned. With the token the price is set and the notifications go out.

Two steps. Without a confirmation token it previews how many matching subscribers would be notified now; nothing is sent. With the token the pre-market alert e-mails go out (fixed template, one message per object and address, identities stay hidden).

Two steps. Without a confirmation token it shows the owner, their e-mail and what would be sent; nothing is rendered or sent. With the token the current object report is e-mailed to the owner as a PDF.

Two steps. Without a confirmation token it previews the recipients, cadence and first send date. With the token a recurring owner report is set up (sent automatically later, not now).

Two steps. Without a confirmation token it checks for conflicts in the organisation's calendar and shows who would be invited; nothing is created or sent. With the token the event is created and the connected calendar (Outlook or Google) sends real invitations.

Lists the organisation's CRM contacts; search by name, e-mail or company.

Creates a CRM contact. If a contact with the same e-mail already exists, the given fields of that contact are overwritten instead. Syncs to HubSpot when connected.

One CRM contact with details.

Updates the given fields of a CRM contact (overwrites them). Syncs to HubSpot when connected.

The timeline of a CRM contact: notes, calls, e-mails, meetings.

Adds a note or activity to a CRM contact's timeline.

Lists the organisation's properties (objects); search by address or internal reference, filter by status.

One property (object) with details.

Updates the given fields of a property (status, price, rooms, area, year built, notes, description). Changes flow into its public listing. The intended use (rent/sale) can't be changed here.

The interested parties of a property and their pipeline status.

Lists the organisation's new-build projects.

One new-build project with details.

Lists the organisation's investment properties.

One investment property with details.

Lists the organisation's own listings; filter by status.

Creates a listing as a draft (not public). Publish it later with publish_listing.

One of the organisation's own listings with details.

Updates a listing (title, description, price, rooms, area, address). Setting status to «active» publishes it and setting «inactive» takes it offline – both need two steps: the call without a confirmation token returns a preview and a 5-minute token, the call with the token applies it.

Two steps. Without a confirmation token it previews the go-live (who is alerted, which portals receive it); nothing changes. With the token the draft goes live with its full effects: public listing, portal export, matching search alerts.

Takes a listing offline (soft delete: status inactive; the record and its history stay).

Lists applications for the organisation's listings; filter by listing or status.

One application with its dossier (name, verification badges, compatibility, shared documents). The applicant's e-mail is only included when they consented.

Two steps. Shortlists, rejects or waitlists an applicant – the applicant is notified (in-app message and e-mail). Without a confirmation token it previews the notification; with the token the status changes and the notification goes out. Closing steps (acceptance, contract) run in Heimster itself.

Moves an interested party to another pipeline status and returns the status before and after.

Lists the organisation's viewings, optionally for one day.

Creates a viewing for an object, project or listing (open, series of individual slots, or private). Two steps when it sends e-mails (guest invitations, tenant notice for occupied objects): the call without a confirmation token returns a preview and a 5-minute token, the call with the token creates it. Times are Europe/Zurich; the organisation's approval and tenant-notice rules apply.

Lists incoming leads (enquiries not yet handled).

Views, saves, enquiries and demand snapshots of a listing over time.

Creates a follow-up task on a contact or object timeline, due at a given time.

Writes an e-mail as a draft into the agent's connected Outlook mailbox (Drafts folder) and never sends it; the agent reviews and sends it from Outlook. Without a connected mailbox the text is returned unsaved.