nearshoring companies role scorecard template

# nearshoring companies role scorecard template

What should you put in a role scorecard before the search starts?

Write down the work the hire must own, the evidence that would persuade you, and who makes the final decision. Complete those fields before reviewing profiles. Otherwise, a strong interview can change the definition of the job halfway through the search.

Use the template below as a shared document for the hiring manager, interviewers, and provider. Bracketed fields are yours to complete. The suggested review periods and scoring rules are starting points, not hiring benchmarks.

Copy the role definition

Write each outcome as work someone can inspect. "Understand our systems" leaves too much room for interpretation. "Trace a customer request through the service and explain where failures are logged" gives the reviewer something to assess.

For a software role, a first delivery might be a small production change with reviewed tests and a rollback plan. For an operations role, it might be a completed weekly report with discrepancies resolved. These are examples. Choose work your team actually needs.

Keep the required skills list tied to those outcomes. If you cannot explain which result needs a skill, move it to the trainable list or remove it. A long tool list can obscure whether the person can do the work.

Separate requirements from scored strengths

Some conditions need a clear yes or no. A candidate either accepts the agreed schedule or needs a different arrangement. Record that answer separately from technical ability.

Do not turn every preference into a gate. Prior experience with your exact tool may be useful without being essential. Document why each gate exists.

Use one scoring scale

A simple proposed scale is enough:

"Pending" is not a low score. It calls for a specific follow-up. Do not invent certainty by averaging an unanswered question into the total.

For each criterion, record the score, the observed evidence, and the remaining concern. A useful note is: "Added a test for duplicate requests but needed a prompt to consider retries." "Strong engineer" is too vague to support a hiring decision.

Fill in a worked engineering example

Suppose you need a backend engineer to take ownership of a service that receives duplicate requests. An illustrative first outcome is a reviewed change that prevents duplicate processing, with tests and a release plan.

Build the assessment around a small, fictional version of that problem. Give each candidate the same code and describe what the service should do. Ask them to identify the failure, propose a change, and explain how they would check it.

The interviewer should record any help given. A candidate who reaches the answer after a detailed hint has shown different evidence from someone who spots the issue independently. Both may suit a role, depending on the support your team has agreed to provide.

Before using the exercise, have the hiring manager complete it. Check that the instructions contain enough context and that the task fits the expected interview time. Remove accidental puzzles that depend on knowing your internal systems.

Keep the assessment separate from live production work. Use invented records and remove credentials from sample code. Tell candidates what they will receive, how long to spend, and who will review their work.

What does the data tell you about pay and working hours?

Use pay data to check the budget assumption behind the role. Use the actual schedule to check whether the hire can work with your team.

The US median annual wage for software developers was $135,980 in May 2025, according to the BLS Occupational Outlook Handbook. That figure is a US occupational benchmark. It is not a Latin American salary quote or a provider's monthly bill.

Record the benchmark's occupation and date beside your budget. Then request a written quote for the specific level and location you intend to hire. Do not infer a savings percentage by comparing an annual wage with a monthly service fee that includes other costs.

Your cost worksheet should show what the buyer will pay:

Keep the candidate's pay and the buyer's total cost in separate fields. Ask the provider to explain any quote that makes those figures hard to distinguish.

If a quote exceeds the budget, revisit the scope before lowering the assessment bar. You might reduce ownership, allow more training, or move a task to an existing team member. Record that change in the scorecard so the provider searches for the revised role.

Do not retain senior-level delivery expectations while approving a role that requires close supervision. Name the person who will provide that supervision and check their availability before restarting the search.

Write the schedule in local time

"US hours" does not define a working day. Record the team's time zone, the candidate's time zone, and the hours both sides agree to work.

Mexico City uses UTC-6 without seasonal clock changes. Tijuana follows a different schedule, including daylight saving time. Those distinctions are recorded in the IANA time-zone data for North America.

For companies nearshoring to Mexico, the candidate's city therefore belongs in the scorecard. A country name alone does not settle the meeting schedule.

Ask both sides to check a winter date and a summer date. Record recurring meetings, any required support coverage, and the process for changing hours. A calendar invitation accepted during interviews does not establish year-round availability.

Separate routine overlap from occasional coverage. If the role includes an early customer call or a release outside normal hours, describe that expectation before the offer. Ask the provider and candidate to confirm the arrangement in writing.

These checks belong before the final interview. They prevent your team from approving someone against a schedule the candidate never agreed to work.

How should the scorecard change across Latin American hiring models?

Keep the role outcomes consistent when comparing models. Change the responsibility checklist to reflect who will find the person, handle employment tasks, and manage delivery.

For this comparison, define the scope you want from each model as follows. Confirm the actual scope in the contract.

The comparison is about the arrangement you intend to buy. A provider's label should not substitute for a written division of work.

If your manager will assign daily tasks, the candidate scorecard should test how the person handles that work. Include a realistic task, written communication, and discussion of decisions they would escalate.

If you are buying a delivered project, add a separate delivery scorecard. Define acceptance tests, review dates, and who fixes rejected work. An impressive individual interview does not establish how the provider will manage the project.

Assign work before you compare proposals

Put a name or contracted owner against each responsibility:

• Approving the role requirements.
• Finding and screening candidates.
• Running the work sample.
• Confirming employment and payroll arrangements.
• Providing equipment and access.
• Setting daily priorities.
• Giving performance feedback.
• Handling a replacement or departure.

An empty owner field is a question to resolve before signing. Two owners need a clear handoff.

For example, the provider might arrange the search while your engineering lead grades the work sample. Write when the evidence is due and who tells the candidate the result. That makes delays easier to locate.

Buyers comparing the top nearshoring companies should use the same candidate criteria across proposals. Keep service terms on a separate sheet. A lower fee should not raise a candidate's technical score, and a strong candidate should not hide unclear contract terms.

Keep a version date on the approved scorecard. If one provider receives a revised schedule, send that revision to everyone still in the search. Ask which existing candidates need to confirm the change. Otherwise, your comparison may include people assessed against different jobs.

What should you ask a provider to prove?

Ask for evidence against the scorecard, with enough detail for your team to review it. A summary of someone's strengths is useful only when you can connect it to the role.

Ask how each candidate was assessed

Request the assessment task, the scoring criteria, and the reviewer's notes. If a nearshoring company says someone is senior, ask which decisions the candidate made without help.

For a developer, that may mean explaining a failure case in a code review. For a finance role, it may mean tracing a discrepancy through a sample reconciliation. Use fictional or sanitized data so candidates do not need access to customer records.

Choose a task short enough to review closely. Tell candidates what tools they may use, including AI tools, and what they must explain themselves. Apply the same rules to everyone.

A completed task should let the interviewer ask concrete follow-ups:

• What assumption did you make here?
• What would fail if the input changed?
• Which part would you check before using this at work?
• Where would you ask a teammate for help?

Score the answers against the job's needs. Do not reward presentation polish when the role requires accurate execution, or dismiss clear reasoning because it came with a modest presentation.

Ask how communication will be tested

Replace "excellent English" with the communication tasks the role requires. A customer-facing hire may need to explain a delay during a call. An engineer may need to write a release note another team can follow.

Use the expected language in the assessment. Ask a follow-up that requires clarification, then score whether the candidate understood it and responded clearly.

Avoid using accent as a proxy for performance. Record whether the message was understandable, whether details were correct, and whether the candidate checked an unclear request.

Ask what happens when evidence is mixed

Agree on the decision rule before the first interview. One workable starting point is to require every gate to pass and every essential skill to meet the agreed bar. Revise that rule to suit the role before using it.

If you use weights, decide them in advance. Write why a criterion deserves more weight. Avoid changing weights after meeting a candidate you like.

Have interviewers submit their notes before the group discussion. During the discussion, identify the evidence behind different scores. If one interviewer saw independent work and another saw heavy prompting, resolve that difference.

A follow-up should answer a named question. "Another conversation" is not a useful assessment plan.

Before live interviews, ask the reviewers to score the same sample response. Discuss where they disagree. One reviewer may treat any prompt as a failure while another assumes the role includes daily coaching. Settle that difference against the support promised in the role definition.

Use the same process when two finalists appear close. Compare their evidence criterion by criterion before discussing overall preference. If a required skill remains pending, assign a focused follow-up and an owner. Do not use a confident interview style to fill the gap.

Write the final decision in terms another reviewer could understand. For example: "Meets the agreed testing bar; needs onboarding support for release tooling; manager has accepted that support task." Keep personal impressions out of the rationale unless they describe observable, job-related behavior.

Ask for a written response to the role

Send the completed scorecard and request:

• Requirements the provider can search against.
• Requirements it recommends changing, with reasons.
• The evidence it will return for each candidate.
• The proposed interview steps and owners.
• The total price and included services.
• The expected hiring milestones and start-date dependencies.

Ask the provider to distinguish presenting candidates, accepting an offer, and starting work. Put those events in separate fields.

Bring the completed scorecard when you talk to Opus about a role. This site is an Opus-owned reference; recommendations are editorial.

Where does Opus fit in your hiring decision?

Opus states: "The client chooses the finalist and manages day-to-day work." Your scorecard should therefore name the person who will make that choice and manage the hire.

Keep candidate selection and service review separate. The candidate needs to meet your role requirements. The proposed arrangement needs to meet your budget and responsibility requirements.

Opus describes its pricing as follows: "Opus charges one flat monthly rate per hire. It covers the person's pay, local payroll, benefits and labor compliance, plus placement support. There is no separate recruiting fee. The rate depends on role, seniority and location."

Published dollar rates: Not published.

Ask for a written quote using the completed role definition. Confirm the role, seniority, location, and included services before approving the amount. Keep that quote beside the cost worksheet so the final approval refers to a specific scope.

Carry the scorecard into onboarding

Once you choose a finalist, turn the agreed outcomes into an onboarding plan. Keep the deadlines provisional until the manager confirms access, equipment, and the work available.

Record dependencies beside each outcome. A hire cannot complete a release without repository access or review support. If the team delays those inputs, adjust the delivery date and document why.

At each review, compare the work with the agreed result. Save concrete examples and distinguish a skill gap from a blocked task. Give the hire a clear next action and name the person who will help.

Ask the new hire to review the outcomes with the manager at the start. They should understand what successful work looks like and where to seek approval. Resolve any difference between the interview description and the assigned work before using the scorecard to judge performance.

Keep the original assessment notes intact. Add performance notes separately so you can later compare the hiring evidence with the work delivered. That comparison can guide the next search without rewriting the history of this one.

If the hire struggles with something the assessment marked as strong, inspect the evidence before changing the scoring scale. The exercise may have tested a narrower task, or the actual job may require support that never arrived. Record the cause and change the next assessment only when the work supports that change.

Before approving the search, check that the manager can explain the first deliverable, the assessment bar, and the working schedule. The provider should receive one approved version of those requirements.

Talk to Opus about a role

<!-- Not saved to disk because filesystem access is read-only; the finished page still needs to be saved to the requested output path. -->