Drake Dragging Support

[Snaggletooth]

I've had Drake for 11 years, and for the first time tonight, they failed to answer the phone promptly and put me in a 4-minute queue. Drake has a reputation for very prompt customer service. I hope this is a glitch and not a preview of things to come. Anyone else have this happen??

[TaxGuyBill]

A 4 minute queue? Not a big deal. It just happened that several people called immediately before you. They can't have an infinite amount of employees just waiting for a phone call.

If you call Intuit (Lacerte or ProSeries), you need to assume at least an hour on hold (and be pleasantly surprised if it is less), then spend at least a half hour talking to a clueless customer service representative.

[Snaggletooth]

No a 4-minute queue is not a big deal (especially considering IRS or states) - but it happened 4-5 times today for the first time in 11 years. Drake prides itself on prompt telephone response time.

Some "customer support" schemes refer you to a website, where all you get is FAQs, or a "community solutions board" where you cannot find a thing relevant to what the issue is. Yes it can get much worse than a 4 minute queue.

[Rapid Robert]

Some "customer support" schemes refer you to a website, where all you get is FAQs, or a "community solutions board" where you cannot find a thing relevant to what the issue is. Yes it can get much worse than a 4 minute queue.

I appreciate that my vendor not only provides phone/chat/email support with humans, but also has FAQs at the web site and a community forum. I have used all of them as appropriate. It's actually great when you can find an answer yourself online during the hours that human-based support is closed.

Best of all is when your software rarely or never requires contacting support in the first place.

[sami]

To Drake Users: This is the year of worst customer service I have experienced being a Drake user for over 10 years. They are closing my open cases without resolving the issues. The latest which I want to alert is that the IRS direct payment on Drake software is not being debiting out balance due from client's account. I have received several calls from my clients that their IRS payment has not been debited out of their account when the return acknowledgment had been more than 11 days. Drake is saying that it is not their problem if IRS does not take out money from the taxpayer account, while the IRS says (after a long hold ) they process all payments within 24 hours even with the delay due to COVID. Drake is refusing to take any responsibility or even bother to look into this issue. Drake is saying that they are not responsible for direct pay, they use third party. Wonder why they have that feature of direct pay on their system. Some of these payments are large amounts over $30K. I can't ask my client to pay twice because what if the first payment goes through. All the payments I paid using IRS direct pay did cleared bank within 24 hours.

If you are a Drake user just be cautious on this. If someone out there have a solution or suggestion, please share it too. Definitely worse service by Drake for 2020 tax year.

[Snaggletooth]

Could be the IRS that is not doing their job. If so, there's nothing Drake can do about it...

[DoubleO]

I have to say that I have found Drake support to be exceptional this year. I had a very odd problem with my software, and they went above and beyond to help find what was causing it.

So far, I have not heard of any clients with the scheduled debit problem, but as others have said, could it be an IRS problem? I've even filed 1040Xs and had the additional amount debited, and the debits processed timely. I'm having a hard time putting the blame on the software. I have many scheduled for 4/15, including mine, so we'll see what that brings.

BTW, I've been with Drake 31 years and stayed with them because of the exceptional support.

[dtlee]

People using Drake blame them for everything. It is not unusual.

They have spoiled us. I have never been told to contact my printer company nor the signature pad vendor. I have had their technical people take me through operating system parameters when diagnosing an issue. They are rather old school and try to support the customer in whatever environment the customer has chosen. The software is quirky and that leads to needing support that might not be necessary with their peers. DoubleO probably knows why you might need to enter a mill (.001) in some places to get a form to print right, but a new user would never guess this (sadly, their newer support staff may also be unaware).

I have joked with some of their support people about "why can't you fix your printing problem for all open tax years" (which was a compatibility issue between a Microsoft update and the printer drivers of several printer vendors) and "why aren't you deducting my IRS payment on time" (totally an issue with the IRS since Drake has absolutely no control over what the IRS does after they get the tax return information). One representative asked me if I was listening in on his calls. I challenged one customer who was haranguing about how Drake had so poorly supported the printer issues caused by Microsoft and he explained that he is a Drake customer (apparently not a customer of Microsoft [must be stolen software] nor the printer company) so he has a right to demand that they address it.

I think Drake could do more to inform customers where the blame actually lies with these types of problems, but that is typically not their style.

Excessive hold times: I was told on one call that I would need to wait over 20 minutes but was answered within 6. A six minute hold time in the height of tax season would be something some customers of other software would be thrilled about. Plus, other than confirming who the caller is, the person answering is generally speaking from their tax and software knowledge as opposed to reading from a script, which for my kind of questions will save me more than the 6 minutes it would take to get past the first level support of most other vendors and I don't need to explain to them what a capital gain is nor things like why I would want to report a gain on a personal use item but not a loss (all of their representatives are trained in both tax issues and software issues and I have spoken with more than a handful of Enrolled Agents there).

In reality, I think this is an indication that Drake is trying to better control their costs. Staffing so that you have overtrained staff sitting around waiting for a call during peak is not a good use of my software dollars (in my opinion). However, I do like being spoiled.

[ATSMAN]

During Tax season I would not consider a 10 to 20 minute hold from any vendor out of the ordinary that I have to complain. When I call my bank or Doctor's office or other service providers I rarely talk to a live person at the get go. It is usually a complicated phone system and then you have to listen to that sleepy music for 10 minutes before a human voice comes on.

No software vendor can control when IRS does the actual ACH debit. The e-file contains the banking data and it is up to the IRS to debit. Last tax season they were like 10 days behind. So far no complaints this tax season from my clients, but then the bulk of them are scheduled for 5/17. So I am expecting some delays.

[sami]

After using Drake for a over a decade and have one complaint is not a big deal. But the point I was trying to make here was to be cautious that the direct payment is not being received by the IRS.
It is not the IRS fault because the person I got on the phone, spent over 40 minutes looking for all the payments and he sounded very experienced and explained me the entire process. While I have no answer to give it to my client in regards to the payment, which ultimately could cause them penalties so my reputation.

I don't mind the hold time if I know I will get good results after being awaiting on phone. The problem is they pick up the phone promptly but not resolve the issue.

[dtlee]

After using Drake for a over a decade and have one complaint is not a big deal. But the point I was trying to make here was to be cautious that the direct payment is not being received by the IRS.
It is not the IRS fault because the person I got on the phone, spent over 40 minutes looking for all the payments and he sounded very experienced and explained me the entire process. While I have no answer to give it to my client in regards to the payment, which ultimately could cause them penalties so my reputation.

I don't mind the hold time if I know I will get good results after being awaiting on phone. The problem is they pick up the phone promptly but not resolve the issue.

There is no way for Drake to send the payment request separately, so it was sent with the original return.

What the support person was doing (and this should be a complaint about their product) was he was inspecting the e-file record that Drake does not allow you to review and he was looking in the record to confirm what the software indicated (that the payment information was transmitted). Most other vendors will tell you, "If the software says it was transmitted, it was transmitted." This representative spent over 40 minutes to verify that what the software indicated was indeed in the e-file record. He went above and beyond so you give him a demerit. I have likewise had them confirm that a payment request had been included in the e-file record.

Like I said in my earlier post, people who use Drake blame them for everything.

Regarding my comment that this should be a complaint about their product:
Most other major vendors provide you with a way to parse the e-file record yourself so you don't have to spend 40 minutes on the phone (perhaps you may spend a couple of hours reading through XML code on your PC, but not on the phone with support). Drake does not allow us access to their e-file record (supposedly for security) but they also capture information in their e-file record that you probably think is none of their business, so I think you would be correct complaining about that. I have done that quite a few times.

Complaining about someone who went as far as to read through the XML code to reassure you that the payment was transmitted just seems wrong.

YMMV

[Rapid Robert]

What the support person was doing (and this should be a complaint about their product) was he was inspecting the e-file record that Drake does not allow you to review and he was looking in the record to confirm what the software indicated (that the payment information was transmitted).

Most other major vendors provide you with a way to parse the e-file record yourself so you don't have to spend 40 minutes on the phone (perhaps you may spend a couple of hours reading through XML code on your PC, but not on the phone with support). Drake does not allow us access to their e-file record (supposedly for security) but they also capture information in their e-file record that you probably think is none of their business,

Thank you for a clear explanation, although I think you are missing a few critical points (following). You are correct about other vendors providing easy access to the actual MeF data that is transmitted to IRS (the "e-file record", which is formatted using industry-standard XML).

I can assure you, it only takes a couple of minutes, not a couple of hours, to skim through the XML e-file record, and it is easy to view using MS Word or even Notepad. In fact, I often do this before I send the return to my transmitter, for the very issue given in this thread (to confirm that an EFW has been properly included, both federal and state -- there are separate XML files for each).

The information in the XML file is what is required for the return to be processed, and also includes some meta-data as a result of the Security Summit (such as the computer & network ID, time spent on the return, and so on). There is no security risk in allowing the ERO to view this data, and it has helped tremendously in the reduction of fraudulently submitted returns, as the fraudsters now have a much harder time submitting bogus returns. It also helps to better understand what the IRS is actually getting, to help set straight the people who think, for example, that 1099-NEC info is included with the return (it isn't).

[dtlee]

Thank you for a clear explanation, although I think you are missing a few critical points (following). You are correct about other vendors providing easy access to the actual MeF data that is transmitted to IRS (the "e-file record", which is formatted using industry-standard XML).

I can assure you, it only takes a couple of minutes, not a couple of hours, to skim through the XML e-file record, and it is easy to view using MS Word or even Notepad. In fact, I often do this before I send the return to my transmitter, for the very issue given in this thread (to confirm that an EFW has been properly included, both federal and state -- there are separate XML files for each).

The information in the XML file is what is required for the return to be processed, and also includes some meta-data as a result of the Security Summit (such as the computer & network ID, time spent on the return, and so on). There is no security risk in allowing the ERO to view this data, and it has helped tremendously in the reduction of fraudulently submitted returns, as the fraudsters now have a much harder time submitting bogus returns. It also helps to better understand what the IRS is actually getting, to help set straight the people who think, for example, that 1099-NEC info is included with the return (it isn't).

Thank you for your thoughts, Robert. While I would need very little time to parse an XML file (assuming I knew what I was looking for), I do not believe it would have been easy for the poster who had no idea what the support person was doing (though I agree that could be a very wrong assumption on my part). The support person in this situation had to locate the file, extract the data and then (probably) look up the values he wanted to locate. I think the call could have taken the 40 minutes described (some of that determining what the caller was trying to find out about).

Drake also grabs the fee the preparer charges for each return. It is not (as far as I know) required by the Security Summit and they refuse to disclose what they do with this information and what other information they may be uploading from our machines.

[Rapid Robert]

Drake also grabs the fee the preparer charges for each return. It is not (as far as I know) required by the Security Summit and they refuse to disclose what they do with this information and what other information they may be uploading from our machines.

I'm not sure how they "grab" the fee but I'm pretty sure it is not sent to the IRS, as the IRS MeF system has no place to store that data. For example, I send my invoices to clients using Quickbooks and almost all of them pay me using Intuit Quickbooks Payments online. While I don't use Drake, how could my vendor or Drake or the IRS for that matter possibly know what the amount was on my Quickbooks-generated invoice, since it has no taxpayer ID associated with it? Even if they did, how would they know whether or not my invoice include other fees or discounts not directly related to the tax return being filed?

Minor note, I wasn't addressing the 40 minutes that the Drake person took to look up something. I was addressing your comment that "perhaps you may spend a couple of hours reading through XML code on your PC". XML, as documented in the Wikipedia link I included in my reply, is designed to be both human-readable and computer-readable. Using Notepad or Word, one can simply search for any particular text they are interested in, such as routing and account numbers.

[dtlee]

They grab the fee from the invoice within the software.