everyone. I like to make dramatic entrances. I'm Zach, I'm a product manager on the Chrome team, and I spend most of my days thinking about how we can make payments on the web, particularly on the mobile web, easier, less painful, and all around better experiences for our users. So I'm really excited by the Critical Management API, especially for someone who talks to e-commerce people all day long and people who sell high engagement and easy sign-in is really critical, and it's really great. But if you think registration forms are difficult, we should talk about checkout forms. A lot more form fields, a lot more questions. But I think that you're going to see a consistent theme emerging through our talks here today, which is this one of, let the browser help you. There are certain advantages that we have as a browser, especially when it comes to reducing friction and making life easier for users, especially things around repetitive data sets, things that the users can store inside of the browsers. What we're trying to do are expose APIs and give you tools to reduce friction and make things easier for your users. We saw it in credential management and we'll see a very similar theme with what we're doing in payments. But first, a little user activity just before we go off for lunch, which are some questions. Okay, great. So first question, just curious, how many people here actually enjoy the process of buying something on the web using their mobile device? Okay, good. Some people. But by large, no. And by the way, we should come talk. I'd love to hear what it is that you like about buying things on the mobile web and what it is that you don't as much. Second question, and I'm going to be really impressed here, how many people can remember all the details of their credit card? I'm talking full 16-digit number. Really? CVC and expiration? Okay, that's more than I expected. I've got to be honest. Okay, we're still under 15%. Okay, because I've been doing payments now for 18 months and I think I have yet to remember a credit card number. That's great. Final question, how many people enjoy the process of handing over all of their sensitive credit card information to a random third-party server? I knew it. I got one. It's almost like I'm asking these questions to lead up to a particular point. And there is a point. And the reality is that most users find payment difficult. They find it insecure and scary and frightening. And they find the process of doing it on the mobile web particularly bad. And so we had this number. We talked about it at IO as well. And it hasn't really changed, which is that on average, we tend to see about 66% fewer conversions on mobile than on desktop. And again, we think there's an answer to that, which is all around, again, high friction, the difficulty, and issues around trustworthiness and security. And so we'll talk about sort of how we're addressing those today and how we're trying to bring fast, simple, and secure payments to the web platform. But this is a little, I'm a PM, but this is a little bit too PME for me actually. And so I have a much better mission for us inside of the Chrome team, which is we're trying to save the world from annoying checkout forms. So I'm trying to save the world from virtual keyboards and having to memorize and all of those terrible things. I actually started this joke, the Better Payments Bureau, a couple of months ago. And now it's become like a thing. So anyway, but actually Chrome has been fighting the good fight against annoying checkout forms for many years actually. We started with Autofill back in the day. You guys are probably familiar with Autofill. This is my one slide on it. It's not really the topic today. But consider this my 10-second plea to say, if nothing else, leave today and set autocomplete types on your checkout forms. It helps us. It helps the users. It helps the browsers. And it basically ensures 100% accuracy on Autofill. But I'm not here to talk about that today. I'm really here to talk today about payment requests, which is this new API that we're building for the web to really help solve a lot of the problems I've been talking about. But before I talk about what payment request is, I want to talk about what payment request isn't. And that's because payment is complicated. There are a lot of players in the space. And I just want to sort of set up fronts and sort of help alleviate any confusion. So the first thing, payment request is not a new payment method. So we're not trying to create Chrome pay or browser pay or yet another X pay button on your website. That's not fundamental to our goal. Our goal is to help users pay that they what the way that they want to pay and do it quickly and efficiently. Secondly, we are not trying to become a gateway or a processor or some entity that literally moves money in the ecosystem. So we're not trying to step on any toes here or like enter into this ecosystem. We think that the market has actually done an incredible job here already. Players like Stripe and Braintree and others have done a really stellar job over the last couple of years of taking the incredible complexity of accepting online payments and making it really simple. They've removed the burden of things like acquiring banks and all the, you know, even some levels of PCI and they put it all into like an easy to use API. And so our goal is to ensure that whatever we do plays really nicely with all these gateways and processors, but that's not fundamental to our goal to become one. The thing about all these great new services though is that they've really focused on developers, which is great. They've made your lives easier and they made easier for you to accept payments. But the user experience has largely remained the same. You have to go from this state where you know nothing to a user to everything and form fields tend to be the way that we do this. So payment request was fundamentally built for users. I mean, we think it's pretty good for developers too and it's pretty easy and we'll sort of talk about code samples. But fundamentally, like my goal, I think about users and how I can help them and help them get through these burdensome flows on mobile faster and more efficiently. So what exactly is payment request? Well, payment request, like I said, is a new standards-based API. And standards-based, I want to emphasize that. We joined the web payments working group almost a couple of years ago now and every major browser is a vendor. We have financial institutions from around the globe and we're trying really hard to build something that everyone can integrate, that all forms of payment can integrate with and all browsers can do so that users on a variety of devices and ecosystems can continue to leverage and have the benefit of it. We're just in the early stages of it and sort of we'll talk about where we're at. But that's sort of fundamentally our goal. And so when we started to think about what design this API looked like, we had two high-level goals in mind and they sort of referenced back to my original question set. The first one is we wanted to build a seamless, easy-to-use checkout experience on mobile in particular. We wanted to make sure that users like could minimize typing and minimize friction as much as possible. And the second thing is we really want to bring more secure payments into the web platform. In many ways, the web is one of the last places where it's very common place to exchange over all of your sensitive information to some unknown third party. And even though there's an answer to this from the payments community with regard to tokenization, the web really didn't have a great answer for that. Which is why we're really excited that we brought Android Pay into the web platform and again we'll continue to expand that. But this brings tokenized forms of payment, so in the event of data breach or other problems, users are protected, but it also reduces the burden for you as developers and merchants. And so those are our two high-level goals that we had. And again, the idea here just at a high level is that if you think of your traditional checkout flow, it looks something like this. It's anywhere from like two to five pages, maybe one for single page things. And you have somewhere between 10 and 40 form fields where you're asking a variety of questions, things like what's your name, what's your shipping address, what's your email, what's your phone number, what's your credit card number, what's your expiration. And then you have users who are trying to do all this on their mobile device and at some point they're like meh. And they kind of give up and maybe they go to desktop later or most likely they don't. And Darren talked a lot about the growth of mobile, right? And so we really think we need to fix this and make this easier. And the way this happens with payment requests is you can imagine that the browser sort of plays this role and helps facilitate checkout across the highest fiction point. So we take that common set of data, those common things that you request and sort of leverage our strengths to make it easier for users to be successful. So before I show you a demo, I want to talk about what types of data is actually supported by payment request. So the first one's probably a little bit obvious, but it's a form of payments. So at the end of the day, you need a way to actually request money from the ecosystem. So you need some sort of form of payments. Right now in Chrome, we support two. We support credit cards and Android pay. I put et cetera on here because the plan is to support more, but we'll talk about that a bit more later. And so you always have to request a form of payment. You can't call payment requests and not want a form of payment. That would just be weird. And then it would just be request arbitrary user data API. So the other big thing that we like to request is shipping address and shipping options. So for physical good purchases, you can leverage the API to say, hey, give me their shipping address. And then there's a dynamic mechanism for you to take that address and then populate shipping options that have updated pricing, et cetera. You can also request a phone number. You can request an email address, of course, for sending a receipt or even prompting sign up afterwards. And coming soon, actually, but not quite there, but in the next couple of months is pay or name support. And these are all flexible. You can request any of these or none of these if you want. The idea is to support a broad range of use cases out there.  Or if you're a physical good, you may or may not need their pay or name because you'll get that from the shipping address. So it's flexible and you can accommodate experiences as fits your business. But the really important point here is that all of these data points can be stored and returned by the browser. So users, by and large, trust Chrome to store this data. They trust us to store their names, their emails, and even their credit card data. And so the question is, why put users through the burden of a form that they have to fill out manually? And you saw Sabine slide about fat fingering and the difficulty of mobile keyboard typing. And those problems are multiplied across all those form fields. So if you can save them, the burden of doing that, we think it's worthwhile. And sort of payment request is really designed to do that. But let's go ahead and just sort of see it in action. So switch over to a demo here. Let's see if we can see. Oh, right. Excellent. I'm going to open up Chrome on stable. And I'm actually going to use the exact same shop API that's, oh, and you see it auto signed man. You have to love when a good demo goes right. But otherwise, it's the exact same website, Polymer shop demo, except I'm going to go a little bit further and actually just make a purchase. So I hit the shop now button. You know, I definitely don't have enough Google hoodies. So I'll just switch shirts. I'll just buy yet another one. So standard shop, you see that there's like size and quantity. I won't affect those. But you see that there's two buttons at the bottom. There's a typical add to cart button. But there's also this buy now button. That buy now button is based on feature detection. So we're checking to see if payment request exists. And if it's there, great. Let's leverage it. And if not, you would just see an add to cart. But I'm going to end use the rapid checkout approach. And so I tap on the buy now button. And you see that this payment sheet slides up from the bottom. This is payment request in action. So you're looking at sort of natively drawn UI. It's controlled by us. We can throw it. But it's populated with data from the merchant. So you see that my total amount is there, $22.15. I default to my form of payment that I prefer, which is Android Pay if it's available, only because it's faster and more secure. You see that they're also requesting my email address for the purpose of sending a receipt. And the only thing I need to do here is select a shipping address. It's very difficult to ship a sweatshirt to someone if you don't know where it goes. So I'll tap on that. You'll see that the payment sheet slides up to full screen. And it has my addresses automatically populated for use. These are our two Google offices here. So I'll go ahead and ship to the one in San Francisco where I work. And you see that when I do that, the shipping options are automatically populated there. And so we have a free shipping in California option or an express shipping. And if I change those, it'll dynamically change the price. So you can see here that express shipping changes. But of course, why would I pay more? I'm going to go back to zero. That seems to make a whole lot more sense to me. And now I'm ready to pay. So I just have the pay button. And then you'll see the Android Pay screen slide directly up. We're running the test app. So it says unrecognized. You guys wouldn't have that. And because I've actually authenticated in the last couple of minutes, I don't even have to do any extra authentication on Android Pay. I'll literally just tap the continue button. A response comes back and the transaction in order is successful. So pay with Android Pay, no keyboard, no typing. All I had to do was tap and select and confirm my shipping addresses. So really great, really seamless. We're really excited about it. And just to show you that if you don't have Android Pay available, no big deal, we can always change our form of payment. And if I didn't have Android Pay, I would just default back to my credit card, in this case a Visa card that I have. Once again, I'll select my shipping address and options. I hit the pay. And the only thing, the only keyboard we can't get rid of is the CVC input. Everything else we have. So I'm going to do one, two, three. I used to do like a live credit card on this. And I discovered that that didn't work well for me. So I've switched to a demo card. But either way, the same concept applies. We'll talk about what's happening behind the scenes, but this is all client side, so it's all happening super fast and pretty great. We're really excited about that. And now maybe we can switch back to the slides and talk more about what it takes to make this actually happen. So how do you leverage payment requests? Well, it's pretty simple. There are three parts to payment requests, two of which are that are required and one of which is completely optional. And so we'll talk about them in order. The very first one are payment methods. So we need to know basically all the ways that you can get paid. This could be a wide variety of things in the future. So it could be I accept Visa and Mastercard and AMX and Discover, JCB, Union Pay. It could be in the future, I accept Allipay or Ideal or PayPal, et cetera, as long as people are built into the ecosystem. Like I said, for now, Chrome, we just launched. So we're starting with credit card support and Android Pay. And so it looks a little bit like this. So we basically pass in this thing called method data and method data is an array of objects and those objects each have an array of supported payment methods. So you can see here that the first thing I support are credit cards. I support the standard for Visa, Mastercard, AMX and Discover. That's it. Nothing else to do it, just as I accept this. In the future, coming out in a couple of months, we have added support for granularity for things like debit or credit or prepaid. But for right now, essentially, when you say Visa, we sort of assume you can accept all Visa and don't make a strong differentiation there. But the second one is a little bit more interesting and this is Android Pay. This is sort of an abbreviated version of this, but to support Android Pay, you see that there's an additional key inside of that object, which is the data. Data is sort of a generic object and it's payment method specific. The reality is that different payment methods out there have different dependencies, different things that you're going to pass in when you instantiate it by default. So for Android Pay, for example, you always have to pass in your merchant ID, you have to pass in what kind of token you would like, either network or gateway. We don't have a full example here. And then what happens then is when a user chooses to pay with one of those forms of payment, we basically bundle it all up and pass it on to the payment app. And then the payment app uses that data plus things like origin and assertions from Chrome to basically verify that the payment app is the right one and so the payment can continue. So it's pretty simple, but the idea here is that you throw everything you can at the browser for ways that you accept payment. So if you can accept 100 different ways of paying around the globe, tell us 100 different ways to pay because what the browser does is we find that spot in the middle between the set of ways you can get paid and a way that a user can pay you and give a user an optimized experience about the ones that make the most sense for them. So you saw, for example, in the demo that Android Pay and a Visa card were available, but let's say that we had removed Visa as an option, then Visa just wouldn't show up because that doesn't make any sense. And so as you go around across the globe, there are a wide variety of ways to pay, but we recommend giving us all to them and then we'll find the best experience for the user to optimize around their preferences, their defaults, and what is the best thing for them. The second bit of data is also quite important. So now that we know how I can pay you, we need to know how much money you want to get paid. And this is what this looks like. Great. So the first thing, the most important thing that's required is this total attribute. Three parts, basically, or two parts really. The first one's a label, so we customize this. So if you tell us total will display total, but this could be like authorization, donation, whatever you want. And we have to know an amount. An amount is composed of a total amount of money and an underlying currency code. So we know, for example, the underlying payment app that we transfer to knows what currency to charge in. We're also to sport display items. So just like I showed you, when I tapped on the total, those line items came down that basically told you how the total amount was reached. We also support this. It's fully optional. You can pass in if you want or ignore it. We recommend it. It's nice to give a high-level overview to a user about the things that inform the total amount, things like the subtotal, tax, shipping costs, et cetera. Less of like a full itemized receipt and again, more of like a high-level overview. One important point. Payment request does not do math. We're not good at floating point math. So if you pass in, you know, you have two line items that sum to five and your total says four, like, we're not going to throw anything. So you're totally in control of this thing. So just keep that in mind. And there, by the way, might be some use cases where it makes sense for those not to align. But by and large, I just want to point that out. The other point to note is that transaction details can also contain shipping options. And in this case, if you put them in there by default, we support default shipping options. We only recommend you use this if you're highly confident that your shipping options will not change, as in they're not dynamic. So if you support, for example, worldwide free shipping and it never changes no matter what the address is, feel free to default populate this. But if your shipping is dependent upon a user address, then we recommend waiting until you've gotten a user address event, which we'll talk about a little bit. And then you can use that to dynamically query against whatever service you use to calculate prices. And you can repopulate this. And that's an important point that basically the transaction details object can actually be updated and overwritten throughout the lifecycle of payment requests at certain events and points. So if a user changes their shipping option, you saw like how in my demo, when I changed my shipping option, the price change in the list items changed. That's because when that event took place, we repopulated those set of transaction details. And so you have that flexibility and control on those events. And so that's how we get sort of that dynamic pricing model that exists out there. And so, again, don't do default shipping options unless you're highly confident they aren't going to change. And the final piece is the extra information, the optional set of options. And that's the things I talked about. User address, shipping support, name, email, and phone, all entirely optional, but definitely useful. I think there was sort of this myth out there that the only drop-off point in the funnel is the process of putting in your credit card. But really, the entire checkout funnel is, well, a funnel. And so wherever your users experience friction and there's a step, there's a drop-off. So we highly recommend taking advantage of these different pieces. And so there's a few that we support, like I said, and it's as simple as passing in just a bunch of booleans, basically. Do I want shipping? Yes. Do I want email? Yes, et cetera. And you can, again, these can be variables. You can say I don't want shipping, but I do want a name and phone number. Or you can say I just want an email address to send a receipt to, for example. It's completely configurable. And again, the idea here is to support a wide variety of use cases. Something funny that is minor that we have coming soon in the next couple of months is we're adding support as well for a shipping type value. It's pretty simple, but the idea here is that, let's say you are buying a pizza. One does not ship a pizza, right? It's just weird. Like, we deliver pizzas. And so it's a very minor feature that allows you to actually specify shipping, delivery, or pickup as like the address type. So we still call it shipping address, underlining the system. But this way in the UI, a user would see, I want my pizza delivered to 345 Spear Street. I don't want it delivered. Or if you're a ride sharing service, for example, you can say pickup and it's your pickup address where you're currently at or located. And so that's the value of that particular little thing. Again, pretty minor, but allows us to just have like a better user experience underlining the whole system. So now we just put it together, basically. And then we get that whole experience that we talked about, or I just showed you. So the first thing we do is we instantiate payment request. And we pass in our method data, things that we support. We pass in the transaction details. Again, how much money, what currency code, what line items do we want. And then our optional options. So in the case of our demo that I went through, that would be request shipping true and request email true. But again, that one's completely optional. You see here, I've also added an event listener to my shipping address change. And we support two events in the system, shipping address change and shipping option change. This is that dynamic mechanism that allows you to receive the events, parse out the new details, let's say, so if a user selects a shipping address, that event fires, you can actually pull out that full shipping address. We don't do just the zip code because you can't get fully accurate shipping information with just a zip code. So you get a full user address. You can use that at that time to call event.updatewith. This basically says, hey, browser, I'm thinking, I need to calculate this. You can call your back in APIs and you can update, resolve a promise with new transaction details. So again, that updated transaction details object can now contain your updated set of shipping options, including the empty set of options and an error which says, sorry, we don't ship to wherever it is that you're trying to ship to. So that's also supported. And by instantiating payment requests, there's no UI that shows. It's just instantiation. When you want that actual payment sheet to slide up from the bottom, we call .show. .show is actually our signal and we actually raise that payment sheet and put the user through the process. That returns back a promise, and when that promise resolves, you have a payment response. And that payment response contains the entire set of data. It's just a JSON object that contains the entire set of data that you requested. So for a credit card, for example, you would know what the underlying network was, so visa, master card, et cetera. And then you would see credit card number, full number, full CVC, expiration, et cetera. Think like the same set of data that a user would have typed out into your form, you're now getting just from the browser as a JSON response. You can then use that to basically send that response directly off to your gateway, your server, or even let's say in the case of Striper APIs directly over to the APIs for tokenization. It's completely up to you because it's all plain text. These responses, it's important to note, are method specific. So if you selected Android Pay as your form of payment, then when that response comes back, it's going to look like an Android Pay response. You're going to be able to select this, there's a key, and they'll tell you that, oh, the form of payment they chose was Android Pay. And then you'll have to expect that the Android Pay details object looks different than a credit card one, which may look different than some other form of payment like an AliPay, et cetera. And that's because different payment methods have different requirements and are different systems and call things different things. The final step here is we just need you to tell us to close the UI because once you get this payment response back, we actually chose a little loading spinner. And that little loading spinner is sort of waiting for you to come back and let us know the result of the transaction. We highly encourage but do not require that at the time that payment response comes back, you try to make the payment. There are legitimate use cases where you can't do this, things like 3DS flows, et cetera, but by and large, if you can submit, we recommend it. And so you call the complete, you can call it with success or failure, but you can also call it with nothing. This is basically an affordance for the browser to do special UI considerations in the events of success, like a little animated check mark or something. But again, it's totally optional. But the important thing is that when the UI closes, we'll actually resolve that promise. And that promise is your queue that the UI has been completely torn down. So if you have animations or things that you're trying to time with the close of that, wait for that promise to resolve, and then you can be guaranteed that any Chrome UI has now been stripped from the page. And that's it. Armed with that, you basically have the whole experience. So in just a few lines of code, you basically get help user alleviate all that friction and difficulty of typing all those annoying form fields. Pretty simple, but also again, with Android Pay and other future forms of tokenized payment, you're basically getting easy, great tokenized forms of payment that reduce like the burden of CVC, memorization, et cetera. So really excited about this. And this is all possible because the browser is sort of sitting as the middle man there, proxying data back and forth between native apps on the device and the underlying website and the developer that's requesting it. So my last few minutes here, I want to talk about just a few UX considerations and forward looking stuff. So first one is my very bold hyperbolic statement to say, kill the cart, which is maybe a bit strong. But it's sort of my way of saying if a user is coming to your site or if a lot of users who come to your site on mobile that only make a single purchase, why put them through the burden of opening the page, adding it to the cart, finding the cart page, clicking the cart page, going to the review page, go to the checkout page, and then finally starting the process. They're on mobile. We want to optimize their experiences. Payment request allows you to do that quickly and immediately. So consider adding like buy now buttons directly to your product pages, especially on mobile when it makes sense. Again, this moment won't make sense for all businesses. But I would encourage you to go back and check the numbers and see if this might be a powerful tool for you guys to leverage to help your users. Just a few other things really quickly that I've talked about and you've heard mentioned here today is think progressive enhancement. This is a new API. It won't always be available. So you can't necessarily completely depend on it, especially in a cross browser way yet, although hopefully we'll get there. So think what happens if it's not available. You'll still need fallback flows, et cetera. Second one, of course, is we encourage you to keep the set of list items high level. So don't think of it like an itemized receipt. We don't want the user to say this long scrolling list in the UI if possible. Try to keep it high level, subtotal, tax, things like that. If it's single item, you can put it in there. But by and large, we encourage high level subtotals and things like that. And then last one, something to consider is that if you already have a user's information and you already have a credit card on file or some way to pay, I wouldn't expect you to use, don't think you have to use payment requests. Like give the user the best experience they can. And that means go ahead and just leveraging what you already have on file. But if you don't have anything and you don't have the credit card or the credit cards expired and you need a new one, consider payment requests as a tool to help these users. We talked about sign up first, right? But that might not always make sense for your business. If you think about it, like maybe your P0, your most important thing is getting a user through that checkout flow. Then you can request an email address from payment requests. And now all you need from them at the end of that funnel to sort of optimize the experience for next time is a password. And so consider sort of leveraging this. Again, these are tools to help you be successful. So just a quick status update. So we are live in Chrome as of M53. So we've only been live for about eight weeks now. And it's sort of a quiet launch. We had a great set of early launch partners that we worked very closely with. And they integrated and tested and gave us a lot of great feedback. Again, the API is still early. Chrome is the first browser to implement. And so we're really thankful to all of these players for their great feedback. And from it, we're actually making a lot of changes and improvements and enhancements to the underlying experience. And so I just want to talk a little bit about what you can expect to come soon. So the first one that we're working really hard on is support for third-party payment apps.  In India, you know, you have like Paytm and Snapdeal and all these other new emerging wallets. If you go to Holland, you have Ideal. If you go into other countries, a whole new forms of payment that are not just credit cards and Android Pay. And we want to be able to support all of this in a nice open way where we can support users from all over the globe no matter what. And so we're really close to finalizing this. And we hope to have support next year. Secondly, we have a lot of spec and feature enhancements coming. So we have the shipping address types I talked about.   So we added OCR scanning just recently, so you can now just like scan. If you don't have a credit card, you can just scan it directly into the UI. So there's things to make it faster, easier, and fundamentally better onboarding flows. And then just quick timelines here, just so you're aware. We're sort of targeting M56, that's our January release, as like our next big major release. It's going to have all these enhancements, all these improvements, and we're really excited about it. You'll continue to get updates along the way. This is all live in Chrome stable, and we'd love to continue to work with you and get your feedback. Everything I talked about today is available online in a lot more detail. We have integration guides, a bunch of examples in sample code. Ooh, the phones come up. And then we also have a gain start with Android Pay. Android Pay is really simple with payment requests. It's like less than 10 lines. We do almost all the heavy lifting for you. So just a quick shout out there. But I'll be around for the rest of the day. I would love to chat with you, learn about your challenges, things that you think you need from the browser, ways that we can help you be successful, especially in checkouts. So thank you so much. Talk more.


I'm Robert Lam, president of the American College of Dentist Foundation, Regency 3 of the college, as Dr. Bob Plage, who is the region of Regency 3, for a tutorial on the nomination process for fellowship, and he will assist in this production. Susan Pittman, our operations manager for the college, will also assist in this tutorial. The nomination process for the college is confidential and therefore seems somewhat mysterious, and we will try to demystify it. Whether you became a fellow in Orlando or become a fellow or been a fellow for many years, one of your obligations is to identify worthy candidates for fellowship. We will discuss the nomination selection process, the profile summary and nominator statement forms, and give you an idea of where to search for worthy candidates. Hopefully this will make your nominations more successful. The nomination and selection process as I mentioned before, this is confidential. The nominee should not be told. There's a nominator and a seconder. The nominator is the one who writes the main statement, and the secondator just affirms that he knows the nominee and is a fellow in good standing. Normally I will ask the candidate for a CV, and then I'll use that to fill out the profile summary and the nominator statement, which we'll discuss shortly. After the packet is submitted to the National Office, the credentials committee will get this and get the packet, and they will send postcards to the local consultants, five or six fellows in the zip code of the nominee for further evaluation. You're not limited to nominations in just your section. You can nominate anywhere in the United States or in the world, and you can nominate any time of the year. Nominations are due January 15th, 2024 for this year, and after that date, those nominations will be held for 2025, but you could have started in January of 2023 and started writing your nominations. Once the packet is submitted to the credentials committee, the nominator and seconder's names are removed for blind evaluation, so the candidate is, or the nominee, is evaluated solely on their accomplishments and their achievements to the dental profession and leadership, and not because they know me or Dr. Plage or some other fellow. Who should you nominate and where are good places to look for nominees? You can look at the state board of dental examiners. You can you can get on the acd.org website under members and you can search to see if somebody is a fellow or not, but the state board has many qualified people for fellowship. The ADA 10 under 10 program where they evaluate and award dentists who have been under 10 years of practice for their accomplishments. The AGD 10 dentists to watch and the National Dental Association 40 under 40 or other valuable resources for nominees. Officers and leaders in our sister organizations like PFA and ICD are also excellent areas for resources. Bob, I think you'll take over at this point. Yeah. Thank you, Robert. Also, your ADA districts. I'm on the sick was on the 16th district for about 20 years and they're just filled with leaders. All of them are all 16 district ADA districts. So that's a good resource as well. Your state association has many committees and those chairs and vice chairs of those committees are also potential candidates. A lot of our sections are fairly large. The third Regency is I'd say medium sized, but our first district, our first Regency is super large. Second Regency is large. You might consider a group of people to have a zoom call from different parts of that section and assign nominators and seconders. And some sections also are encouraged to maybe construct a committee for your nominations as well. So just check with your dental society to get some of these other lists I mentioned. In 2018, in response to feedback from our fellows, the nomination packet was separated into two parts. The profile summary, which norms information normally found on the CV or resume and was de identified. So as a potential nominee might complete the form themselves and return it to the nominator or a nominator could request a CV and copy and paste from the CV into the profile summary. The profile summary states the qualifications of a nominee. Now these are pretty much just single sentences and statements of their resume versus the nomination form, which we'll talk about in detail as well. Anyway, so let's get to the profile summary. First, get a copy of it. You can't submit it as it is. It's got to be changed. It's got to be put on our PDF, you know, from the American College, but I still use it as best I can to put into that CV, into that profile summary. Now, if I put stuff in there and I really don't know something about what the candidate does, like I have questions about what this means, then I'm going to call them and see how it impacted an organization that they were dealing with. So you want to clear up any of those questions so that you have a clear and concise message when you write your nomination statements. So you might say, well, that's kind of odd me calling asking about it. Well, it really isn't. They know you're up to something, but you don't ever tell them what it is. So just be a little bit coy about it. Give them a call. I had one candidate this year who I knew the father, and I asked the father who's a dentist for the CV got it. But I needed more material. I felt like, gosh, this isn't enough right here. I've written several of these up and there needs to be more material. Well, this dentist's mother had more of the information. So I called her and knew her quite well. So you never know what your resource might be. Even some of their friends that might have worked on a committee might know more about them. That might also be in the American College. So just use your your noggin and call different people to try to clear up anything on their their CV. Robert. OK, thanks for the profile summary. Evaluation, the nomination statement and discusses the impact the nominee has made in his culture. And both on the profile summary and the nomination statement try to you need to put something in every slot. So I will take a CV and I'll figure out what I'm going to put where and where to expand on it so I don't put everything in one slot and then leave three other areas void. And I write my statements as I think that the credentials committee has no idea of what I'm talking about. So instead of just saying the patient has worked. I mean, the candidate has worked in their mom. I will say the candidate has volunteered for X number of years in a mom program, which is a two day brief clinic offered by the Y dental association where 900 patients were treated and so many dollars of services were provided during that time. So it shows the impact of what they were doing or if they had served as a lead, I say they served as a lead and restorative or endo. Or triage and don't have the candidate write their own nomination statement. The credentials committee does not like this written in the first person like I have participated in three moms. I am chair of this. They know that the nomin the candidate is then has written their their nomination statement. The nominator support statements allow the nominator to explain how the qualifications listed on the profile summary have added value to the profession and society and will add value to the college. So in review. Here is the difference between the profile summary and the nominator statement. Bob, I think you are going to do this. Thank you, Robert. So just these key points. You've got leadership positions in the profile summary. So you list them. They are lists. Those organizations are position positions held in organized industry, industry community research, academia, military, et cetera, et cetera, and then add the significant dates alongside of it. If you feel they are necessary. They usually are. I usually put the dates. That they were chairs or vice chairs and things like that. And their key contributions list the significant volunteer community service contributions and accomplishments. Those dates should be shared if you feel they are necessary. Again, I kind of think they are necessary in many cases. Versus the nominators support statement. Which they are statements and they're, we're going to go over those in both of these in a little more detail, but they're not just one sentence. A lot of times they are paragraphs. So, and there are different support statements, which we'll get into here soon. So just remember that the statements will go through leadership experience. You'll describe the value of that. They'll go into service. And you'll describe the commitment and the value of that. And there'll be more than just those couple of. Areas of service. And you'll describe the commitment and value of that. And there'll be more than just those couple of. Areas of statements that you do, but I like to make paragraphs out of them. And again, what Robert said is make sure you fill out all the boxes. There's additional ones. I'll save something for that box. I'm not going to leave anything empty. So, and then I think we're going to go into those forms a little bit. Is that correct, Susan? Yes. I wanted to just talk a little bit about. Something really important that Dr. Lam said, and that is before we send the nomination packets to the credentials committee, they are de identified. So it truly is a merit based evaluation by the credentials committee. And the different, what you all have been talking about is the difference between the profile and the nominator support statement. So the profile summary goes on the top. And followed by the nominator support statement. So it reads the credentials committee sees the list of things, and then they really get into the meat of it. So it's a really nice presentation that's made to the credentials committee. One of the pitfalls of our online system is that you cannot save a form and come back to it later. So there are a couple of ways to handle this. One is to write down everything you want to say. From the CV for the profile statement and everything you'd like to say on the nominator statement. Save it in a Word document and then you can copy and paste from your Word document into the online form. And that works really well for some of our fellows. That's actually something that a successful nominator shared with us, how they handle it. The other thing you can do is contact Stephen here in our office, Stephen Frohlish. And you can email him at Stephen with a PH, S-T-E-P-H-E-N at ACD.org. He will send you a fillable PDF form, one for the profile and one for the nominator statement. Once you save those forms onto your desktop, you can fill them out, save them, and email them back to Stephen. One of the things that I just want to kind of beat this horse a little bit more dead, as we say in Texas, it is really important on the nominator statement that you talk about the value that they have brought to the profession. So often I've sat through the Credentials Committee nine times. This will be my 10th time sitting through a Credentials Committee meeting this spring. And the thing I hear come out of, come from them the most when they read a nomination is, so what? That the nominator statement is just a restating of the CV, that there's no, there's a listing of committees and organizations for which this person has given service, but new details, nothing about leadership. So it's really important to go into those details and talk about them as if no one knows who this person is. Your nominee may be the greatest dentist ever on the planet, they may lead every organization and you may feel that everyone knows who this person is, but really in the nomination process, those five people on the Credentials Committee are the ones that have to know who they are. So even if everyone else knows them, if the Credentials Committee does not, that makes it really hard for them to interpret the nomination. So please be very specific in those nominators support statement forms. And I think we have some examples, Dr. Lam, are you going to go through some of these examples? Yes, I can. And I think we're going to put the profile summary form up now, Susan. Yep, let me stop the share here and I'll put the form up. And one thing about the Credentials Committee, the Credentials Committee is made up of five individuals and I do not know who they are. I've been on the board since 2013 and I have no idea who the Credentials Committee is. They are Susan knows and Steven know, but they are sworn to secrecy. So we cannot call the Credentials Committee and say, hey, you know, even though my name stripped off, I've got this great candidate, this great nominee that is really needs to come in. So I cannot put any pressure on the Credentials Committee. And that again, keeps us an arms distance from the Credentials Committee and makes it very important. So it is all merit based and no outdoor outside influence. And I'm sure they're very accomplished themselves. For sure. And maybe, you know, they can really read these different nominations and kind of figure out who the movers and shakers are. So write it like they don't know anything about your candidate. In the professional biographical summary page, it starts off with all the demographics. And it asks for the ADA membership number if applicable. The board a couple years ago made the decision that although we feel ADA membership is very important, it is not required at this point for fellowship. The board recognizes that there are many individuals in dentistry and our sister organizations who may not belong to ADA, but are very interested in the same things as far as excellence, ethics, professionalism, and leadership that those of us in the college are. But we encourage the candidates to be part of at least one organization. We feel they should be a part of organized dentistry again, although that's not required. We asked many statements about prior organizations they've been in. We get to the part about education, where they undergraduate, dental school, work experience, and then we get into a professional and community experience or get into the key leadership positions. And one of my nominees, I might put in the profile summary that he is a member of the city planning and zoning committee, where in the nominator statement, I will put he is a member of the city planning and zoning committee, which approves housing and developments in his hometown. So just to expand on a little bit, under key service, Bob, you had a nominee that had a vegetable garden. Right. She is a public health dentist in our state. And she treats a lot of poor people. She listed a vegetable garden. And I'm going, OK, what's that all about? I need to find out. So I did call her and got the details. She grows food a couple of acres. She dedicates the grown food for some of her patients, the poorest ones. But I didn't know enough about it with it just being listed. So you have to call them and kind of find out the details. And that's, I don't know if that's a first or not, but that's a significant thing to put into the nomination statement. Thank you, Robert. I had a nominee who was a church deacon for 19 years, which I've listed that in the profile summary. But then I, in the nominator statement, I put he was chair of the deacon body for two terms, shared the church finance and personnel committee and served on a committee to select a new minister. So this again, just telling about that he's a church deacon for 19 years in profile summary, and then expanding what he, what that dentist did in his nominator statement. And then key awards and accolades and publications. And in an award, you might, you might, in the profile summary, just, just write the award they got, but in the, in the nominator statement, explain the award, the significance of the award, how they were selected, and from how many were they selected. And I had a nominee who was very active in the Boy Scouts. And he had been rewarded, awarded the Virgil award in the Boy Scouts or the arrow. And only 2% of those in the order of the arrow become vigil. So that is quite an accomplishment, which just said, he obtained a vigil award in the Boy Scouts. The nominating committee, excuse me, the credentials committee may not have any idea what, what the significance of that was. Susan, at the bottom of the profile summary, he talks about them, the information, if it's a different person from somebody completing the forms, explain that a little bit. We did that when, when we got, when we responded to an extraordinary amount of feedback about the, so the nomination forms used to be all one form. And when we extracted just the basic profile summary form based on feedback from our fellows, it was they wanted to give at least part of the nomination to the nominee to fill out themselves. This is to be quite frank, somewhat controversial. Some people do not like that at all. Some people are very happy to have that option. So the opinions about this over the last few years have come up or kind of all over the map. But if you are someone who is comfortable doing that, we ask that this, this is a way for the nominator to tell us that the nominee filled this out themselves. So we want to know that the person who requested this information, we want to know, we just want to know that if the nominee did it themselves. So that's why we ask that question. Thank you. Thank you for explaining that. Absolutely. Now we can move on to the nominator statement. We'll go through this form fairly quickly, because I think we kind of discussed the difference between the profile summary and the nominator statement, but this will just give you an idea of what it looks like if you have never filled out one of these before. And Dr. Lam, just to point out to everyone, these are the PDF forms. These are not the online forms. To access the online form, you go to acd.org and hit the members button at the top right and log in. And then you can get there from there. You can also go to acd.org slash nominations and get to it a little bit more quickly if you're using online form. And if you have any questions logging on, they just contact the national office and you all can help set up passwords or help get them in if they have any questions. They can contact us at office at acd.org or<PHONE_NUMBER>. Great. Thank you. And then this form shows the next year we'll be in New Orleans, October 16th and 17th of 2024. And then the year after the convocation will be in Washington, D.C. And then on the nominator statement, it starts out again with the nominee's name and this the demographics of the nominator and the seconder. And then there are support statements and just, again, their leadership experience. And so you've listed in the profile summary expanded it here. They're service statements and describe their level of commitment and the value that their service is and their impact on their community. And then the support statement for the awards. And then there's other relevant support information. If they entered the military after dental school, you can discuss their career in the military. I had a person who was out of the military but they continued to train OMS residents. My nominee that had been active in the Boy Scouts, he had completed Wood Badge, which is adult training program in the Boy Scouts. And he continues to teach in the Wood Badge program.  Susan, I think you're going to discuss some guidelines used by the credentials committee. Yes, and I, you know, I don't know. Okay, so here, these are some resources we'll talk about in a minute, but guidelines that the credentials committee are given include things like looking for dentists who are newer in their career. They should look for a clear trajectory. So maybe this person has not been president of their state dental association just yet, but maybe they are chair of the new dentist committee and they're headed in the direction of becoming the president of their state dental association. So it's looking for potential for leadership development at earlier career stages. And then accomplishments and especially contributions to the profession and society for dentists who are further in their careers. They're looking for awards. They're looking for diplomat status. They are looking for active and engaged and very involved in dentistry and in their communities. They also will ask, do you, they'll ask one another, do you all see leadership here? So that comes up over and over again in these conversations with the credentials committee. Stephen and I do attend that meeting and we take care of the administrative work and, you know, make sure Vice Fed and everybody has what they need to do their job. But it's interesting to listen to that conversation and it's different every year, but leadership comes up every single time. Civic and community involvement is very important. Academic affiliated nominees, they are looking for publication in peer reviewed journals. They are looking for involvement in research. They are looking for things that are not part of the normal job of someone in academia. Are they going above and beyond in research and adding to the scholarly body of work in dentistry? And also evidence of presentations at professional meetings. They are looking at, one of the things they look at for everybody regarding presentations are, are they at non-commercial workshops? Are they presenting a workshop on behalf of a corporation? Or are they presenting a workshop for an organization? Are they presenting for the NDA? Are they presenting for the ADA? Or are they presenting for a corporation? And they're also looking for consistency and balance. Is it only, is all of the work inward facing? Is it only for the profession? Or are they engaged with the wider community? A couple of things to note too. When the credentials committee, and Dr. Lam touched on this at the beginning, when the credentials committee approves the nominees, they go to the board of regents for final review and approval. We notify the nominators first, because some nominators like to be the ones who tell their nominees, not all of them, but some do. We give them that opportunity. And then if they're not selected, we don't carry them over. They have to be renominated. I think Dr. Lam, you might talk about that a little bit. Did I touch on everything? Are there any questions? Good job. One thing that I use that word trajectory for somebody young, because it's kind of like right out of the handbook, because they don't have that much information on them yet. But if you see their path is going up and up, I want them in there. I want to boast about them. I want to tell the committee that they have that kind of trajectory or potential to become a real leader in dentistry as they go forth. So that's important, a real important point to me. It is. It's actually in, I was just reading from the guidelines that we give to the credentials committee, and that is the word that's used in their guidelines. And of course, like any rubric, we're happy to share this. If you contact me, Susan, S-U-Z-A-N at ACD.org, I'm happy to share those guidelines. Right. I always like to allow my nominee to get the letter. And then after I figure out, sometimes I call Susan and say, when did the letters go out? When do you expect to get them? Because I like to have them have the excitement of opening that letter because they have not been told what they're, hopefully they have not been told what they're being nominated for. It is a confidential nomination because although 90 to 92% are selected, there are some that are not. And that puts the nominator and the candidate in a very awkward situation. And normally it's because, not because the candidate is not worthy, it's just not a strong application or nomination packet. And so that's why we are trying to help strengthen these packets. For those military candidates, again, you might look at leadership roles if they're a base dental surgeon or a system-based dental surgeon, which is basically a commander or vice commander of a clinic, a command dental surgeon, whether they're over a command of many dental clinics that a dental officer may be consulting in certain areas, such as forensics or oral pathology. And again, look at different civic or community activities. One of my nominees was a military officer and he was very talented musically and he went to nursing homes with a group and they sang in nursing homes. And so that was one of the things that I thought was very unique about his nomination. If the candidate is selected, they have the year they're selected and the following year, in order to attend the convocation, we know that sometimes they can't make it the first year and may have to delay the second year. And under extreme circumstances like if they're having a baby, if they're military and deployed or they've had a death in their immediate family, we can make some exceptions, but just contact the national office. As we've talked about resources, your nominator can help you write your first nomination. He was successful, he or she were, that nominator was successful in your nomination so they know how to do it and should be able to help you nominate some of your peers because especially the new fellows, you'll know people more than your generation. As I sit on the Oklahoma committee as we're evaluating nominees, I just search for names and I may not know the names and I suggest them and let our more recent fellows comment about yes, they're ready, no, they're not quite ready, they need a little more time. Your section chair should be able to help you. Some sections or regents sees have a nomination committee to help write nominations. Your regent, the national officers will be glad to help out. And another place as Dr. Plades had talked about as far as looking at your state society, you can contact the person in your state society that handles recent awards and you might look at the young dentist of the year or different awards, a legislative award or a citizenship award or a distinguished, hopefully somebody's received a distinguished dental service award and is already a fellow, but it's amazing sometimes you look at people and think they should be fellows already and go, gosh, they've been overlooked for too many years. And again, the national office either Stephen or Susan can help with nominees and the nomination process. We hope this has been helpful to you. If you want to contact information, our lamb okay at aol.com or our pledge dds at gmail.com or office at acd.org. Susan or Bob, do you have anything else to add? I think you've covered, you both have covered it all. I think we wish you the best of luck in putting your nominations together and hopefully these points will help you do it. Getting some advice from whoever nominated you or someone else that has written several of these can be really beneficial as well. Well, thanks, Dr. Lam and Dr. Plage. This has been really helpful and we'll get this sent out to our fellows. Thank you.