B2B booking portal for hoteliers: access stalls

A revenue manager wants a group rate for a conference in March. The portal's front page talks about trade rates for hotels, with a log in button and an apply button. The apply form asks for a registration number, a tax number, a business email and the number of rooms. The number format is not explained, and the form rejects the first try without saying why. After the second try, the form says the application is under review. There is no status page and no sign of what the rates would be.

• Read the front page. Can a hotel see one rate before it applies?
• Enter a tax number in the format your own country uses. Does the form accept it?
• Use a generic webmail address. Does the form stop you, and say why?
• Submit the application. Does the pending screen say what happens next, and when?
• Do the apply button and the sign up button lead to the same kind of account?

A hotel that does not know what the portal will save it has nothing to weigh against a registration form. A rate card behind a login gives the visitor no reason to finish. The fix is not to publish every rate. It is to show enough of the offer, such as a sample room type, a discount band or a sample booking screen, that a revenue manager can decide whether the effort is worth it. Read the front page and the apply page, and write down any number or example a hotel could see without an account. If the list is empty, the application asks for effort with nothing in return.

Test the front page as a visitor who is not yet approved, before you review the form, since the front page sets what a hotel expects to find there. Look for any sample that shows the price of a trade room, and note whether the page says what the trade rate is compared with. If the only thing visible is the login, a hotel that needs a group rate may never reach the form at all.

Pricing page testing

A registration number or tax number is usually required in a format set by the business's country, and a form that accepts only one format will refuse a correct number that a hotel copied from its own paperwork. The refusal can say only invalid, without naming the field or the expected shape. Check the fields with a number in the format your own country uses, then with the same number written with spaces and punctuation. If the form accepts one and not the other, the fix is to accept both and show a sample.

A check against an outside register is a separate matter. If the form compares the registration number with a public register, the test cannot pass that step, because a visitor cannot connect to an outside register. The report shows the step where the check stopped the visitor. Treat that as a limit of the test, and read the message the visitor sees, which should say what to do next.

A trade application may be reviewed by a person, so the portal says under review and stops. That is a reasonable rule, but a hotel that has just given its tax number needs to know three things: what happens next, roughly when, and where to check. A pending screen that offers only a home button leaves the hotel guessing whether the application arrived at all. Check the screen the moment after submission, then the confirmation email, then the status page if there is one, and compare the three.

The approval itself is a decision your team makes, so the test cannot pass it. Visitors have a working inbox, so the confirmation email arrives and the report shows where the visitor stopped. Read the email that confirms receipt, and check whether it names the next step, a person or team to contact, and whether it comes from a real address rather than a no reply one.

The first run finds whether a hotel stopped at the rate wall, the registration field or the pending screen. A fix changes the sample offer, the format hint or the status message, and a new approval rule or a changed tax format can bring the same stop back. Run a hotel with a generic email and a local number format after each change.