Every working day we get requests from our customers that usually end with something like “Waiting for the quote ASAP!” It is fine with us when requests come well formulated, detailed, and illustrated, but what if they are not? Incomplete requests that lack detail and essence are impossible to work with, take too much time and effort, make everyone go through a nagging and tedious “Whaddayamean by ______ (fill in the blank)?” process, and are simply risky.
When there are risks involved, the cost of such project goes up. We waste time, you waste time, and all of us lose money in the process.
What should we do to avoid all of the above and what is your role in the process being the beneficiary of the project?
This is a very important aspect of coming up with a perfect customization request that will save you time, money, and efforts.
Let us start with the fact that we spend an awful lot of time trying to understand certain things. This is primarily because we fail to gasp what you mean when you use incorrect terminology describing certain features.
We do not expect you to be rocket scientists or to know all the lingo of the trade, but still. When classified listings or ads are called ‘banners’, a search results page called “a listing page”, and export is requested when actually import is required, it takes a lot of time and effort to sort everything out.
We are actually ready to spend some extra time to agree upon the terminology with you. And if you are not ready for that and really need to get going, here are a couple of recommendations for you:
Using the correct terminology decreases the total time for formalization up to three times compared to the original time estimate. So, if you need your customization ASAP, this is a huge shortcut you will need to consider.
When it comes to detailed descriptions, our guess is that some people place their requests in hopes of finding a team of psychics who can read their minds being half way across the globe. Either that, or there is some other explanation to such a huge number of laconic assessment requests that we are not aware of.
The truth is we are not mind tellers. W cannot really understand what customers expect to receive when requesting something like “I want a calendar for my iRealty listings” or “Add a messaging system to my iAuto-based website”.
Instead of going deep into explanations, let us use some specific examples:
Initial customer's request was: "Want users to send emails to each other without leaving the iRealty website."
Here is the final version of the fully formalized description for the above requirement:
Feature - Internal Messaging System:
Now, some stats pertaining to this project:
Here is another example that will help us illustrate the need to consider thoroughly the functionality of the website you want implemented as much as you can.
Initial customer's request was:
Please take a look at the formalized description for the above requirement provided below:
Feature - Ability to Leave Comments on Listings for iLister:
The above clearly shows that the more details you include in your feature description the less time will pass before you receive the quote. Describing your feature in a user story form is preferable, though the general idea may also help, if this idea is not too vague.
Pictures and screenshots are very important for successful formalization of requirements, especially when the project requirements include template modifications.
When you place the following request: “Make all green backgrounds of iRealty 1 theme on the website red”, you certainly have a more or less clear understanding of what red color constitutes for you. At the same time, you should be aware that Photoshop has several thousands of shades of red. Which one should we use? However, when you provide an image with the required color there, or the color’s HEX code, we will be certain that we use the color based on your preferences.
Sometimes, when we receive a request to "put the banner image somewhere under the top menu", we put is "somewhere" in that neighborhood based on our understanding. It is not uncommon when we get the feedback saying that "the image should have been reduced in size and put on the right side of the page, not centered as you did…" Therefore, the question is why you are not specifying the banner location more accurately during the formalization stage. As an alternative, a simple mockup drawing of the positions of key interface elements would do the job just as good and would save both your and our time.
In rare cases, we get something like this:
Confused? Disoriented? Totally lost on the first line? So are we. Now, imagine that you are looking at a couple of pages filled with the same kind of gibberish inscriptions, no commas, paragraphs, nor hyphenation.
This request appears to lack the desire to make the project happen and shows that the author is not interested in cooperating with the Customizations Dept. Likewise, the aurhor should not expect a thorough review of such a sloppily prepared request by us.
This is another typical tasking request that you should try to avoid as much as you can. You may think that by providing a link to the function you like on a certain website, you give us the exact explanation on how this thing should work, but it is not quite the case.
What we all see on the website is the output produced by server-side code neither you nor us see, have access to, or understand how it works. A banner displayed on a page can be displayed by simply inserting the image into html code, by a banner add-on displaying this image in this location on this date for this region. It can also be displayed via the AdSense or similar services.
The point is – we see the results, but not the code that produces these results. We can replicate the results by implementing what you need instead of trying to guess how their system works. Working off your description is an honest commitment we are ready to give. We will not pretend we know how this banner works on that website, we will make your banner work the way you want it on your website.
So, if your aim is to receive the quote ASAP, the description should be provided along with the live example.
Let us say you live in the Capitol city of the FarFarAway country. In your city, you have a popular payment system that you would like to integrate into our script. Naturally, you may want to come up with the following request: “Hi, I want our local payment system to be integrated. How much it will cost?”
It may come as a surprise to you, but all payment gateways have certain unique features or unique approaches to API integration. As a result, we cannot give a realistic quote without studying the integration documentation for a particular gateway first.
By including a link to the English version of the API documentation for the gateway, you will save at least one full day of your valuable time on requirement formalization.
Giving a quick cost estimate to you is another challenge. It is very difficult to say how much it will be if we know nothing about the functionality to integrate. Of course, we integrate payment gateways quite regularly. However, because of payment gateways being unique and different in implementation, quotes for some gateways may wind up being three times higher than for others. Therefore, a rough estimate quoted at the beginning is not a reliable figure to base the budget on; you should wait for the actual quote, which brings us to the next point.
This is a real response to our attempts to clarify the requirements of an original request from a potential customer. This request was, "I want messages sent to inbox from contact seller form on my website".
Let us look at why we would need to clarify this requirement in the first place.
There are three likely options to implement the above:
Option 1: All emails sent via ‘Contact Seller’ form should be saved in the database and should be available for seller to read them on the website. No additional functionality.
Option 2: The functionality described in Option 1 + the ability for seller to reply to emails directly on the website, plus notifications and email sorting, forwarding, and deleting capability.
Option 3: The functionality described in Option 2 + the ability to send emails to multiple users, message send filtering by region or other criteria (for ex., users can send messages to people in the same region only), adding the ability to send messages as a membership plan option to be purchased separately.
The cost of Option 1 will be around $200, Option 2, around $500, and Option 3, around $2,000. This means that the rough estimate is between $200 and $2,000, which serves no real purpose in budget estimating. Further, even this range can be wrong if additional functionality is added at the formalization stage.
Therefore, in case we provide this range as an approximate cost, will it do you any good or help you any? We bet it will not. In this case, the only option would be for you and us to work together some more to clarify the scope better and to receive a more accurate ballpark estimate. We are very interested in preparing a quote that is reasonable because we want to have you as our customer, a satisfied customer.
To summarize the above, we can come up with the following considerations that will definitely improve the quality of the quote, reduce the time for the quote assessment, and save you a lot of money. Before sending in your customization request, review it to make sure that:
We are here to help you if you have any problems with formalizing your request. The only thing we would ask you is to please have some patience and work with us on getting the best request to start the most successful project, your project.
Author: Amber Worksforweb Customization Department
WorksForWeb software portfolio:
WorksForWeb software features:
"Works perfect! Thank you. Must to say that you have a good service and support at your company. Good works."
"Customization team is SUPER GREAT to work with."
"...we are very happy with all your work and help, you have been great and we love working with you. We ... express our greatest gratitude for your help."