Onboarding and Support Issues in Microsoft Advertising — Feedback and Suggested Fixes

As a (still early-stage) user of Microsoft Advertising, I need to flag several problems I ran into, both during the onboarding flow and while trying to resolve issues, and suggest fixes for them.

When trying to create an account on Microsoft Advertising, you're given only two OAuth options: sign up with Microsoft or with Google.

This is fairly limiting, because in most cases the user will be a company running ads, or an agency managing ads on a client's behalf, and they're initially blocked from signing up with their corporate email ("@owndomain").

https://ui.ads.microsoft.com/campaign/pmaxlitelanding/signup?ccuisrc=4&redirect=pmaxlitesignin

That option only shows up right after, when Microsoft asks for a business email and lets the user change it to their corporate address. However, since the signup was done via OAuth, when switching to a corporate email (which has no login option) the user would need a password. But the email-change flow never asks for one, so the user is still forced to log in via OAuth.

When trying to log in to an existing account, the user again has to use OAuth, but now with three options: Microsoft, Gmail, and Facebook (Facebook wasn't available during signup).

https://ui.ads.microsoft.com/campaign/pmaxlitelanding/signin?ccuisrc=4&redirect=pmaxlitesignin

Obviously this is already a problem on its own for any user, but let me give an example of a very common scenario where this causes real trouble for a company.

Imagine a scenario where the company "Anunciante LLC" asks its employee John to create an advertiser account on Microsoft Advertising to run ads. When John tries to create the account, he can't use Anunciante LLC's own domain email, and has to log in via OAuth, so he uses his personal Gmail or Hotmail address. After creating the account, John is able to add the company's business email, but he's still forced to log in via OAuth, since that's the only method available. From that point on, any employee, or even the company's partners, depend on John's personal email to log in via OAuth to the company's advertiser account.

There are several possible fixes for these inconsistencies:

1. Allow signup using a custom domain email.
2. Keep signup OAuth-only, but when allowing the email change, require the user to set a password. Then, in the login flow for existing accounts, allow login via email and password (not only OAuth).

Another problem I ran into was with the Account Review Form (I no longer have the link to show as an example). This flow kicks in when the advertiser receives a secure file transfer link from support, to download the "Account Review Form.docx," fill it out with the required information, and upload it back through the same link.

However, when the user downloads the file, fills it out, and tries to upload it, they get an error message saying the file couldn't be processed and to try again later.

This error happens because the user downloaded "Account Review Form.docx," filled it in, and uploaded it back, which conflicts with the file already sitting in the transfer window that the support rep provided. Both files have the same name, and the system doesn't allow replacing the existing file, nor does it rename the uploaded file to something like "Account Review Form (1).docx" (which would be a solution). The error message also doesn't explain why it's failing, which can leave the advertiser with no idea what went wrong. They may just assume it's a system outage, since they're left not knowing the cause and therefore unable to fix it.

Among the possible solutions, one was already mentioned: automatically rename the uploaded file by appending "(1)" at the end, the way Windows does with duplicate files. Or, alternatively, simply replace the form provided by the support agent with the one uploaded by the advertiser.

Another problem, also in the review form submission flow, is that in order for the user receiving support to view and download the form from the secure transfer window link, they need to be logged in to the advertiser account tied to that support case.

However, in some cases of account suspension or deactivation, the user can't log in at all, or if they do log in, that session doesn't persist for the transfer window link.

Among the solutions:

1. The secure transfer window link shouldn't require login to view the Microsoft review form. Instead, accessing the link should require a code, provided by support via chat or, preferably, by email. That way, even though the link is public and accessible without login, only the user actually receiving support would be able to view files and upload documents. If more security is needed, 2FA via a code sent to the advertiser's email could be added.
2. Even with a suspended or deactivated account, once the user has logged in, that session should persist unless the user explicitly logs out. That way, when accessing the link tied to their support case, the account stays logged in and the user can view the files in the secure transfer window.

Another problem is the appeal form: one of the questions is "please provide more information so we can investigate your account," but what information should be provided? What does the review team actually need? How is the user supposed to know which information is relevant, when they don't even know the reason for the suspension/deactivation?

For example, if a user gets a message saying their account was suspended because of an inconsistency found in their account data, they'll submit a bunch of information: EIN, D-U-N-S, business address, company name, company email, company phone number, and so on. If they get a message saying the link between address and domain couldn't be verified, they'll submit proof of address and proof of domain. But the suspension and deactivation messages are completely generic, which makes it hard for the advertiser to understand the actual reason and provide the right information. This creates yet another problem, because one of the reasons Microsoft cites for keeping a suspension in place is that the advertiser submitted incorrect information or documents. Of course they did. The advertiser has no way of knowing what to submit, because Microsoft uses one broad, generic list that covers everything from data entry errors to malware and ransomware to selling illegal products. That's extremely broad and inconclusive, which makes it very hard to understand and actually resolve the issue.

It's like being accused of a crime, and when you ask which crime, they send you the entire penal code in response.

Finally, the manual review system needs to actually live up to its name. It's evident that no case receives real human review. No matter which stage the appeal reaches, the reviewer keeps reproducing the automated system's output, responding in a generic, templated way, and the advertiser is still left with no understanding of what's actually happening. There is no genuine review taking place.

I went through the links below, 136 complaints showing an identical pattern, which proves that Microsoft ignores suspension complaints that clearly stem from false positives flagged by its automated fraud-detection system.

There's nothing inherently wrong with relying on an automated system, however flawed. That's the norm today. But if you're going to use a system that's this miscalibrated, the bare minimum should be genuine human review.

https://learn.microsoft.com/en-us/answers/questions/2289717/ https://learn.microsoft.com/en-us/answers/questions/2290269/ https://learn.microsoft.com/en-us/answers/questions/2288988/

I'm not a native English speaker, so I may end up being misunderstood in places, but even as an experienced user in the tech field, I found the onboarding process difficult because of these issues, and I haven't even used the platform in full yet. If I had actually gone through with full usage, I probably would have run into even more problems. All of these were found within just a few minutes of attempted use (I only went through registration and reaching out to support).

I also believe that listening to users is the best way to refine a service, because when we build features and flows for our own products, we can easily miss edge cases that only the end user will ever actually run into.

NOTE: I currently have a suspended Microsoft Advertising account. I've already spoken with several Microsoft representatives, and I have no real hope of reversal, as shown in the links above, there are people who have been trying to get this resolved for over 3 years, some of whom even sent a letter to Satya Nadella, and still have no resolution to this day.As a (still early-stage) user of Microsoft Advertising, I need to flag several problems I ran into, both during the onboarding flow and while trying to resolve issues, and suggest fixes for them.

When trying to create an account on Microsoft Advertising, you're given only two OAuth options: sign up with Microsoft or with Google.

This is fairly limiting, because in most cases the user will be a company running ads, or an agency managing ads on a client's behalf, and they're initially blocked from signing up with their corporate email ("@owndomain").

https://ui.ads.microsoft.com/campaign/pmaxlitelanding/signup?ccuisrc=4&redirect=pmaxlitesignin

That option only shows up right after, when Microsoft asks for a business email and lets the user change it to their corporate address. However, since the signup was done via OAuth, when switching to a corporate email (which has no login option) the user would need a password. But the email-change flow never asks for one, so the user is still forced to log in via OAuth.

When trying to log in to an existing account, the user again has to use OAuth, but now with three options: Microsoft, Gmail, and Facebook (Facebook wasn't available during signup).

https://ui.ads.microsoft.com/campaign/pmaxlitelanding/signin?ccuisrc=4&redirect=pmaxlitesignin

Obviously this is already a problem on its own for any user, but let me give an example of a very common scenario where this causes real trouble for a company.

Imagine a scenario where the company "Anunciante LLC" asks its employee John to create an advertiser account on Microsoft Advertising to run ads. When John tries to create the account, he can't use Anunciante LLC's own domain email, and has to log in via OAuth, so he uses his personal Gmail or Hotmail address. After creating the account, John is able to add the company's business email, but he's still forced to log in via OAuth, since that's the only method available. From that point on, any employee, or even the company's partners, depend on John's personal email to log in via OAuth to the company's advertiser account.

There are several possible fixes for these inconsistencies:

1. Allow signup using a custom domain email.
2. Keep signup OAuth-only, but when allowing the email change, require the user to set a password. Then, in the login flow for existing accounts, allow login via email and password (not only OAuth).

Another problem I ran into was with the Account Review Form (I no longer have the link to show as an example). This flow kicks in when the advertiser receives a secure file transfer link from support, to download the "Account Review Form.docx," fill it out with the required information, and upload it back through the same link.

However, when the user downloads the file, fills it out, and tries to upload it, they get an error message saying the file couldn't be processed and to try again later.

This error happens because the user downloaded "Account Review Form.docx," filled it in, and uploaded it back, which conflicts with the file already sitting in the transfer window that the support rep provided. Both files have the same name, and the system doesn't allow replacing the existing file, nor does it rename the uploaded file to something like "Account Review Form (1).docx" (which would be a solution). The error message also doesn't explain why it's failing, which can leave the advertiser with no idea what went wrong. They may just assume it's a system outage, since they're left not knowing the cause and therefore unable to fix it.

Among the possible solutions, one was already mentioned: automatically rename the uploaded file by appending "(1)" at the end, the way Windows does with duplicate files. Or, alternatively, simply replace the form provided by the support agent with the one uploaded by the advertiser.

Another problem, also in the review form submission flow, is that in order for the user receiving support to view and download the form from the secure transfer window link, they need to be logged in to the advertiser account tied to that support case.

However, in some cases of account suspension or deactivation, the user can't log in at all, or if they do log in, that session doesn't persist for the transfer window link.

Among the solutions:

1. The secure transfer window link shouldn't require login to view the Microsoft review form. Instead, accessing the link should require a code, provided by support via chat or, preferably, by email. That way, even though the link is public and accessible without login, only the user actually receiving support would be able to view files and upload documents. If more security is needed, 2FA via a code sent to the advertiser's email could be added.
2. Even with a suspended or deactivated account, once the user has logged in, that session should persist unless the user explicitly logs out. That way, when accessing the link tied to their support case, the account stays logged in and the user can view the files in the secure transfer window.

Another problem is the appeal form: one of the questions is "please provide more information so we can investigate your account," but what information should be provided? What does the review team actually need? How is the user supposed to know which information is relevant, when they don't even know the reason for the suspension/deactivation?

For example, if a user gets a message saying their account was suspended because of an inconsistency found in their account data, they'll submit a bunch of information: EIN, D-U-N-S, business address, company name, company email, company phone number, and so on. If they get a message saying the link between address and domain couldn't be verified, they'll submit proof of address and proof of domain. But the suspension and deactivation messages are completely generic, which makes it hard for the advertiser to understand the actual reason and provide the right information. This creates yet another problem, because one of the reasons Microsoft cites for keeping a suspension in place is that the advertiser submitted incorrect information or documents. Of course they did. The advertiser has no way of knowing what to submit, because Microsoft uses one broad, generic list that covers everything from data entry errors to malware and ransomware to selling illegal products. That's extremely broad and inconclusive, which makes it very hard to understand and actually resolve the issue.

It's like being accused of a crime, and when you ask which crime, they send you the entire penal code in response.

Finally, the manual review system needs to actually live up to its name. It's evident that no case receives real human review. No matter which stage the appeal reaches, the reviewer keeps reproducing the automated system's output, responding in a generic, templated way, and the advertiser is still left with no understanding of what's actually happening. There is no genuine review taking place.

I went through the links below, 136 complaints showing an identical pattern, which proves that Microsoft ignores suspension complaints that clearly stem from false positives flagged by its automated fraud-detection system.

There's nothing inherently wrong with relying on an automated system, however flawed. That's the norm today. But if you're going to use a system that's this miscalibrated, the bare minimum should be genuine human review.

https://learn.microsoft.com/en-us/answers/questions/2289717/
https://learn.microsoft.com/en-us/answers/questions/2290269/
https://learn.microsoft.com/en-us/answers/questions/2288988/

I'm not a native English speaker, so I may end up being misunderstood in places, but even as an experienced user in the tech field, I found the onboarding process difficult because of these issues, and I haven't even used the platform in full yet. If I had actually gone through with full usage, I probably would have run into even more problems. All of these were found within just a few minutes of attempted use (I only went through registration and reaching out to support).

I also believe that listening to users is the best way to refine a service, because when we build features and flows for our own products, we can easily miss edge cases that only the end user will ever actually run into.

NOTE: I currently have a suspended Microsoft Advertising account. I've already spoken with several Microsoft representatives, and I have no real hope of reversal, as shown in the links above, there are people who have been trying to get this resolved for over 3 years, some of whom even sent a letter to Satya Nadella, and still have no resolution to this day.