TOMP-WG / TOMP-API

Transport Operator to Mobility-as-a-Service Provider-API development for Mobility as a Service
Apache License 2.0
96 stars 40 forks source link

[FEATURE REQUEST] Allow the TO to provide his terms&conditions within the offer #526

Open matt-wirtz opened 7 months ago

matt-wirtz commented 7 months ago

Is your feature request related to a problem? Please describe.

Following only applies for the cooperation model broker: When end users want to use the offer of a TO they do it on the bases of the TO's terms&conditions. In order for the MP to make the end user aware of the currently valid terms&conditions a link to them should be provided within the offer.

Urgency

Minor: this feature is a nice to have, because it prevents solutions where URLs to the terms&conditions are stored locally in an app or configured statically on MP's system.

Describe the solution you'd like

Add another userCommunication goal in the information object, e.g. TERMS_CONDITIONS. Right now there are available: INSTRUCTIONS, SALES. That should be amended by TERMS_CONDITIONS.

Describe alternatives you've considered

Possible Implementation

goal: description: the purpose of the information type: string enum: [INSTRUCTIONS, SALES, TERMS_CONDITIONS]

edwinvandenbelt commented 6 months ago

On the other hand, we already have all kinds of conditions on the leg. But I agree, we should have an additional step in the booking phase, to demand showing the terms&conditions.

edwinvandenbelt commented 6 months ago

How about this: extend the enumeration in the planningStep (v.1.5): SHOW_TERMS_CONDITIONS and extend the condition object with the description to show to the end user.

condition:
  type: object
  properties:
     + userText:
           description: text describing this condition, to show to the end user in the offer phase. Booking the leg with this condition
              implicitly means accepting this condition.
           type: string
matt-wirtz commented 6 months ago

My understanding is that the terms&conditions need at least to be read and approved by the end user immediately before the booking is triggered. So e.g. in the app there is a "booking" button which reads "by booking this service you adhere to the terms&conditions of the TO".

So at this time point when the terms&conditions need to be made available for the end user there doesn't exist a booking yet. If there is a booking - independent of it's state - the end user has already agreed to the terms&conditions.

To me that sounds like showing the terms&conditions is not a booking step because there is no booking yet. So it should be part of the planningStep:

planningStep:
    type: object
    description: this action allows to publish advertisements together with the proposed leg.
    allOf:
    - $ref: "#/components/schemas/information"
    - type: object
      properties:
        action:
          type: string
          description: the `RESULT_SHOWN` action requires the MP to display some information to the customer when it is viewing the proposed legs.
          enum: [  SHOW_TERMS_CONDITION, RESULT_SHOWN ]

I think the existing action "RESULT_SHOWN" has a more informative character but doesn't include contractual relevant information. And the info should be displayed when viewing the leg. In the case of the terms&conditions they must not necessarily be shown when viewing the leg but when booking it.

What if the MP wants to book legs with different TOs for an intermodal trip? Then the end user will presented multiple terms&conditions and he needs to approve all of them at once. But that is then the job of the MP to coordinate this.

edwinvandenbelt commented 6 months ago

Regarding your last point: completely agree. It's up to them how to cope with that. But the option to show (and agree) the terms & conditions is part of the booking process. Otherwise, the end user should be confronted with the T&Cs of each option. Maybe it should be a mix of both: In the planning phase, there should be the SHOW_TERM_CONDITIONS, including your first proposal. Secondly, there should be an additional condition: agreedOnTermsAndConditionsCondition (name to be discussed), to highlight that the SHOW_TERMS_CONDITION is not allowed to be skipped.

So, in short:

Information - enum: [INSTRUCTIONS, SALES, TERMS_CONDITIONS]
planningStep - enum: [  SHOW_TERMS_CONDITION, RESULT_SHOWN ]
+ new condition subclass to indicate to highlight that this step is a real condition

On the other hand, making use of 3 concepts is complicated. Let's discuss next meeting!

edwinvandenbelt commented 6 months ago

@matt-wirtz :I've pick up this issue, added the enum value 'SHOW_TERMS_CONDITIONS' to the planningStep. The real question is, where the MP can find the T&C? In the booking object (also used in the offers, we do have the userCommunications-array. In this array we can supply Information objects. Depending on the configuration in there, the text of the T&C can be found (url or text). Together with your proposal to extend the 'goal' enum with 'TERMS_CONDITIONS', this looks doable to me.

itziweb commented 2 months ago

At carsharing.link the consent to TO's terms is a required step within booking. It is the responibility of the MP to do that properly. However we are thinking about solutions to provide the TO with the possibility of any kind of confirmation. Maybe some hash/signature of the content+consent as response value....

And there are ideas to make the system more universal. With Edwin I've already discussed the idea of standardization and modularity (textblocks).... Another idea is to make the consent system unviversal to use it for other actions as well. E.g. required vehicle check in preparing-phase, or some kind of confirmation on the end... 🤔