AI in e-learning: How chatbots, adaptive learning systems and automation are revolutionizing learning
A contact person becomes machine-readable when their role, responsibility, language, location, contact method, and deputy are clearly and structurally defined. The guide demonstrates implementation using Person, Organization, ContactPoint, and JSON-LD.

To make a contact person machine-readable , their name, role, responsibilities, area of ​​expertise, language, location, contact method, availability, and deputy must be consistently provided. This information should be visible on the website and additionally stored as structured data. This allows interested parties, search engines, and AI systems to more easily attribute an inquiry to the right person, rather than just finding a generic email address.

Especially in small and medium-sized enterprises (SMEs) in South Tyrol, consulting, sales, press relations, support, and data protection are often handled by just a few people. If the website doesn't clearly separate these tasks, inquiries have to be reviewed and forwarded internally. From my work with SMEs, I know that it's usually not a lack of willingness to help, but rather a clear and structured system of responsibilities.

Definition: A machine-readable contact is a clearly described person or contact point whose role, responsibility, language, region and contact methods are specified both visibly on the website and in a standardized data format.

Make contact details machine-readable: You need this information

A name and email address are usually insufficient for unambiguous identification. The website must answer who can be contacted for which purpose, in which language, and in which region.

The necessary core areas

  • Name: the full name of the responsible person or a clear designation of the contact point.
  • Role: for example, sales management, technical consulting, press contact or data protection officer.
  • Responsibility: specific requests such as quote requests, complaints, media inquiries, or technical malfunctions.
  • Field of expertise: the main focus, for example photovoltaics, interior design, hotel software or business consulting.
  • Language: For example, German and Italian, supplemented by other languages ​​if needed.
  • Location or area: for example Bolzano, the Eisack Valley, all of South Tyrol, or the Italian market.
  • Contact method: Email, telephone, contact form or a central service number.
  • Reachability: Specific service times or a realistic estimate of the expected response time.
  • Representation: a second person or contact point for absences.

Useful additions

  • a recent photo so that the person can be recognized,
  • a brief professional profile and verifiable expertise,
  • the organizational assignment to the company,
  • a link to the visible personal profile,
  • an escalation point for urgent or unresolved issues.

These fields do not all need to appear on a single contact page. The crucial point is that the contact page, team page, services pages, and privacy policy page do not contain any conflicting information.

Why a general email address is not enough

A general address remains a useful starting point. Without further context, an address like... info@beispiel.it However, it cannot determine whether it is intended for sales, technical support, press, or data protection. A digital assistant is no more able to reliably determine the responsible role than a human being.

I often find phrases like "We are happy to answer any questions" in the communications of SMEs. Such a phrase doesn't name the responsible person or specify the nature of the issues being addressed. In particular, the following questions remain unanswered:

  • Who can advise me before I buy?
  • Who can help with a technical problem?
  • Who answers media inquiries?
  • Who is responsible for my location or area?
  • Can I discuss my request in German or Italian?
  • Who do I contact if the responsible person is absent?

Clear information reduces internal queries and forwarding. This allows a request to reach the right person with the necessary context.

Separate consulting, sales, press, support and data protection

Not every task needs a dedicated person. However, every task needs a clearly defined person responsible . In a small business, the same person can take on multiple roles. Nevertheless, the individual roles should be described separately.

  • Consultation: professional guidance, needs assessment and selection of a suitable solution.
  • Sale: Offers, terms and conditions, availability and order processing.
  • Press: Media inquiries, images, statements and interviews.
  • Support: Technical problems, complaints, maintenance and existing orders.
  • Privacy Policy: Inquiries regarding the processing of personal data and the exercise of data protection rights.

For example, one person might handle both consulting and sales. The website should then explicitly state that this person is the right contact for both. A contact point can also be functionally named, such as "Technical Support South Tyrol," if different team members handle the inquiries.

Special features regarding data protection

Data protection concerns should be addressed via a clearly designated contact option. If a data protection officer has been appointed in accordance with Article 37 GDPR, controllers or processors must publish their contact details and notify the supervisory authority. Article 37(7) does not necessarily require the publication of the name, as explained in the guidelines of the Article 29 Working Party.

A clearly identified address such as datenschutz@beispiel.it This may therefore be more suitable than using an employee's private contact details. If you are unsure which legal structure is necessary for your business, you should consult a qualified data protection advisor.

Visible personal profile and structured data combine

A visible personal profile tells people who they are talking to and what that person is responsible for. Structured data additionally presents selected information in a standardized format that software can process.

The machine-readable layer does not replace the visible content. A common mistake is to include detailed JSON-LD data while the visible website only displays a name without any role information. Conversely, a detailed team page may technically leave important relationships between the person, the department, and the contact point undefined.

Structured data must confirm the visible information. It should not contain any conflicting statements or statements intended solely for machine use.

I explain the interplay of content, relationships, and technical formats in more detail in the article about the content model of a website.

Person, Organization and ContactPoint explained in an easy-to-understand way

Schema.org provides defined types that a website can use to describe people, businesses, and contact points. The " Person" type in Schema.org describes a natural person. "Organization" represents a business or organization. "ContactPoint" represents a contact point for a specific purpose.

  • Person: Who is the specific contact person?
  • Organization: To which company does the person belong?
  • ContactPoint: How can the person or department be contacted regarding a specific request?

The ContactPoint type at Schema.org supports, among other things, three properties relevant to contact persons:

  • contactType: describes the type of contact point, for example sales, press or technical support.
  • availableLanguage: Indicates in which languages ​​contact is possible, for example using language codes. de and it.
  • areaServed: describes the area served, for example Bolzano, South Tyrol or Italy.

Additionally, a phone number, email address, and other contact information can be stored. JSON-LD is frequently used for the technical output because the data block can be displayed independently of the visible formatting. The quality and consistency of the underlying contact data remain crucial.

Before and after: a South Tyrolean service provider

The following fictional example shows a technical service provider from Bolzano with a German- and Italian-speaking target audience. Before the revision, the website contained only this information:

Before: "Questions? Write to us at info@montetechnik.example or give us a call.”

This information does not indicate whether the address is intended for an offer, a complaint, a press inquiry, or a data protection request. AI contact information cannot be clearly derived from it either.

The visible representation afterwards

  • Anna Hofer – Consulting and Sales / Consulenza e vendite: Consulting on new projects and proposal preparation; building technology expertise; German and Italian; responsible for Bolzano and South Tyrol; available Monday to Friday via anna.hofer@montetechnik.example and the business telephone number; represented by Marco Bianchi.
  • Marco Bianchi – Technical Support / Technical Assistance: Troubleshooting, maintenance, and questions regarding existing orders; technical service area; Italian and German; responsible for South Tyrol; reachable via support@montetechnik.exampleRepresented by Anna Hofer.
  • Press / Stampa: Media inquiries and image material via presse@montetechnik.example; supervised by the management.
  • Data protection / data protection: Data protection concerns about datenschutz@montetechnik.example.

On both the German and Italian websites, the name, email address, phone number, location, and organizational identity remain unchanged. What is translated is the role, area of ​​expertise, responsibilities, and explanatory text. Both language versions therefore describe the same person and the same contact point.

How to connect concepts and identities across languages ​​is explained in my article on a consistent German-Italian taxonomy.

Simplified JSON-LD for consulting

{
  "@context": "https://schema.org",
  "@graph": [
    {
      "@type": "Organization",
      "@id": "https://montetechnik.example/#organization",
      "name": "Montetechnik Beispiel",
      "contactPoint": {
        "@id": "https://montetechnik.example/#sales-contact"
      }
    },
    {
      "@type": "Person",
      "@id": "https://montetechnik.example/team/anna-hofer/#person",
      "name": "Anna Hofer",
      "jobTitle": "Beratung und Verkauf",
      "worksFor": {
        "@id": "https://montetechnik.example/#organization"
      },
      "contactPoint": {
        "@id": "https://montetechnik.example/#sales-contact"
      }
    },
    {
      "@type": "ContactPoint",
      "@id": "https://montetechnik.example/#sales-contact",
      "contactType": "sales",
      "email": "anna.hofer@montetechnik.example",
      "availableLanguage": ["de", "it"],
      "areaServed": "Südtirol"
    }
  ]
}

This example is intentionally simplified. In a production environment, the correct web address, business phone number, location data, and, if applicable, opening hours or service times would be added. Separate contact points with appropriate information could be provided for support, press, and data protection. contactType

German and Italian without dual identities

A multilingual website should not list the same person as two different contact persons. This problem arises when German and Italian pages are maintained independently.

There are four basic rules for care:

  • Keeping stable: Name, identity, business email address, phone number, location and internal identifier.
  • Translate: Role, responsibilities, area of ​​expertise, description and contact information.
  • Connect: Mark German and Italian profile pages as language variants of the same person.
  • Synchronize: Update changes to responsibilities, representation, or contact methods in all language versions.

I therefore recommend that small teams use a central data source. If the same contact details are entered separately on multiple pages and in multiple languages, the risk of conflicting information increases. Centralized data management reduces effort and improves data quality.

How btlabs Core contacts are structured

btlabs Core treats contact persons not just as text elements on a contact page, but as structured content objects. Person, role, responsibility, language, location, and contact point can be centrally maintained and used for different pages and output channels.

The goal is to represent contact persons in a machine-readable format while simultaneously reducing maintenance effort: language variants remain linked and structured outputs can be generated from the same data source. You can find an overview of this functional area in the btlabs Core website features overview.

Structured contact information does not guarantee a specific search engine ranking or a mention in an AI response. However, it helps systems to more clearly distinguish your business, its contacts, and their responsibilities.

The 15-minute self-check

Open the contact page, team page, services pages, and privacy page side by side. Then check the information in this order:

  • Minutes 1 to 3: Check that consulting, sales, press, support and data protection are clearly assigned.
  • Minutes 4 to 6: Search by name, role, field of expertise, language, location and contact method of each contact person.
  • Minutes 7 to 9: Compare German and Italian websites. Names and contact details must match.
  • Minutes 10 to 11: Check availability and coverage. Remove individuals who have left the company or are permanently absent.
  • Minutes 12 to 13: Check if the visible information and the JSON-LD contain the same statements.
  • Minute 14: Validate the structured data using a suitable schema validation tool.
  • Minute 15: Send a test request and check if it reaches the right person.

Prioritized implementation sequence

  • First: Clarify responsibilities internally.
  • Secondly: Publish easily understandable, visible profiles and contact details.
  • Third: Synchronize German and Italian data.
  • Fourth: Add Person, Organization and ContactPoint as structured data.
  • Funftens: Designate a responsible person for updates and representation.

FAQs

Is a general email address sufficient as a contact person?

A general email address can serve as a central point of contact, but without a description of responsibilities, it is rarely sufficient. At a minimum, specify what the address is intended for, which languages ​​are available, and who will handle the inquiries internally.

Does every role need its own person?

No. In a small business, one person can take on multiple roles, such as consulting and sales. Nevertheless, describe each responsibility individually so that people and systems can recognize which issues should be addressed to that person.

How do I specify a substitute?

Specify a permanent representative or a functional alternative address, for example support@beispiel.itAvoid short-term notices that remain online after an absence; a permanently maintained substitution rule is better.

Am I allowed to publish the private contact details of employees?

Always use business contact channels and only publish personal information on a legally sound basis. Private mobile phone numbers or personal addresses are usually neither necessary nor appropriate for a visible personal profile.

How do I handle multiple locations and languages?

Assign each contact point to the appropriate area via its location or areaServed to and enter the available languages ​​via availableLanguage In German and Italian, identity and core data remain stable, while roles and descriptions are translated.

How do I check structured contact data?

First, compare the visible information with the generated JSON-LD and then check the technical syntax using a schema validator. Additionally, perform real test requests, because formally valid data is useless if emails end up with the wrong person internally.

Does every contact person need their own personal profile?

For key roles, a dedicated profile is useful because role, area of ​​expertise, language, and responsibilities can be clearly combined. For rotating service teams, a clearly designated ContactPoint may be more suitable than publishing numerous individual names.

Do structured contact details automatically generate better AI responses?

No, automatic identification or a correct answer cannot be guaranteed. However, clear, visible information and consistent, structured data reduce ambiguity and facilitate the assignment of person, company, task, and contact method.

Conclusion: Identify contact persons in a machine-readable and unambiguous manner.

If you want to make a contact person machine-readable , start with organizational clarity, not JSON-LD. First, define their role, area of ​​expertise, responsibilities, language, location, contact method, availability, and backup. Make this information publicly available and then map the same information using Person, Organization, and ContactPoint.

The result is more relevant inquiries, fewer internal referrals, and direct contact with the responsible person. The technology supports clear organization and reliable communication.

If you would like to check the contact persons listed on your website, you can reach Berger+Team at info@berger.team , by phone, or via WhatsApp at +39 346 1033 556. I am the founder and main contact person of Berger+Team in Bolzano. Regular business hours are Monday from 14 pm to 17 pm, Tuesday to Thursday from 9 am to 11 am and from 14 pm to 17 pm, and Friday from 9 am to 11 am.

Florian Berger
Bloggerei.de