Red Ear Media remains open for business. All of our staff are working from home and are accessible by email, text or phone. #STAYHOME

Why We Don’t Do RFPs (And Why You Should Stop, Too)

Rob Gillan

Rob Gillan

What is an RFP?

RFPs (Requests for Proposal) are commonly used in the business world to solicit for proposals when a project is in the beginning phases. In our case, these are mainly for websites or digital advertising plans and campaigns.

A typical RFP process looks like this:

  1. Business outlines specific wants/needs in broad strokes
  2. Total project budget is identified by the business issuing the RFP
  3. Agencies submit multi-page proposals responding to the specifics in the RFP

The above sounds reasonable enough, right? Let’s dive deeper into why we don’t like the process.

For Businesses

An inefficient way to spend time?

First and foremost, both parties spend a lot of time getting very little done. While there isn’t anything wrong with the RFP-issuing business spending time thinking about their project needs, the process isn’t the most efficient use of anyone’s time. The issuing business has to spend valuable time sifting through numerous multi-page documents that are, by and large, going to say very similar things. Why? Because you, the business, have already told everyone what you want to hear. Although not a perfect analogy, most businesses wouldn’t conduct a job interview by offering the maximum salary up front and then asking the candidate to define their own role — the business doing the hiring already understands their own needs. The whole hiring process is a negotiation (and a conversation) based on the business’s specific needs and a candidate’s skill-set and experience. Important projects should be treated similarly! The business’s needs should be identified to candidates by way of engaged conversation. Think about it – conversation and communication always leads to a better understanding between all parties involved.

Secondly, this process doesn’t give the RFP issuing business an opportunity to test the responding company’s knowledge in a meaningful way until much later in the selection process. Although there can be useful information received in a proposal document, much of the time these responses are somewhat generic and are recycled from previous proposal materials. The respondents often spend time writing to the exact bullet points the issuer has laid out. If you’ve already told someone what you want to hear, then you shouldn’t be impressed when they parrot it back to you.

Thirdly (and acknowledging that this isn’t always the case), proposals from large agencies are often put together by head salespeople and/or managing partners. While these people are eager to please, many times they’re only involved in the sales phase and the work gets passed off to junior staff once a contract is signed.

Finally, why tell someone what you’re willing to pay them? Instead, find out what they can do for you and what that is going to cost. Your job is to get firms with the right skill-sets competing for your money, not salivating at how much you’re willing to spend.

While the business team issuing the RFP don’t need to be experts in the project’s domain (after all, it’s why you’re hiring an outside firm), your team likely has a well-honed bullshit meter. Take that collective business experience and interview firms in your area. Give them some sense of the project and see what they suggest – the responses and general plan should make sense to all involved. Fancy slide decks and a list of previous big-name clients can seem impressive, but the most important thing to remember is this: you’re going to be involved in a multi-week, month, or years long project. Quality of relationship and communication is paramount.

For Agencies

Time Is Precious – Use It Wisely

Responding to RFPs — it’s the job contract lottery. We’ve all been there – a business issues an RFP and you spend hours putting together a proposal that you hope gets their attention. However, you’re subject to a couple of unpleasant realities in this process.

  1. You may not get a chance to engage anyone in a real conversation, and
  2. The hiring business may have already chosen another company for the project.

Wait, what? Yep, knowing who you intend to hire before even issuing an RFP happens more than anyone wants to readily admit. A handshake and a promise behind closed doors becomes subject to “our bylaws/policies/etc. require us to put it out to tender.” Both parties involved know this is a mere formality and a foregone conclusion.

Admittedly, there are fewer downsides for the agency drafting the proposal, and this is the way it should be. As agencies, we’re the ones trying to win a customer’s business, so there is a lot of upside here and it’s incumbent upon us to effectively sell our team and our value to the client. However, spending time submitting proposals to RFPs means spending less time on client work. Less time giving your already paying customers the quality of work that they deserve. Less time continuing to hone your skills and stay on top of the ever-changing landscape that is “best practices”.

Rather than spending time writing a long, comprehensive document, work on getting in front of clients and explaining your value to them. A great agency, no matter the size, should be able to convey to a client the benefits of working with them.

A Better Way To Do Business

At Red Ear Media, we focus on sitting down with and engaging with our clients, both current and prospective. We believe that clear, honest, and open communication will help yield relationships that are mutually beneficial for years to come. If you’d like to find out more about what we do and to see if we can help you, please don’t hesitate to reach out to us.

Request a Free Quote

How To Manually Add A Subscriber To A WordPress Database With PHPMyAdmin

Rob Gillan

Rob Gillan

How To Manually Add A Subscriber To A WordPress Database With PHPMyAdmin

I’ve seen many articles detailing how to add an administrative user to the WordPress database using PHPMyAdmin. While this is great (and perhaps the most likely scenario), we recently had a client encounter a situation where they needed to manually inject a Subscriber into the database. While the process is very similar, two important key-value pairs in the wp_usermeta table will need to be entered differently — otherwise your new users will have administrative privileges!

Why would you need manually add subscribers?

Though this may be a niche topic, I think detailing it will help as I couldn’t turn up any Google searches on pages 1 or 2 that had anything other than tutorials on how to add Administrative users.

A company recently came to us after their pre-built WordPress theme had stopped allowing for the creation of new users via the WordPress Dashboard. It turns out the theme they were using had become abandonware (the developers stopped maintaining/updating it) and something in the theme had broken the Add User screen. The rest of the site worked fine so, while waiting to build a new site, they still needed to get new Users entered into the system to avoid lost sales or excessive frustration from their client base.

What do you need to add users to a WordPress database?

You’ll need two things: 1) access to the PHPMyAdmin tool through your hosting provider, and 2) the confidence to learn about how to work directly with your WordPress database. Fair warning: the database is where virtually everything that WordPress considers “important” is stored, so it’s not to be taken lightly. HOWEVER, you’re also not likely to break anything if you simply follow instructions. In fact, you may learn something!

Why does the database matter to WordPress?

Although it may seem like everything lives “on the WordPress site”, in truth practically everything that shows up on your site is actually stored in a database created during the WordPress installation process. WordPress provides a framework of HTML (and PHP, CSS, and JS) to display this data to you and other end users. WordPress queries the database for page content, post content, user information, site settings, and much more, then simply presents that to the end user in the form of a web page. The database is where most of your WordPress site’s important stuff is stored.

Creating a New User

Once you’ve logged in to PHPMyAdmin and opened the database that is listed in your wp-config.php file, you will want to find two tables: wp_users and wp_usermeta. Note that, depending on your host setup, the wp prefix may be different or may have additional prefixes after it, so the main thing to look for are the two tables ending in _users and _usermeta.

User fields

In the _users table, you can look at some existing users to see what is required to manually create a user. We’ll want to add data for:

To do this, look for the “Insert” tab near the top of PHPMyAdmin when in the correct database table. It probably defaults to “Browse”. The Insert tab will give us some handy fields for typing in info to add to the database so that we don’t have to write an actual SQL database query ourselves.

In the Insert screen, you’ll see the field names above and each should have a blank textbox beside it for us to enter data. If there are other fields besides the ones listed above, just ignore them for now. They aren’t (at the time of writing, at least) required to create a new user.

ID is a unique number that identifies each user. I prefer to look at the last user added in the table and simply choose the next number. For example, if the last user in your table has ID of 74, then create your next user using 75.

user_login is used for — you guessed it — the value that people should enter when on the WordPress login screen. This might be an email, or it may be more of a username like ‘jdoe’.

user_pass is the password for the new user and it is very important to use the MD5 function when typing in a password in this field. You can use this function by clicking on the dropdown list under “Functions” and finding MD5 in the list. This will hash (encrypt) the password you enter which is vital because WordPress does not store plain-text passwords – every password stored in the database is hashed using MD5 and, if yours is not, authentication will fail when you or your users try to login. (When you click “Login” on the dashboard login screen, WordPress will be trying to compare a hashed version of what you enter as your password to what’s in the database. If you insert a non-hashed version because you didn’t use the MD5 function then those two values will not be the same and the login will fail).

user_nicename is the nickname for the user.

user_email should be self-explanatory.

user_registered is a date and time that they signed up. If you’d like, use the icon to open the date picker and choose today’s date. Don’t worry about the exact time (which is what the 00:00:00 will represent).

user_status should be set to 0.

display_name is the pretty first name + last name combo, so enter something like “Jane Doe” here (you should insert your users real name here).

User Meta fields

In the _usermeta table, we’ll want to link these meta fields back to our user ID from the _users table, then add some information describing the user and her permission(s).

user_id must match the ID we entered in the _users table.

meta_key must have the string: wp_capabilities (UNLESS your default table prefix has been changed — again, looking at an existing user for their meta_key values will help).

meta_value should be: a:1:{s:10:"subscriber";b:1;}

Next, you can either click Go and then click on the “Insert” tab again, OR you can continue scrolling down and enter a second set of meta values on the same entry screen as the above.

Again, user_id must match the ID from the _users table

meta_key should be wp_user_level (again, assuming the table prefix is set to default otherwise change the prefix accordingly)

meta_value for a basic Subscriber might be: 0 (so that your Subscriber has no additional capabilities) though it’s important to note that these values were deprecated years ago. Only certain legacy plugins or very old installations of WordPress (versions 2.0 and below) will require the wp_user_level value.

Wrapping Up

I’ve added a brief explanation in each section in order to help demystify the process. Hopefully, this will provide you with what you need in order to manually inject a Subscriber user into your WordPress database using PHPMyAdmin.

If you’re having issues with your WordPress website, consider reaching out to us to see if we can help!

Request a Free Quote