Answers.Body: <p>I've done something similar to this recently, and I went through the same though process as you've done!</p>
  <p>I initially added a new Channel for plans, and built each plan as an entry in that channel. These were then selected in an Entries field for the pricing page entry. However, after building this solution locally, I felt like it was overkill for my particular use case.</p>
  <p>In the end, I asked myself 'Will I need to reuse any of the data that's shown for each pricing plan anywhere else?' and the answer was 'no'. I removed the plans channel and ended up using a Super Table field in my pricing page entry type, with fields for the plan details inside the Super Table.</p>
  <p>This was specific to my use case though, where I knew I wouldn't need to surface the plan data on any other pages. If you do need to reuse plan data elsewhere - and you probably will - then I'd stick with my original solution of defining the plans in a Channel as entries that can then be selected in an Entries field in your pricing page entry type. This way, the data for each plan is held in a single place and you get all the standard entry functionality (like draft entries, date expiry etc.) for your plans, which can be helpful.</p>
  
Answers.ContentLicense: CC BY-SA 4.0
Answers.CreationDate: 2021-03-15T12:25:54.987Z
Answers.LastActivityDate: 2021-03-15T12:25:54.987Z
Answers.UserDisplayName: Martin Spain
Body: <p>CraftCMS gives us so many ways/options on how to build pages that I'd love to see what people are doing with their pricing pages!</p>
  <p>I'm planning on building something similar to <a href="https://www.amilia.com/pricing" rel="nofollow noreferrer">Amilia.com</a> or <a href="https://slack.com/intl/en-ca/pricing" rel="nofollow noreferrer">Slack.com</a>.</p>
  <p>My thoughts:</p>
  <ul>
  <li>Create 1 single page for the pricing page.</li>
  <li>Create 3 entries in a structure for the 3 plans? (Or I don't need this?)</li>
  <li>Create a features structure for all features?</li>
  <li>For each feature entry put a field for each pricing plan?</li>
  <li>Or do I just make it using a matrix field with a super table field?</li>
  </ul>
  <p>I'd love to hear the best practices and what would be the best way to build a pricing page and all of its content. Thanks!</p>
  
Tags: <field><structure><entries-field><pricing>
Title: Best Practice on how to build a Pricing Page on CraftCMS
ThreadText: # Best Practice on how to build a Pricing Page on CraftCMS
  
  (Asked by: username_0 on 2021-03-13)
  
  CraftCMS gives us so many ways/options on how to build pages that I'd love to see what people are doing with their pricing pages!
  
  I'm planning on building something similar to [Amilia.com](https://www.amilia.com/pricing) or [Slack.com](https://slack.com/intl/en-ca/pricing).
  
  My thoughts:
  
  * Create 1 single page for the pricing page.
  * Create 3 entries in a structure for the 3 plans? (Or I don't need this?)
  * Create a features structure for all features?
  * For each feature entry put a field for each pricing plan?
  * Or do I just make it using a matrix field with a super table field?
  
  I'd love to hear the best practices and what would be the best way to build a pricing page and all of its content. Thanks!
  
  **Tags:** field, structure, entries-field, pricing
  
  
  ---
  
  ## 1 answers
  
  ### Answer by username_1 on 2021-03-15. Score: 2
  
  I've done something similar to this recently, and I went through the same though process as you've done!
  
  I initially added a new Channel for plans, and built each plan as an entry in that channel. These were then selected in an Entries field for the pricing page entry. However, after building this solution locally, I felt like it was overkill for my particular use case.
  
  In the end, I asked myself 'Will I need to reuse any of the data that's shown for each pricing plan anywhere else?' and the answer was 'no'. I removed the plans channel and ended up using a Super Table field in my pricing page entry type, with fields for the plan details inside the Super Table.
  
  This was specific to my use case though, where I knew I wouldn't need to surface the plan data on any other pages. If you do need to reuse plan data elsewhere - and you probably will - then I'd stick with my original solution of defining the plans in a Channel as entries that can then be selected in an Entries field in your pricing page entry type. This way, the data for each plan is held in a single place and you get all the standard entry functionality (like draft entries, date expiry etc.) for your plans, which can be helpful.
  
  
  ---
  
  