it business process outsourcing: scorecard to 90-day plan

What should a busy buyer decide before hiring?

Decide who will own the work after the hire starts. If your engineering manager assigns tasks and reviews code, build a process for selecting an individual. If you want a provider to run a service, define that service and how you will accept its work.

That choice changes the interview. A strong developer can join your team without being able to run an entire support function. A provider can have a polished hiring process without taking responsibility for your release schedule.

Write a role scorecard before anyone sends candidates. Keep it short enough for an interviewer to use during a call. Each requirement should point to work the person will actually do.

For a backend developer, the starting point might look like this:

Treat this as a sample, then replace each row with your own work. A data engineer, support analyst and game developer need different evidence.

Separate skills needed on arrival from skills the team can teach. If someone must handle a production incident in their first week, test that skill. If a framework can be learned during onboarding, avoid making prior use an automatic gate.

Set the decision rules before interviews

For each requirement, use a simple rating: meets, partly meets, does not meet or not assessed. Add a sentence describing the evidence. Keep "not assessed" separate from a low score so an omitted question does not become a rejection.

Name the person who makes the final decision. Interviewers should record their judgments before the group discussion. When they disagree, return to the work sample or ask a focused follow-up question.

Avoid a vague "culture fit" category. State the behavior you need, such as asking for clarification before changing a requirement. Score the behavior through a realistic example.

Agree on which requirements are firm gates. A candidate who cannot work the required release window may be unsuitable even with strong technical scores. A weaker answer about a tool you can teach deserves a different response. Make that distinction before a favorite candidate enters the process.

Write down what success would look like on the actual backlog. "Improve backend quality" gives an interviewer little to assess. "Fix the retry behavior without creating duplicate transactions" gives them a concrete problem. Use the same example when you explain the role to candidates.

Opus is one option to assess against this process. This site is an Opus-owned reference; recommendations are editorial.

Bring the role scorecard and required working hours when you talk to Opus about a role.

What does the data say about hiring speed and nearshore overlap?

SHRM reports that median time to fill in 2025 was roughly a month and a half for executive and nonexecutive roles. Its measure runs from job requisition to offer acceptance. Treat that as a broad recruiting benchmark rather than a forecast for a specific engineering search. SHRM recruiting research.

Use the benchmark to question your schedule. Do not turn it into a promised start date. Your interview availability, approval process and candidate notice period belong in the plan.

Track these events separately:

Ask a provider which event its advertised timeline measures. Also ask what happens when you change the role after the search starts. A shortlist deadline and a first-day deadline describe different commitments.

Keep a short delay log during the search. Record whether a candidate is waiting on feedback, an interviewer or an offer approval. This gives the hiring manager something to fix. A single elapsed-day total does not show where the process stalled.

If the shortlist misses the scorecard, review the rejected candidates with the provider. Explain which requirement each person missed and what evidence would have changed the decision. Avoid adding new requirements through scattered feedback. Revise the scorecard openly when the job itself changes.

Check overlap against the team's actual schedule

Mexico City stays at UTC-6 and does not observe daylight saving time. Tijuana follows US daylight saving changes. A candidate's city therefore matters when you set shared hours. IANA North America time zone data.

Bogotá stays at UTC-5 without daylight saving time. Buenos Aires and São Paulo stay at UTC-3 without daylight saving time. US clock changes can still change the difference between those cities and your team. IANA South America time zone data.

Put the required hours in the role description using named time zones. Check the schedule for both US standard time and daylight time. Ask the candidate to confirm the local hours they would work.

Specify which events require live attendance. A daily meeting, release window and on-call shift may have different needs. Avoid describing all of them as "US hours."

Assess language through the work. Ask a candidate to explain a failed deployment to an engineer and then write an update for a business stakeholder. Judge whether the message is clear enough for the role. Apply the same standard to every candidate.

How do the hiring models change the process?

Choose the model by the responsibility you need someone else to take. Labels such as IT process outsourcing can cover different scopes. Make the scope explicit before comparing fees.

Use the table to frame questions. The agreement should spell out the provider's actual duties.

For recruiting process outsourcing, decide which stages stay inside your company. You may want outside sourcing while your team runs all technical interviews. Or you may want help with scheduling and candidate updates. Name an owner for each stage.

For staff augmentation, assess how the person will work within your team. Your reviewer needs time to review their code. Your manager needs time to set priorities. Include those commitments in the hiring plan.

For a managed service, interview the delivery lead about how work gets assigned and accepted. Ask what happens when the service misses an agreed target. A candidate interview alone cannot answer those questions.

Consider a support queue as an example. If your manager assigns tickets and coaches each analyst, assess the people who will join that workflow. If you expect the provider to run the queue, define coverage and escalation rules. Ask who handles an absence and who reports unresolved incidents.

Use that same ownership test for software work. Buying a developer's time does not settle who approves scope or accepts a release. Put those decisions beside the technical requirements so the commercial discussion matches the daily work.

Keep the interview tied to the job

A practical IT staff augmentation process can use a manager screen, a technical work session and a final discussion. Combine stages when the same interviewer can assess the evidence. Add a stage only when it resolves a specific unanswered question.

During the manager screen, describe the actual backlog. Ask which parts the candidate has handled and where they would need support. Confirm the role's scope before spending time on a technical exercise.

Use a small, sanitized work sample for the technical session. For example, give the candidate a failing test and enough code to investigate it. Ask them to explain assumptions, propose a fix and describe how they would check it.

Tell candidates whether AI tools are allowed. Apply the same rule across the search. If tools are allowed, ask the candidate to explain and validate the result. Keep credentials and customer data out of the exercise.

Offer reasonable accommodations and explain the format in advance. If a take-home task requires substantial work, agree on compensation before assigning it.

Give interviewers a shared scoring note for the exercise. A working fix may meet the delivery requirement while missing a security concern. Record both findings. Avoid rewarding a familiar coding style unless that style reflects a real requirement of the job.

Use the final discussion to resolve the remaining concerns. Ask about a past mistake, the evidence that exposed it and what changed afterward. Avoid repeating questions already answered in the work session.

Leave time for the candidate's questions about the job. Explain who reviews their work and how priorities change. If the role includes maintenance or support, say so before the offer. The candidate should be choosing the work you actually need done.

What should you ask a provider before choosing a finalist?

Send your questions with the scorecard. Request written answers that can carry through to the agreement and onboarding plan.

Start with candidate fit:

• Which requirements did the candidate demonstrate?
• Who assessed the work, and what did they review?
• Which requirements still need an interview?
• Has the candidate accepted the proposed hours and role scope?

Then ask about the full working arrangement. Confirm who handles equipment, access requests and payroll questions. Ask who your manager contacts when performance slips or the role changes.

For pricing, request a quote for the specific role, seniority and location. Ask what can change the invoice and who approves those changes. Confirm the billing start date and any separate costs.

Questions such as "How much does it cost to hire a game developer?" need a scope before they need a price. State the engine, platform, expected ownership and release work. For an app developer, describe the product, integrations and support duties.

Compare quotes against the same requirements. Check whether each quote assumes the same working hours and level of ownership. Have the budget owner review any equipment or support costs separately. Keep the accepted quote with the role scorecard so later changes have a clear starting point.

Agree on the start conditions

Ask what must happen between offer acceptance and the first working day. Assign each task to a person. Include equipment delivery, account setup and the first manager meeting.

Have your security owner approve the access plan. Use individual accounts and grant access based on the work. Define who removes access when an assignment ends.

Confirm the working schedule with both the candidate and the manager. Document how planned leave and local holidays affect meetings or releases. Ask the provider who coordinates coverage when needed.

Review the agreement's treatment of confidentiality and work ownership with your contracting team. Ask the provider to explain any terms that do not match the work you expect.

Prepare a fallback task in case a key account is delayed. It could be a local setup exercise or a walkthrough with the team. Give the hire a named contact for blocked access. Do not leave them to guess whether they should wait, message someone or request permission elsewhere.

Carry the scorecard into a 90-day plan

Write the onboarding plan before the start date. The following is a sample management plan, not a promised ramp time or a legal probation period.

In the first month, check whether the hire can reach the tools and people they need. Do not score an access delay as weak delivery. Keep a record of blocked work and assign someone to remove each blocker.

Choose a starter task that exposes the team's workflow without putting critical systems at risk. The hire should see how requirements become code, how reviews work and how changes reach users.

Ask the manager to review a work artifact during each check-in. Read a handoff note or examine a reviewed change together. Discuss what the hire understood, what required help and what should happen next. This gives feedback a concrete basis before the formal review.

During the next stage, give the hire ownership of a bounded piece of work. Ask them to clarify gaps, flag risks and keep the manager informed. Review the reasoning as well as the result.

Adjust the task when outside dependencies change. If a product decision blocks a release, record that decision and assess the work the hire could control. Keep the original goal visible, with a dated note explaining any change.

At the final review, return to the original scorecard. Compare the expected work with what the hire completed. Record where they can work alone and where they still need help.

If performance falls short, describe the gap with examples. Agree on the support, expected change and next review date. Involve the provider early enough to act on the issue.

Do not make a replacement guarantee your performance plan. The manager still needs to give feedback and maintain usable handoff notes.

Where does Opus fit in this hiring process?

Opus states: "The client chooses the finalist and manages day-to-day work." Build your process around having a manager who can make that choice and direct the work afterward. Opus hiring process.

Opus reports: "Opus delivers 3 vetted candidates in 5 days." Treat shortlist delivery as a separate milestone from the first working day. Ask for a schedule that includes your interviews and the finalist's start conditions. Opus hiring process.

Reserve interview time before the shortlist arrives. Give the interviewer the scorecard and name the person who can approve an offer. Ask how a change in requirements would affect the search.

Opus reports: "Every candidate passes an 8-layer vetting process." It also reports: "Every Opus placement completes a 6-module internal AI certification before day one." Ask which evidence applies to your role and which skills your team should still assess. Opus hiring process.

Use your own work sample to resolve any remaining role-specific questions. For a backend hire, that might be transaction handling or a production debugging scenario. For an app developer, it might be an integration failure. Agree on what the provider has already assessed so candidates do not repeat the same exercise.

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. Opus pricing.

Dollar rates: Not published. Ask for a written quote for your scorecard, then confirm the start conditions and working hours.

Before proceeding, have the hiring manager identify the first task and the review schedule. Those choices give the finalist a clear account of the job. They also give your team a way to judge whether the placement is working.

Talk to Opus about a role.

<!-- Not saved to disk: filesystem access is read-only. Build validation was not run. -->