Hiring & the ATS

Hiring is the first step in Interwise’s core value loop: hire, onboard, run payroll, pay out — repeat every period. This page goes deep on the first two steps. The Hiring module is a full applicant-tracking system (ATS) built directly into Interwise: job posts, a public careers page candidates apply through, a pipeline a hiring team runs — with screening questions, structured scorecards, collaborative reviews, offers, candidate emails, job-board distribution, and AI assists — and, at the end, the one thing no standalone ATS can do: a hired applicant converts directly into an employee record, ready for its first payroll run, without anyone re-typing a single field into a second system.

Job Posts#

A job post starts as a DRAFT and is only visible to the company’s own admins. Publishing it (PUBLISHED) is what makes it appear on the public careers page — closing it (CLOSED) removes it from that page without deleting its history or its applicants. Creating and publishing a job requires COMPANY_ADMIN (or higher); every job post has a unique, URL-safe slug within its tenant, generated from the title if one isn’t given.

A job post carries the basics a candidate needs to decide whether to apply: title, department, location, employment type (full-time, part-time, contract, internship), a work arrangement (on-site, remote, or hybrid), and a description written in markdown. Publishing a job does more than list it on the careers page — it also emits the structured data that gets the role into Google Jobs and gives it clean social previews, both covered under Distribution below.

The Public Careers Page — Interwise’s Only Public Surface#

The careers page is deliberately the one part of Interwise reachable without a login. Every other page in the product sits behind a session; the careers page and its apply flow are the exception, served from a completely separate, unauthenticated route that resolves the tenant from a slug in the URL and reads only what’s already PUBLISHED.

Because it’s the one thing an outside candidate — or a competitor, or the company’s own client — ever sees of Interwise directly, it carries outsized weight: it speaks for the company. It has to load fast, look clean, and feel trustworthy on a phone in one hand, because that’s how most candidates in Indonesia actually apply. There’s no excuse for a clunky public form when the entire rest of the product is behind a login and never seen by anyone outside the company.

The apply form is deliberately minimal: full name and email are required; phone, a CV (upload a PDF/DOC/DOCX up to 5MB, or paste a link instead), a cover letter, and an expected start date are optional. That’s the whole form — no NIK, no bank details, no date of birth, no dependents, no address. Those are Indonesia-specific payroll and compliance fields, and Interwise deliberately doesn’t collect them on a public, unauthenticated form; asking a candidate for a national ID or bank account number before they’re even hired is a privacy and professionalism problem, not a convenience. That data is collected once — during onboarding, after the candidate is hired, by HR inside the product.

The one thing the form does add per job is screening questions the company chose (covered next). And once a candidate applies, the same page becomes their status page: a magic link — no login — lets them check where their application stands.

Screening Questions & Knockouts#

Any job can carry a short set of screening questions that a candidate answers on the apply form. Each is a short- or long-text field, a single- or multiple-choice list, a yes/no, or a number, and can be marked required. They do two things: capture the answers the recruiter actually needs up front (so triage isn’t a guessing game), and — for choice and yes/no questions — carry optional knockout answers.

A knockout answer is a hard disqualifier the company defines (“Are you legally allowed to work in Indonesia? — No” knocks out). When an applicant submits a knockout answer, Interwise auto-rejects the application on the way in, so it lands in Rejected instead of cluttering the New column. Nobody has to read a stack of applications to weed out the ones that never qualified — the pipeline stays clean, and the recruiter’s attention goes only to candidates worth a look.

The Applicant Pipeline#

Once an application comes in, it moves through a fixed set of stages, shown to the hiring team as a stage board — one column per stage, cards moving left to right as a candidate progresses.

• New — the application just came in, untouched.
• Reviewing — a hiring manager is looking at it.
• Interview — the candidate is being interviewed.
• Offer — an offer is out.
• Hired — the candidate accepted, and the application is ready to convert.
• Rejected — a candidate can be moved here from any of the first four stages (or auto-rejected on the way in by a knockout answer); it’s a dead end, not a stage in the forward sequence.

The board is built for fast triage, because a real hiring round is a stack to get through, not one candidate at a time. Above the columns is a toolbar: search by name or email, filter by stage, tag, source, or minimum rating, and sort. Every card has the next action right on it — a one-tap stage move, an inline rating, a quick-reject, and a self-guiding “Start Review →” button so nobody has to wonder what to do with a New candidate. Checkboxes turn on bulk actions to move or reject many at once. Every application also carries a source (where it came from — the careers page, a shared link, a job board) and free-form tags, so a recruiter can slice the pile by channel or by any label the team invents.

Structured Evaluation#

Moving a candidate forward is a decision, and Interwise makes that decision structured and shared rather than a number one person types from memory.

• Scorecards. Each job gets a set of evaluation criteria — sensible defaults like Technical, Communication, and Culture Fit, editable per job. A reviewer rates the candidate 1–5 on each criterion for the round they interviewed, plus an overall recommendation and markdown notes. The applicant view then shows the average per criterion across every review, so two candidates are compared on the same consistent axes instead of on vibes.
• Interviewers as real people. An interview round is assigned to an actual teammate, not typed as free text. The moment they’re assigned, that round shows up on their own “pending reviews” surface, with a deep link straight into the candidate — so an interviewer always knows exactly what’s waiting on them and lands one click from filling in their scorecard.
• Activity timeline & comments. Every applicant has a running timeline that auto-logs what happened — applied, stage moved, interview added or completed, interviewer assigned, offer sent or accepted — merged with a comment thread where teammates can discuss the candidate and @-mention each other. The whole history of a hire lives in one place, so a decision is never a black box.

Offers#

When a candidate reaches the Offer stage, HR records an offer against the application: the basic salary, any allowances, and a start date. The offer runs a small state machine — DRAFT → SENT → ACCEPTED / DECLINED / WITHDRAWN — that the product enforces, so an offer can’t skip from draft straight to accepted. From the draft, Interwise generates a formatted offer-letter PDF on demand, and (when candidate email is configured) an offer email goes out on the move to SENT.

The offer isn’t just paperwork — it’s the number that feeds payroll. When the offer is accepted and the candidate is converted, the salary and start date HR agreed on the offer become the new employee’s compensation, with no one re-typing a figure. That handoff is the wedge.

The Wedge: Offer → Hire → First Payslip#

The point of running hiring inside Interwise rather than beside it: converting a Hired applicant into an employee is one action, and it reuses the exact same employee-creation path a manually-added employee goes through — so an ATS-sourced hire is never a special case for tax, BPJS, or employment-period logic.

What carries over automatically: full name (split into first/last), email, and phone from the application; the job title from the post they applied to; the start date; and — this is the wedge — the basic salary from the accepted offer, seeded as the new employee’s compensation. NIK, bank details, address, and the PTKP code were never on the application (a public form shouldn’t be where BPJS or tax filings depend on being exactly right), so those start blank.

That’s not a gap, it’s a guided next step. The new employee’s record shows an onboarding checklist — basic salary confirmed (already ticked, straight from the offer), then NIK, bank account, and address still needed — each with a link to complete it. Once the checklist is done, it collapses into a single “Run First Payroll” call to action. The path from a signed offer to a first payslip is a handful of clicks with the product telling you exactly what’s left at each one.

Conversion is idempotent and collision-safe: converting the same applicant twice returns the same employee rather than creating a duplicate, and if another employee already has that email, the conversion is rejected with a clear conflict instead of silently producing a broken duplicate.

The Safety Guard: Recruiting Ratings Are Not Payroll Points#

The ratings a hiring team gives a candidate while they move through the pipeline and an employee’s points field are unrelated numbers that must never be confused — points distributes real money, weighting how a company’s monthly service-charge pool is split across employees. Mapping a recruiting rating onto it during conversion would silently corrupt that distribution with a number that was never meant to represent it. Interwise keeps them apart by construction: scorecard ratings stay on the application, full stop. The compensation that carries into the employee record is the salary HR deliberately put on the offer, not a recruiting number — and points is left for HR to set afterward through the normal employee flow. It’s a small rule, but it’s exactly the kind of place where hiring data and payroll money need a hard line between them.

Candidate Communications#

A candidate who applies and then hears nothing is the fastest way to look unprofessional. Interwise sends templated, tasteful emails at the moments that matter — application received (with a link to their status page), a status update or a warm rejection when their stage changes, an interview-scheduled note, and the offer when it’s sent. Sending is fire-and-forget: an email problem can never break the pipeline action that triggered it, and a candidate can always check their own status page via the magic link without an account.

Email delivery is turned on by configuring a sending provider and a verified sending domain for the company; until that’s set, the pipeline runs exactly the same and simply doesn’t send — nothing breaks, and no half-configured email ever goes out.

Distribution#

Publishing a job should get it seen, not just listed. Every published job page carries:

• Google Jobs structured data — a schema.org JobPosting block (title, description, date posted, hiring organization, location, employment type, and a remote flag for work-from-home roles) so the role is eligible to surface directly in Google’s jobs results — free reach, no job-board account required.
• Clean social previews — Open Graph and Twitter-card metadata plus a canonical URL, so a link shared in a WhatsApp group or on LinkedIn unfurls into a proper preview instead of a bare URL.
• One-tap sharing — a share control on both the admin job view and the public page itself, prefilled for LinkedIn, WhatsApp, X, and copy-link.

Direct posting into third-party boards (LinkedIn, Indeed, Glints) needs those platforms’ own credentials and partner access, so it isn’t wired up yet — it’s the natural next step, not something the docs will pretend already exists.

AI Assists#

Interwise adds a layer of AI help across hiring, built to cut the busywork a recruiter would otherwise grind through by hand:

• CV parsing & auto-fill — extract a candidate’s name, contact, years of experience, skills, education, and current role from an uploaded CV, and one-click apply the contact fields to the application where they’re missing.
• Candidate summary — a short, at-a-glance blurb (fit signal, key strengths, and risks) built from the CV, screening answers, and interview notes, so a reviewer can triage a stack faster.
• Job-description generation — draft a full JD from a title and a one-line brief on the job form, which HR then edits before saving.

These run on Anthropic’s Claude models and are turned on by configuring an API key; results are cached on the application so the same CV isn’t re-analyzed on every open, and scanned image-only CVs are skipped gracefully rather than guessed at. Like email, the AI layer is optional: with no key configured the rest of hiring is completely unaffected.

Reports & Exports#

Hiring decisions get shared and defended — with a hiring manager, with leadership, with compliance — so Interwise exports them at three scopes:

• Per applicant — a clean, shareable PDF: details, source, current stage, screening Q&A, every interview scorecard, a CV reference, and the activity timeline.
• Per job — the funnel (counts per stage, source breakdown, average rating) as a PDF summary, plus a well-formed CSV of every applicant for a spreadsheet.
• Hiring overview — company-wide across jobs: total applications, funnel, source effectiveness, and time-to-hire, as PDF and CSV, over an optional date range.

Every export is one click from where the data already lives — the applicant drawer, the job page, and the hiring index.

Why Interwise’s ATS Beats a Standalone Tool#

Standalone applicant-tracking systems — SmartRecruiters, Greenhouse, Lever — are built to get a company to an offer, and stop there. What happens next is someone’s manual job: export the hire’s details, re-type them into a separate HRIS or payroll system, chase down the tax and bank fields the ATS never asked for. Interwise matches them on the hiring craft — screening, structured scorecards, collaborative reviews, offers, candidate emails, distribution, AI assists, reporting — and then closes the gap none of them can:

• Hiring→payroll continuity. Applicant, to a signed offer, to a Hired stage, to an employee record with the offered salary already in it, to a first payslip — one system, one data model, zero re-entry. No standalone ATS can do this, because none of them run payroll.
• Indonesia-native compliance, completed at the right moment. NIK, PTKP, and bank details — the exact fields PPh 21, BPJS, and disbursement need — are filled in via a guided onboarding checklist once HR onboards a hire, inside the same product that runs payroll, instead of a generic Western ATS form that has no concept of any of them and no route into a payroll system at all.
• Structured, self-guiding, and fast. Consistent scorecards, assignable interviewers, a knockout-screened and bulk-triageable pipeline, and next-actions on every card — a hiring team runs it without a dedicated recruiter or a second subscription to keep in sync with the HR system of record.
• A public careers page that reflects well on the company, discoverable in Google Jobs and clean to share, because it’s built into the same product that already has to be fast, clean, and mobile-first for every other user.

This stays an honest comparison, not a checklist: Interwise doesn’t do automated interview scheduling, video screening, or direct posting into external job boards yet. It does the part that matters most for a company that already runs its HR and payroll in Interwise — the handoff a standalone tool structurally can’t make.

Where to Go Next#

• Overview — the full core value loop this module feeds into, from hiring through payroll to a payslip.
• Payroll Engine — where a converted hire’s first run is calculated, line by line.
• Roles & Access — who can post a job, review a pipeline, and convert an applicant (COMPANY_ADMIN and above).
• User Journeys — the Hiring Manager’s day-to-day walkthrough of posting a job and running a pipeline to an offer.