SEO optimizes for search engine rankings within a list of clicks. AI Visibility measures and optimizes whether a brand is mentioned in an LLM’s direct response. Both disciplines coexist—they have different data models, metrics, and optimization levers. For your marketing, this means two separate reports, not one with an extension.
Through systematic simulation of real user queries against ChatGPT, Claude, Gemini, and Perplexity—directly via the providers, not via scraping or proxy measurements. Mentions, position, frequency, and context are recorded. This gives your team a reliable data basis instead of assumptions.
Infera is the monitoring module – available as a standalone option for companies that have already defined their topic areas and are looking for an ongoing tracking tool. The AI Visibility service additionally includes the strategic definition of topic areas, the audit, content optimization, and reporting. For your team, this means: purchase Infera as a tool when the methodology is already in place. Book the service when the methodology still needs to be developed.
For optimization, the platform needs to offer a way to deploy semantic markup, Schema.org, and an AI-first sitemap. This enables your content team to publish structured content without requiring development. WordPress Enterprise, HubSpot CMS, and headless setups (e.g., Payload) meet these requirements out-of-the-box or with manageable effort.
The audit provides an immediate assessment of your current position. Optimization measures typically take effect over several weeks, as embedding pipelines and LLM training updates follow their own cycles. Infera displays development at a defined frequency—ensuring that the impact is methodically verifiable, not just claimed.
Infera covers four leading LLM providers: ChatGPT, Claude, Gemini, and Perplexity. The methodology is based on direct provider queries, not on scraping or proxy measurements.
Classic SEO optimizes for search engine rankings. AI-First optimizes for content to appear as a source in generative answers – meaning not for a position in a search results list, but for being mentioned within an AI-generated response. Both complement each other: solid SEO fundamentals are a prerequisite, while AI-First goes beyond this by modeling content as citable entities and describing them semantically.
No. Both traditional CMS platforms like WordPress Enterprise and headless systems like Payload CMS can be set up AI-first. What matters is data modeling, not the platform: content must be maintained as typed entities, not as free-text pages. WordPress with clearly defined Custom Post Types, Custom Fields, and Schema.org markup fully meets the requirements.
Content that already works as “facts” or “answers”: service descriptions, technical specifications, definitions, FAQs, case studies, locations, product data. Narrative texts (magazine, editorial, storytelling formats) benefit less directly, but serve as proof of authority. A good mix combines both.
Through AI Visibility Monitoring—systematic simulation of realistic user queries against the four market-leading providers (ChatGPT, Claude, Gemini, Perplexity) and evaluation of whether your own brand is mentioned, correctly cited, or ignored. Our SaaS product “Infera” provides ongoing data for this purpose.
This depends almost entirely on the state of the existing data model. A platform with a clean custom post type structure can often be developed incrementally. However, a site structure that has grown over years without entity modeling usually requires a structural reassessment—ideally within the framework of an Ideation Circle (4–6 weeks for scope, architecture, and roadmap) before a single line of code is written.
AI-first means: for every task, we first check whether the problem can be solved better with AI. It does not mean using AI all the time. That is what sets us apart from approaches where AI is added later as a feature—at our company, it is the default that is consciously chosen or consciously rejected. In practice, this means that architecture, content structures, and processes are planned so that AI can operate on them—even if it is not yet being used today.
No. Data modeling is crucial, not the platform. WordPress Enterprise, HubSpot CMS, and headless systems like Payload can all be set up as AI-first – what’s needed is structured, typed content instead of free-form text pages.
An agent requires accessible APIs to the systems it is intended to operate, as well as a permissions concept that defines what it may read and write. The Model Context Protocol (MCP) standardizes this integration, ensuring that a separate solution is not required for each tool. If clean interfaces are missing, that is the first construction step – not the model.
A workflow automation follows a fixed, predefined path. An agent, however, selects the path based on the goal itself, invokes tools for this purpose, and evaluates intermediate results. Simply put: Automation executes a plan, while Agentic AI creates it.
For companies with 50 to 500 employees, Agentic AI is worthwhile wherever rule-based work is distributed across multiple systems. The benchmark is not the size of the company, but the number of documented processes that an agent can take over. Without documented processes, the agent lacks the necessary template.
Through a defined format instead of a large-scale project. First, we clarify in a compact introduction which tasks are suitable for agents and which are not; development follows afterward. Broader expansion follows once the benefit has been demonstrated through a concrete use case.
No. Approval points and permissions define what an agent may decide independently and where human consent is required. Critical steps remain with the team – the agent supports, decisions are made according to the principle “AI First, Human Judgment Always”.
Not out of the box. OpenClaw grants an agent extensive permissions but does not enforce security policies itself. For enterprise use, an isolated environment is required, along with tightly scoped permissions, proper credential management, and comprehensive logging—precisely the building blocks that a secured reference implementation like NemoClaw provides.
A chatbot takes an input and provides a response. OpenClaw maintains a state, plans multiple steps, and executes them using tools: shell commands, browsers, files, and programming interfaces. The difference lies in the capacity to act—the agent does not just say what should be done, it does it.
The software itself is open source and free. Relevant costs arise during operation: hosting, the use of connected AI models, and securing the environment. Model usage in particular carries significant weight, as continuously running agents generate ongoing requests—a point that should be considered from the very beginning of planning.
Operations belong in the hands of IT, as permissions, isolation, and logging are managed there. The functional framework – which tasks an agent may perform and where human approval is required – is established by management in collaboration with the relevant departments. An agent without a designated owner is the primary risk, not the technology itself.
Basic starts at €95 per month with no setup fees, for up to 50 pages and website chat, with a 12-month term. Business starts at €3,000 for setup and €195 per month, for up to 2,000 pages, with no minimum term. Enterprise, which includes a dedicated server and a customized scope, is priced upon request.
It depends on the volume of inquiries. A rule of thumb based on past experience: If your service team spends more than ten hours a week handling standard inquiries whose answers are already available on the website, you’ll see a return on investment in no time. If the main goal is conversion optimization rather than reducing the service team’s workload, it depends on the conversion rate of your main landing pages.
In most cases, yes, but only to a limited extent. Content written purely for navigation purposes (“Click here for more”) performs poorly in RAG contexts. Content that provides clear answers, definitions, and explanations works well. During the project, we’ll determine which parts of your content can be used as-is and which should be editorially revised.
ChatGPT responds based on its training data. It isn’t familiar with your content and, when in doubt, will generate something plausible that is actually made up. With RAG, the language model is first fed the relevant passages from your content. This means the source is cited for every statement, and you can verify it.
In the default configuration, embeddings and the vector database are hosted on Supabase infrastructure in the EU. In this configuration, the responding language model runs via the OpenAI API by default. However, our setup is model-agnostic, so we can flexibly integrate a different model.
You have structured content that could answer your users’ questions—if they could find it. You have a customer service team that answers the same standard questions over and over again. Or you want to finally be able to measure, in your marketing efforts, whether your content addresses real user questions.
Yes. The AI chatbot is intentionally designed to be system-independent. Integration takes place via the front end (the website interface) and the content pipeline (importing content from the CMS). Whether it’s WordPress, Payload, or a custom-built headless CMS—the interface is API-based.
A chatbot that, before every answer, retrieves matching passages from defined content and lets the language model answer only from them. RAG stands for Retrieval Augmented Generation. It links the source for every answer.
RAG stands for Retrieval Augmented Generation. Before every answer, a language model is given matching text passages from a knowledge base and phrases the answer on that basis. This lets it work with current, company-specific knowledge that was missing from its training.
Anything that exists as text or can be converted into text: website pages, PDFs, FAQs, data sheets or manuals. The content enters the system via CMS interfaces or by crawling. A regular sync ensures that updated pages are reflected in the answers.
With fine-tuning, the model is further trained on your own data, and the knowledge then sits in the model weights. Every content change requires new training, and no source can be cited. With RAG, the knowledge stays in a database. An updated page is available after the next sync.
The risk is lower than with a model without a data foundation, but it still exists. A threshold for relevant passages and a clear instruction in the system prompt ensure that it hands off to a person when there is no basis for an answer. The linked source makes errors verifiable.
That depends on two places: where content and chat histories are stored and where the language model runs. Both can be operated in the EU. If the model runs with an external provider, a data processing agreement and a notice in the privacy policy are required.
Yes. The EU AI Act requires a chatbot to be recognizable as AI at the latest at the first interaction. A notice in the chat window or in the greeting is usually sufficient. A note only in the terms and conditions or the privacy policy does not meet the obligation, because visitors hardly see it while chatting.
We can connect a wide range of systems to integrate your real estate website optimally. These include, among others:
We would be happy to discuss your individual requirements and find the right solution for your system landscape.
Yes, absolutely! We place great importance on ensuring that you can manage your website content independently. To this end, we offer various solutions:
**Content Management System (CMS)**
Your website is based on a user-friendly CMS that is easy to operate even without prior technical knowledge. You can:
• Edit text and content directly on the website
• Create new pages and posts
• Upload and manage images and media
• Update real estate listings
• Change contact information
**Training and Support**
We provide you with a comprehensive introduction to the system so that you can quickly find your way around. Additionally, we are available to answer any questions you may have.
**Optional: Editorial Service**
If you require assistance with maintenance, you can also make use of our editorial service. We will then handle the regular updating of your content.
The implementation time depends on the scope of your project. Here is a rough guide:
**Standard website** (5–10 pages)
• Planning and concept: 1–2 weeks
• Design and development: 3–4 weeks
• Content creation and integration: 1–2 weeks
• **Total: approx. 6–8 weeks**
**Extended website** (with exposé system, multilingual)
• Planning and concept: 2–3 weeks
• Design and development: 4–6 weeks
• System integration: 1–2 weeks
• Content creation: 2–3 weeks
• **Total: approx. 10–14 weeks**
**Express option**
For urgent projects, we also offer an express option that allows us to accelerate implementation. We would be happy to discuss this with you individually.
**Important**: The actual duration also depends on how quickly feedback is provided and content is supplied by the client. We work closely with you to keep to the schedule.
A website is a completed project that is delivered. A platform is a system that is continuously developed – with modeled data, multiple stakeholders, and interfaces to other systems. The difference lies not in appearance, but in life expectancy and in the question of who works with it. Anyone still operating the same system two years after launch had a website. Anyone with one that has grown with the business had a platform.
Machine-readable means: content is structured so that AI systems can interpret, link, and process it—not just read it. Specifically, this means Schema.org markup, entity modeling, semantic HTML structure, and an AI-first sitemap. This enables an LLM to understand your texts not merely as sequences of words, but as statements about your company. This difference determines whether you appear as a fact in an AI response or not at all.
Traditional SEO continues to work—just not everywhere. ChatGPT, Claude, Gemini, and Perplexity answer questions directly, without a list of links. Those who are not mentioned there remain invisible to the person asking—regardless of their Google ranking. SEO and GEO are not competing disciplines, but two parallel visibility realities with different data models, metrics, and optimization levers. Having both reporting systems is the only way to see the complete picture.
Continuous Improvement…
We focus on symbiosis rather than replacement. Humans provide context, judgment, and direction—AI contributes speed, scalability, and precision. In everyday work, this means: decisions are always made by humans, AI merely accelerates implementation. This is precisely the operational form of our guiding principle: “AI First. Human Judgment Always.”
Eine branchenspezifische Plattform-Lösung mit vorkonfigurierten Prozessen und Modulen. Statt jedes Projekt bei Null zu starten, bringen unsere spezialisierten Lösungen die wiederkehrenden Anforderungen einer Branche bereits mit – etwa Objektsuche, Eigentümerportal und Standortseiten für Immobilien (im Einsatz bei KAMPMEYER), oder Standort- und Kursstruktur für Bildung (im Einsatz bei Lernstudio Barbarossa, 165 Standorte). Das verkürzt die Implementierungszeit und gibt die Architektur-Entscheidungen vor, ohne den individuellen Plattform-Charakter aufzugeben.
AI-first means: for every task, we first check whether the problem can be solved better with AI. It does not mean using AI all the time. That is what sets us apart from approaches where AI is added later as a feature—at our company, it is the default that is consciously chosen or consciously rejected. In practice, this means that architecture, content structures, and processes are planned so that AI can operate on them—even if it is not yet being used today.
A traditional agency delivers projects. As a digital agency, we develop systems that continue to live on and evolve alongside the business. AI Native means: AI is the standard in the workflow, not an option or a feature. Specifically, three things set us apart: we have three in-house lab products (Infera, DialogHub, Immotelligence), we think in learning systems rather than finished builds, and our platforms are built so that they can be understood equally well by people and machines.
Digital sovereignty means: The company controls its own platform, without dependence on an agency. Specifically, this means that the content team, IT, and management can maintain, further develop, and evaluate the platform without external assistance. We do not deliver black-box solutions, but rather documented systems with accessible architecture. Anyone who wants to change providers should be able to take their platform with them.
A temporary, interdisciplinary body in the early project phase—typically 4–6 weeks. Three phases: orientation and problem understanding (weeks 1–2), ideation and solution concepts (weeks 3–4), decision-making and transition to implementation (weeks 5–6). Result: roadmap, scope, deliverables, design and structural concept. Afterward, the business unit takes over implementation—before a single line of code is written, it is clear what will be built and why.
Agent-ready means: systems are built so that autonomous AI agents can operate on them. Specifically, this requires three things: documented APIs, structured data, and traceable processes. This is not mandatory today – but it is an architectural decision that will either be made or not made within two years. Those who consider this now will not need to build a second platform once agents take over routine tasks.
The design system, the theme, and the block library belong to you, documented and without licensing ties to us. Your editorial team will be trained and can create new page types themselves. If you wish to switch, you take the theme, block library, and documentation with you and do not need to ask us.
Before implementation, we take stock of the existing content and decide for each page whether it will be retained, consolidated, or decommissioned. For every URL that is decommissioned, we set up a redirect so that rankings and linked documents do not lead to dead ends. For Lernstudio Barbarossa, for example, this affected more than 22,000 pages.
The price depends on the scope of the design system, the number of connected systems, and the condition of your existing content. A platform with one data source and one portal area is in a different price range than one with four. In a non-binding initial consultation, we can already provide a comparable budget range.
The Ideation Circle typically takes four to six weeks. Implementation follows in sprints, the number of which is determined by the volume of content types and system integrations. We provide a reliable schedule after the Ideation Circle, as it is only then that the number of page types and interfaces the platform will ultimately include is finalized.
WordPress Enterprise is a good fit if your editorial team edits the content themselves in the CMS. A headless setup is worthwhile if multiple front ends are served from a single source or the front end has its own application logic. For this, we use Payload CMS. The initial decision usually comes down to one question: How much should your team be able to change without developers?
The risk almost always lies in long-established plugin ecosystems. We keep the number of extensions low, manage dependencies via Composer, and develop functionality as custom blocks. After each update, this makes it possible to trace which component is new and what it affects.
A platform that is not only an interface for users, but can also be reliably read and accessed by machines and AI systems through clean data and open APIs.
For most B2B setups, WordPress is fully sufficient as a content system—HubSpot remains the CRM and marketing hub. HubSpot CMS only becomes worthwhile when the marketing team wants to deliver Smart Content tightly integrated with the pipeline and does not require WordPress ownership. If you already have an existing WordPress installation, you keep it—the integration is built for exactly this scenario.
The HubSpot tracking code is only loaded after active consent is given via the WordPress cookie consent layer. Before consent is given, the website does not send anything to HubSpot, and the contact remains anonymous. For existing contacts (logged-in members), the authorization setup stored in the CRM applies. HubSpot offers EU hosting with data processing in Frankfurt – a prerequisite for most GDPR setups.
HubSpot versions the public API and announces breaking changes with a defined lead time. Our adapter in WordPress is built against the respective API version, not against a daily snapshot. For a major version migration, the required adjustments are a documented, plannable sprint—not an emergency operation.
The HubSpot Contacts API allows reading and writing all standard and custom properties defined in the CRM. We jointly define which properties are synchronized bidirectionally in the Ideation Circle – including owner responsibility for each field. This ensures there are no “forgotten fields” that eventually remain empty in the CRM.
The integration has two levels of maintenance: API adapters (rare, only for version updates) and property mapping (more frequent, with every marketing change). The former is development work, planned quarterly. The latter remains with the marketing team – this is part of the integration, not a hidden ticket stream.
For teams with standard setups and a volume of up to approximately 50 deals per month, the native connector is generally sufficient. As soon as custom properties, industry-specific mapping rules, or reverse status syncs come into play, iPaaS middleware or custom middleware becomes worthwhile. We will review this in the Ideation Circle based on your specific data structure.
From kick-off to go-live, it typically takes 4–8 weeks for native or iPaaS setups and 8–14 weeks for custom middleware with mapping rules and a reporting bridge. The biggest variable is not the technology, but the clarification: Who on your team defines the mapping rules and decides which fields are synchronised?
Existing HubSpot contacts and ClickUp tasks are not automatically linked. We recommend a one-time initial mapping – either via script or using the AI-powered migration methodology we have developed. Subsequently, the sync will proceed incrementally.
The integration is part of your system landscape, not a black-box add-on. We document mapping rules, webhook configurations, and error logs so that your team can operate them independently. Continuous improvement (adjustment of mapping rules, new use cases) is handled through maintenance packages or on demand.
REST is the older, more prevalent architectural pattern: The requesting system calls a URL and receives a predefined dataset. GraphQL allows the requesting system to define precisely the fields it needs – this reduces data volume and complexity for large frontends. For most business integrations, REST is the appropriate choice; GraphQL is worthwhile when data volumes or frontend complexity exceed REST’s limitations.
That depends on the complexity of the data model, not on the number of fields. A standardized REST API with clear documentation (onOffice, HubSpot, Salesforce) can typically be connected for production use within 2–4 weeks once the data modeling is in place. With non-standard source systems—such as internal CRMs or legacy ERPs—the modeling alone can take several weeks, because it first has to be clarified which fields exist at all and how they relate to each other.
A resilient API integration accounts for outages. Cache layers retain the last valid data, fallback strategies display meaningful content instead of error messages, and monitoring reports the problem to IT before the user notices it. Platforms built without these mechanisms visibly collapse at the first failure of the source system – a typical symptom of integrations built without an architectural concept.
This question belongs in the contract, not in the final sprint retrospective. We recommend shared responsibility: The source system (CRM, ERP) is responsible for the API version and data quality; the platform side is responsible for cache, fallbacks, and monitoring. Both sides document their agreements—version changes, breaking changes, maintenance windows. Clear regulations determine whether it is later about content or about questions of blame.
Personal data is also subject to the GDPR within an API integration. Specifically, this means: documented data flows, clear purpose limitation, technical and organisational measures such as TLS encryption (Transport Layer Security), access restrictions and logging, as well as data processing agreements with the source system provider. For cloud APIs outside the EU, the question of Standard Contractual Clauses is added. If you do this properly, there will be no surprises in the GDPR audit.
That depends on the use case. For simple forms, Salesforce’s own Web-to-Lead path or a connector from the AppExchange is sufficient; as soon as custom objects, assignment rules, or bidirectional updates come into play, a custom API integration is the more robust choice. We evaluate both options at the start of the project.
Access is handled via OAuth 2.0 with a Connected App whose profile limits permissions to the required objects and fields. Tokens can be revoked, and there is no need to store access credentials in plain text. This ensures your IT retains control over which data leaves Salesforce.
Yes. The integration transfers leads in a way that ensures your existing assignment rules and owner logic in Salesforce continue to function. Your sales processes remain unchanged; the interface feeds them with clean data from the web. The extension is documented and encapsulated, so that your team or ours can maintain it.
The calls run asynchronously via a job scheduler that retries failed transmissions. An outage on the Salesforce side neither blocks page loading nor results in lost leads—they are submitted once the connection is restored.
If your sales data already flows into Salesforce, the direct connection speaks for itself: one less system in the data path, no additional contract, no double synchronization. An intermediate tool is only worthwhile if it handles its own tasks that Salesforce does not cover.
Yes, experience with AI tools is important. You should already have actively worked with tools such as ChatGPT, Claude, or Cursor. You do not need to be a prompt engineer, but you should have a basic affinity for the topic and genuine interest. You can deepen many of these skills with us.
Yes, remote work is possible with us. Our infrastructure and processes are designed for this. At the same time, we welcome regular on-site days in Cologne or Groß-Umstadt. We arrange the frequency and timing of your office visits flexibly per unit.
We work in units of approximately eight people each. Each unit has clearly defined responsibilities and operates largely autonomously.
Not necessarily. However, we would appreciate a brief introduction explaining why 360VIER is a good fit for you—a few sentences are perfectly sufficient.
We support you with an onboarding plan, a buddy system, and individual access to all relevant tools and systems. Nevertheless, things can move quickly in an agency.
We operate based on a circular organization without traditional hierarchies. There are several unit types: Business Units manage client projects from start to finish, Service Units provide cross-functional services, and Expert Units focus specialized knowledge in areas such as Artificial Intelligence, data management, or design.
Learn more here.
Hans Mengler
Managing Director
