Samuel Murray Netherlands Local time: 01:41 Member (2006) English to Afrikaans + ...
Feb 9, 2011
G'day everyone
I'm getting a lot of job posts from outsourcers whom (I believe) would have entered rate information under the old job posting system where budget information was more freely allowed. I suspect that the current sequence of first disallowing and then later re-allowing budget information from being entered by job posters in a single job post are confusing to the point that outsourcers do not realise that they *can* enter budget information in some cases. I think the sequence of "first disallow, then allow" should be reversed to "first allow, then disallow", as explained below.
The current system of job posting works as follows, if I understand correctly:
1. The outsourcer writes a job post and specifies various criteria for matching translators, but *excluding* rate information.
2. ProZ.com's system then checks to see if any translators matching the client's criteria allow rates to be mentioned in a jobs post.
3. If *any* of the matching translators (even if only 1) allow rates to be mentioned, then the outsourcer is given the opportunity to amend his job post by adding rate information.
In other words, in a single job post, rate information is first disallowed, but later re-allowed if there are matching translators who allow it.
I suggest that the system of job posting should work like this, instead:
1. The outsourcer writes a job post and specifies various criteria for matching translators, *including* rate information (perhaps the fields for the rate information can be "folded away" until the client clicks a little plus sign to reveal them).
2. ProZ.com's system then checks to see if any translators matching the client's criteria allow rates to be mentioned in a jobs post.
3. If *none* of the matching translators allow rates to be mentioned, then the outsourcer is given a message saying "None of the translators matching your criteria have indicated that rate information is relevant to them when making decisions about jobs or that they would like to see clients' budget information when receiving job post notifications. Therefore, the rate information that you included in your job post will be hidden. Continue? Y/N".
The "client education" effect of the current "disallow budget information" approach to the jobs system will not be diminished by this suggested reversal.
The suggested reversal will cause fewer job posters who have very low rates to forget or not realise that they can in fact (under certain circumstances) mention rates -- thereby saving those of us who want to see rate information but who do not want to respond to very low rates from having to correspond with the client before realising that the client is offering very low rates.
[Edited at 2011-02-09 08:59 GMT]
Subject:
Comment:
The contents of this post will automatically be included in the ticket generated. Please add any additional comments or explanation (optional)
TransAfrique United Kingdom Local time: 00:41 Member (2011) Japanese to English
An interesting proposal
Feb 9, 2011
I agree that I do want to know in advance whether the client is offering ultra-low rates or not. However I thought the current system was the solution to a huge hue and cry over clients posting rates in their job offers. Isn't what you're proposing a return to what we had before?
Subject:
Comment:
The contents of this post will automatically be included in the ticket generated. Please add any additional comments or explanation (optional)
Samuel Murray Netherlands Local time: 01:41 Member (2006) English to Afrikaans + ...
TOPIC STARTER
Not a return, no
Feb 9, 2011
TransAfrique wrote:
However I thought the current system was the solution to a huge hue and cry over clients posting rates in their job offers. Isn't what you're proposing a return to what we had before?
What we had before was:
(a) translators could not specify that they do not wish to see rates, and
(b) even if all matching translators did not want to see rates, the job post still contained rates.
The current system is that:
(a) translators can now specify that they do not want to see rates, and
(b) if all matching translators do *not* want to see rates, the job post will not contain rates.
OR:
(b) if any of the matching translators do want to see rates, they job post *might* contain rates if the outsourcer had realised that he can add the rate information halfway through the job post process.
My proposal does not change the two most important points of the current system.
I simply ask that outsourcers be allowed to add rates in the first step, and that the rate information is then hidden from the job post if there are no matching translators who want to see it.
[Edited at 2011-02-09 12:32 GMT]
Subject:
Comment:
The contents of this post will automatically be included in the ticket generated. Please add any additional comments or explanation (optional)
The job posting form performs the check for budget preferences based on the job details entered in the first page, or step, of a job posting. In step or page two, the poster is either shown the option to enter budget information or informed no service providers meeting those criteria have chosen to see budget information (this second scenario occurs infrequently, see the context below). In this second case the notice is both informative to the job poster and prevents the entrance of info which will not be included with the posted job. Allowing the entrance of this information and then stating it will be hidden may be more confusing.
Some context: 98% of the service providers who have set their preferences with regards to budget information have chosen to see this information. Whether a job poster elects to include the information initially in the job post is another matter, of course, but the form is not "disallowing" then "allowing" this information.
Jared
Subject:
Comment:
The contents of this post will automatically be included in the ticket generated. Please add any additional comments or explanation (optional)
The job posting form performs the check for budget preferences based on the job details entered in the first page, or step, of a job posting. In step or page two, the poster is either shown the option to enter budget information or informed no service providers meeting those criteria have chosen to see budget information (this second scenario occurs infrequently, see the context below). In this second case the notice is both informative to the job poster and prevents the entrance of info which will not be included with the posted job. Allowing the entrance of this information and then stating it will be hidden may be more confusing.
Some context: 98% of the service providers who have set their preferences with regards to budget information have chosen to see this information. Whether a job poster elects to include the information initially in the job post is another matter, of course, but the form is not "disallowing" then "allowing" this information.
So the reason why the form is designed this way is that the outsourcer shouldn't enter rates if no matching translator will see them anyway. Wouldn't you rather simplify the process for everybody and skip this check? The only cost would be that in the rare situation in which no matching translator wants to see the budget, the outsourcer may enter a figure that nobody sees. That's arguably a very small cost.
Subject:
Comment:
The contents of this post will automatically be included in the ticket generated. Please add any additional comments or explanation (optional)
Neil Coffey United Kingdom Local time: 00:41 Member (2009) French to English + ...
Why make that check?
Feb 9, 2011
Jared wrote:
In this second case the notice is both informative to the job poster and prevents the entrance of info which will not be included with the posted job. Allowing the entrance of this information and then stating it will be hidden may be more confusing.
What's the rationale behind that? Just because the information wouldn't be displayed *now* doesn't mean it shouldn't be entered so that it is available if a translator subsequently chooses to see that information (or a new translator signs up).
Subject:
Comment:
The contents of this post will automatically be included in the ticket generated. Please add any additional comments or explanation (optional)
To report site rules violations or get help, contact a site moderator:
memoQ translator pro is the premium product for professionals. It is Kilgray's best-selling tool among freelance translators: you get all the functionality available in memoQ in your local environment plus the ability to work on remote servers.
Save time by automatically extracting terms. 15% off!
SDL MultiTerm Extract 2011 allows you to automatically create candidate term lists from your existing documentation. This removes the manual effort involved with traditional terminology creation, allowing you to rapidly add terms to SDL MultiTerm.
The translation workplace 
