A consultant CV house style is a one-page standard that gives every profile your team sends to a client the same tone and terminology: person, tense, skill names, the role-title rule and summary length. It also lists what may never change: dates, titles actually held, employers or clients, results, qualifications and language levels. Apply it to every profile before it goes out, and check each edited line against the source, so that consistency never upgrades anyone's experience.
Below is the standard to copy, three profiles written by three different people, the same three after the standard, and the source check that keeps the edit honest.
Why tone and terminology drift between writers
A shortlist is rarely written by one person. One profile comes from a subcontractor in the first person, one is the candidate's own CV in the third person, and one is a note from your bench written in fragments. Two or three recruiters edit them on the same afternoon. Each profile can be accurate and still read as if it came from a different company.
The client sees the drift side by side: "k8s" in one profile and "Kubernetes (EKS)" in the next, a "Senior Software Engineer" beside a "Java dev", one summary in a single line and another in a paragraph of praise. The client ends up comparing the writing, not the specialists: the bench note looks junior next to the candidate's paragraph of praise, even when both have comparable experience. Your template fixes the layout. It does not fix the words.
The one-page house style to copy
Paste these eight rules into your team's profile guide and replace the skill list with the technologies your clients ask for.
- Summary. One to three sentences, at most about 60 words. No pronoun and no name ("Backend developer with …"). No personality adjectives such as "passionate", "highly motivated" or "rockstar".
- Project bullets. Start with an action verb. Past tense for finished projects, present tense for the current one.
- Skill names. Use the team list, one spelling each: Java, Spring Boot, Kubernetes, AWS, PostgreSQL, Kafka.
- Role title held. Exactly as the source or employer gave it. Expanding an abbreviation is allowed ("Lead dev" → "Lead Developer"), nothing more. Do not convert a seniority level to your own scale. The role you propose for this client goes on a separate "Proposed role" line.
- Dates. MM/YYYY – MM/YYYY. The current role is "MM/YYYY – present".
- Numbers and scale. Years of experience, team size and volumes only where the source states them or its dates support them. Words like "scalable" only where the source gives a load or volume that backs them.
- Never change. Dates, titles held, employers and clients (or their agreed anonymised label), results, certifications, education, language levels.
- Unclear in the source? Ask the consultant. Do not fill the gap.
Three consultant profiles as they arrived
Fictional example: three backend specialists in a comparable seniority band, proposed for the same client project. Each source was written by someone else.
Profile A: subcontractor, first person, past tense for a current role, shorthand
I developed microservices in java spring boot. Also did k8s deployments, worked with aws. Senior Software Engineer, 03/2021–now.
Profile B: the candidate's own CV, third person, narrative with praise
Marta is a highly motivated and passionate Backend Developer with 9+ years of experience. She develops scalable services in Java, Spring, Kubernetes (EKS) and Amazon Web Services. In her current role she builds the order API of a logistics platform and took part in its migration to EKS. Backend Developer, 01/2016–present.
Profile C: internal bench note, fragments
Java dev. SpringBoot, K8S, Postgres. Lead dev on payments project 2021-2023. Responsible for the settlement module.
The same three profiles after the house style
Profile A
Proposed role: Backend Developer (Java)
Senior Software Engineer · 03/2021 – present
Summary: Software engineer building microservices in Java and Spring Boot, deploying services to Kubernetes and working with AWS.
- Develops microservices in Java and Spring Boot.
- Deploys services to Kubernetes.
- Works with AWS.
Profile B
Proposed role: Backend Developer (Java)
Backend Developer · 01/2016 – present
Summary: Backend developer with 9+ years of experience. Develops services in Java and Spring on Kubernetes (EKS) and AWS.
- Builds the order API of a logistics platform.
- Took part in the platform's migration to Kubernetes (EKS).
Profile C
Proposed role: Backend Developer (Java)
Lead Developer, payments project · 2021 – 2023 (months to be confirmed by the consultant)
Summary: Java developer working with Spring Boot, Kubernetes and PostgreSQL.
- Was responsible for the settlement module.
The three now read as one team's work. None of them says more than its source.
Check every edited line against the source
Read each normalised line next to the line it came from. Form may change; the fact must stay the same size.
- Profile A. Changed: first person removed, tense set by the role dates, "java spring boot", "k8s" and "aws" spelled from the team list. Stayed: the title, the dates, the three activities. "Did k8s deployments" becomes "Deploys services to Kubernetes", not "Manages Kubernetes clusters": deploying to a platform is not running it. "Worked with AWS" stays vague; if the client needs to know which AWS services, ask.
- Profile B. Changed: the name, "highly motivated" and "passionate" removed; "scalable" removed too, because the source gives no load or volume to back it (rule 6); "Amazon Web Services" becomes AWS. Stayed: "9+ years", because the source states it and 01/2016 supports it; the years describe her experience, not each technology, so they stay in their own sentence. "Spring" stays Spring and is not turned into Spring Boot, which the source does not name. "Took part in" the migration does not become "Led".
- Profile C. Changed: "Lead dev" expanded to "Lead Developer"; "SpringBoot", "K8S" and "Postgres" spelled from the list. "Responsible for the settlement module" becomes "Was responsible for the settlement module", not "Delivered the settlement module": the source does not say it was finished. Open: "2021-2023" has no months, so ask the consultant instead of writing "01/2021".
A profile with an open question is not ready to send: send the client the profiles that are, and add this one once the consultant has confirmed the months.
Whose words are they?
Some recruiters argue that a consultant's wording belongs to the consultant and should not be standardised. The house style answers that by changing form, never facts. Before a profile goes to the client, the consultant or candidate sees the client version and confirms the facts in it. Profiles from a subcontractor go back to the subcontractor for the same check. Everyone keeps their experience exactly as it was; the client simply reads it in one voice.
Where wording ends and layout begins
The house style covers words. Headings, field order, page length and the export format belong to the client's template: test that with the client-template acceptance card for consultant CVs. The full comparison of a profile with its source CV and interview notes, including availability and claims you cannot verify, is in the worked case on checking candidate profile accuracy. For the overall structure of a standard agency CV, see CV standardisation for recruitment agencies.
Applying the house style at volume
TalentVeil's automated CV formatting rewrites each profile for the client in your own branded template, which you can edit, and exports it to PDF or Word. The recruiter applies the team's standard and checks it against the source before export. Then you share the approved shortlist in a branded client portal: the client marks the specialists they want to meet and leaves feedback on each profile, and you are notified when the link is opened.
See the workflow on three profiles from your next shortlist: the free trial gives you 10 days and 10 profile generations, enough to check each one against its source before you share the shortlist.