Customer Driven Schema
This page provides the overview for data schema developed by Customer Commons and/ or the VRM community. These schema are designed to be machine readable, and can be delivered as a sub-component with a JLINC information sharing agreement.
Check out the demo!
— Customer Driven Schema Overview
This page provides the overview for data schema developed by Customer Commons and/ or the VRM community. These schema are designed to be machine readable, and can be delivered as a sub-component with a JLINC information sharing agreement.
- Intentcasting base schema demo (delivering intentcast as a Salesforce lead)
- Customer satisfaction tracking (based on Net Promoter)
- Ratings/ Reviews
- Site Registration
- Newsletter sign-up
- Preference centre
- Cookie Consent
- Renewal
- Complaint
- I Own
- I Use
- I’ve Sold
- Customer Driven Segmentation
Welcome to the “Intercasting — Intentcasting Base Schema Demo”
This section provides a detailed overview of the customer/user-driven terms developed by Customer Commons and the broader Vendor Relationship Management (VRM) community. These terms are meticulously crafted to be machine-readable and can be seamlessly integrated as a sub-component within a JLINC information sharing agreement.
Intercasting
— Intentcasting Base Schema Demo
This page provides the overview for customer/ user driven terms developed by Customer Commons and/ or the VRM community. These terms are designed to be machine readable, and can be delivered as a sub-component with a JLINC information sharing agreement.
TERMS AGREEMENT: {{ Information can only be shared with those parties who first agree to abide by these terms. Any sharing of information with a party that has not first agreed to these terms is a violation of these terms. }}
Terms Agreement Overview:
Information may only be shared with parties who have explicitly agreed to abide by these stipulated terms. Any dissemination of information to a party that has not previously consented to these terms constitutes a violation.
— Key Features of the Intentcasting Terms:
- Intentcasting Base Schema: This schema allows users to express their purchasing intentions clearly and concisely, making it easier for suppliers to understand and meet customer needs.
- Customizable Components: Each term within the schema, such as “Response to Request for Offers” with or without analysis, is designed to cater to diverse business scenarios and customer requirements.
- Dynamic Attributes: Attributes like location, price range, preferred suppliers, and specific requirements are adjustable, ensuring a flexible and targeted approach to market interactions.
- Communication Preferences: The schema accommodates preferences regarding how intentcasts are sent and received, ensuring compatibility with the user’s operational capabilities.
This platform is not just a tool but a framework for facilitating efficient and respectful exchanges between customers and vendors, adhering to a mutually agreed set of rules to enhance trust and cooperation in the digital marketplace. Whether you are integrating this schema into existing systems or exploring its potential for new applications, this guide serves as your starting point for adopting a customer-centric approach in digital transactions.
Intentcasting Terms Overview
Intentcasting Terms Overview
| Intent Cast Attribute Name | Expected Data Type | Nature of the Component | Example | Logic |
|---|---|---|---|---|
| RequirementID | Text | Key Component | 578ea22fe0b14f934456b780 | Each intentcast will need a locally unique identifier to enable it to be found and used in related systems |
| FindTermCategory | Text | Optional Filter | Home and Garden | There are scenarios where it will be useful for the intent caster to specify the context around their requirement |
| FindTerm | Text | Key Component | Garden table and chairs | This defines what the intentcaster is looking for in the marketplace. |
| Location | “latitude,longitude” | Optional Filter | 37.745919,-119.533199 | Each intentcast will require some form of geographic identifier; a number of options exist until we choose/ feel able to standardise. |
| RequirementStage | Text | Optional Meta data | Evaluating Short List | Each intentcast can optionally describe which stage in the buying/ selling process then current request relates to. |
| MinimumPriceGBPounds | Currency | Optional Filter | 250 | Each intentcast can optionally set a minumum unit price as relates to the product/ service sought. |
| MaximumPriceGBPounds | Currency | Optional Filter | 600 | Each intentcast can optionally set a maximum unit price as relates to the product/ service sought. |
| PreferredSupplierOptions | Text | Optional Driil Down Filter | John Lewis, Debenhams | Each intentcast can optionally specifiy one or more organisations that they would specifically wish to respond to their request. |
| FindTermSpecificAttributes | Text | Optional Filter(s) | Driven, in the interim, from cell A3 | The base intentcasting schema requires extensibility in order to support more complex purchasing decisions and processes (e.g. buying a car) |
| Beneficiary | Text | Optional Meta data | Household | In practice, many purchases are made by people, not for themselves, but for others – this may shape some of the input data and be a useful optional attribute |
| RequirementStartDate | Date_Time | Optional Filter | 20/07/2016 | This key, but optional, filter defines the date from which the intentcast should be seen as ‘live’, i.e. can be responded to. |
| RequirementEndDate | Date_Time | Optional Filter | 27/07/2016 | This key, but optional filter defines the date from which the intentcast should be seen as ‘closed’, i.e. it should no longer be responded to. |
| OutboundCommunicationsChannels | Text | Optional Filter | Web Service | This optional descriptor defines the method through which the intencast will be communicated from purchaser to the market place. In turn this defines some of the capabilities of the intentcast |
| InboundCommunicationsChannelPreferences | Text | Optional Filter | Web Service | This optional descriptor defines the method thruugh which the purchaser would prefer that the intencast be responded to by market place. In turn this defines some of the capabilities of the intentcast |
| InboundCommunicationTimingPreferences | Text | Optional Filter | 19:00 to 21:00 | This optional descriptor defines the time window in which the purchaser would prefer that the intencast be responded to by market place. In turn this defines some of the capabilities of the intentcast |
| InboundCommunicationIdentifier | Text | Key Component | Iainhenderson@mac.com | Identifier to be used in Intentcast response |
| UserSubmittedSharingTerm(s) | IRI | Key Component | CuCo IT 1 | This key component defines the terms under which this intentcast is being released |
Ensuring Data Integrity and Compliance through User-Submitted Terms
In today’s digital marketplace, transparency and control over data are paramount. Below are two sets of user-submitted terms designed to outline specific conditions under which information can be shared in response to requests for offers. These terms ensure that all data sharing adheres strictly to the agreed-upon guidelines, protecting both the data provider and the recipient.
User Submitted Term 1: Response to Request for Offers, Including Analysis
—Term 1 establishes a framework where information can only be disseminated to parties who have explicitly agreed to abide by the set terms. This agreement emphasizes the importance of consent and limits the use of shared data to the specific purpose of responding to buying intentions and conducting statistical analysis within the site. It restricts sharing and sets a clear duration of 30 days from the date and time of consent.
User Submitted Term 2: Response to Request for Offers, Excluding Analysis
—Term 2 mirrors the first in its rigorous demand for agreement to terms before any data exchange. However, it differentiates by excluding any analytical use of the shared data, focusing solely on responding to buying intention requests for offers. Like Term 1, it prohibits sharing without consent and specifies the same duration limit. Both terms exemplify a structured approach to handling sensitive information in commercial interactions, ensuring that all parties remain compliant with data protection standards.
—User Submitted Term 1
Term 1 (Response to Request for Offers, inc Analysis)
TERMS AGREEMENT: {{ Information can only be shared with those parties who first agree to abide by these terms. Any sharing of information with a party that has not first agreed to these terms is a violation of these terms. }}
Parameters:
- Sharing: No
- Duration: 30 days from date/ time of consent
- Purpose: Response to Buying Intention Request for Offers, Statistical Analysis within Site
—User Submitted Term 2
Term 2 (Response to Request for Offers, No Analysis)
TERMS AGREEMENT: {{ Information can only be shared with those parties who first agree to abide by these terms. Any sharing of information with a party that has not first agreed to these terms is a violation of these terms. }}
Parameters:
- Sharing: No
- Duration: 30 days from date/ time of consent
- Purpose: Response to Buying Intention Request for Offers