Three sections of the redlined version of the Draft Evaluation Criteria for new Top-Level Domains (TLDs) caught my attention. It seems ICANN wants to ensure it has information to not only evaluate and score responses, but to conduct a post-launch analysis of the program’s success in terms of expanded competition, consumer choice and trust. That additional information means more work by both the applicant and for ICANN. But it’s a good move because pre-launch preparation and thought staves off mishaps and misfortunes later.

The most interesting change of the guidelines, found on page 11 of the red-lined version, requires applicants to document the new TLD’s goals and benefits. ICANN wants to know how the new TLD will improve consumers’ experiences. Applicants must detail operational policies that will minimize social costs and negative consequences on consumers. This forces applicants to test ideas not only with a sample of the proposed target market (the registrants) but also with end-users! This exercise will go a long way to improving the launch, and there are inexpensive survey tools available, if there is an adequate definition of the target market to obtain a reliable list. After all, if the TLD offers no innovation or is simply attracting defensive registrations, after the first renewal period, you will see a steep drop in your domains under management. It’s not enough that you think it’s a great idea. Does the market also embrace it? ICANN is smartly enforcing a savvy business move: vet the value proposition now, not during the launch.

The second intriguing change is on page 22 and 23 of the redlined version: the expanded section on abuse policies and mitigation procedures. To score a “2” the applicant must describe how it will ensure Whois accuracy, ensure proper access to domain functions such as strong authentication, as well as define “malicious or abusive behavior, capture metrics, and establish Service Level Requirements for resolution.” These requirements will likely mean an expanded RRA with additional requirements for registrars, but the abuse policy description, procedures and detailed metrics can be done by the registry. Many back-end operators have established abuse policy procedures. Applicants must understand these policies and their effectiveness and include them in their RFP—even if a back-end operator has not yet been designated.

Finally, on page 40, ICANN expanded the financial statements section, requiring financial projections such as balance sheet, income statement, revenue and cost projections under various scenarios. And ICANN wants to know the underlying assumptions. At the bottom of page 42 it states: “To be eligible for a score of two points, answers must demonstrate a conservative estimate of costs based on actual examples of previous or existing registry operations (emphasis added) with similar approach and projections for growth and costs or equivalent. Attach reference material for such examples.” Which means applicants must benchmark expectations against similar launches in previous rounds.

As I mentioned in my last post, many applicants in the previous TLD round missed financial projections by as much as 80% by year four. Without any concrete “what if” scenarios done prior to launch, the new crop of applicants face the same risks. Your TLD may be unique, and yes, times have changed, but you’ll be introducing your TLD in a more crowded market than before. So if your projections call for a 50% increase in registrations in the first year, you really need to have (and provide to ICANN) justifications for this increase. Which of course brings me back to the point I made earlier: Make sure you vet your expectations with your target market.

These added requirements add work for TLD applicants, but they’ll help ensure a successful application and eventual launch.

(As FYI and for the purpose of full disclosure, I am the CEO of Architelos, and we recently launched the Business Case Builder Tool (BCB), a custom designed Saas application which helps in developing the financial business case for a given TLD.) As a response to these added requirements, we are adding reports within the Architelos Business Case Builder tool to generate many of the requirements such as projections, documenting assumptions, scenarios as well as benchmarks against previous TLD launches. If there are others you would like us to add, please let us know via comments or on our website.