Role Profiles and Standard Kits: Most Starters Are Not a Project

Tuesday, 10:15, at Bellweather Logistics, a haulage and warehousing firm with a desk of four. An onboarding request has arrived for a new warehouse team leader starting in eight working days. Jake, who has claimed it, messages the warehouse manager to ask what the new person needs. The reply comes back in four words: "The same as Dev." Dev was a team leader who left eight months ago. He had been at Bellweather since the warehouse opened. He had been given access to everything at some point for some reason, and had never had any of it taken away. Jake pulls up what Dev used to have and finds the warehouse system, the transport system, the finance reporting folder, and the HR shared drive. He also finds a group called "Legacy-Admins" that nobody on the desk can explain. Noor, who runs the desk, looks over his shoulder and says the sentence every desk eventually says: "We are not giving a new starter the same as Dev."

A role profile is a short written description of what a type of job gets from IT by default. It lists the hardware, the software, the access, the phone, and the name of the person who agreed each part in advance. A standard kit is the hardware and software half of that, built the same way every time and kept on the shelf when stock allows. Together they turn most onboardings from a project, designed from scratch for one person, into a selection, picked from a list of five. This article is part of our Employee Onboarding series. It is about writing that list, keeping it short, and handling the starters who do not fit it.

It covers how access gets designed by accident, and the handful of profiles that cover most starters. Then come the standard kit for each, the access bundle with its approvals agreed in advance, and the exception path for everyone else. Next come keeping the profiles honest, a table of the five profiles at a fictional firm, and a short war story. It ends with the role profile card to copy, in that order.

"The Same as Dev": How Access Gets Designed by Accident

Most access on most desks was never designed; it was copied. The first person in a role was given what they needed at the time, plus a few things that were convenient. They also got whatever was added over the following years as projects came and went. The second person was given "the same as" the first. The third was given the same as the second. By that time the list included a folder from a finished project, and a group from a system that was replaced. It also included an admin right that was granted for one afternoon and never removed. Nobody chose any of it. Each copy inherited every accident of the one before.

The cost shows up in three places. The audit, internal or external, that asks why thirty warehouse team leaders can read finance reports, and gets the answer "because Dev could". The leaver, whose access takes a day to unpick because nobody knows which of the forty groups mattered. And the starter gets either too much, which is a risk, or too little, which is a week of access tickets. That depends on whether the person being copied was a hoarder or a minimalist. The principle that nobody gets more than the role needs is covered in Least Privilege Under Pressure. The profile is how a desk applies it to starters without a conversation every time.

The alternative to copying is writing it down once, per role, with the person who owns each system agreeing that "anyone in this role gets this". That agreement is the whole trick. Once it exists, the onboarding does not need an approval and the desk does not need to guess. The leaver's access can then be removed by profile rather than by archaeology. It takes an afternoon per profile to write and a few minutes a quarter to keep. (The afternoon is the part people skip. The quarter is the part they skip afterwards.)

The Handful of Profiles That Cover Most Starters

Five profiles cover most organisations' starters, and the way to find yours is to count. Take a year of onboardings and write each starter's job title in a column. Group the titles by what they actually use. At Bellweather, a year of sixty-two starters grouped into five piles: office workers at head office, drivers and other field staff, finance, warehouse, and managers. Fifty-one of the sixty-two fitted one of the five with no changes. Seven fitted with one exception each. Four were genuinely one-off roles. That is the pattern on almost every desk I have counted. It has a handful of profiles, a few exceptions, and a small tail of people who are a project whatever you do.

The office profile is the desk-based worker. It includes a laptop, a dock and screen, the standard software, the shared folders for their department, and the printer at their site. It also includes remote access if the organisation allows working from home. The field profile is the person who is rarely at a desk. It includes a phone, perhaps a handheld or a rugged device, and the mobile version of whatever system they use. It includes a mailbox that is read on the phone, and usually no laptop at all. The finance profile is the office profile plus the finance systems, and a second screen because spreadsheets. It also includes the tighter controls on who can change what that finance roles need. The warehouse profile is a personal account used on shared terminals and scanners, and the warehouse system. It includes a shift-pattern mailbox that is checked at the start of the day, and no laptop. The manager profile is the office profile plus the team's shared mailbox, and the reporting views of the systems their team uses. It also includes the approver role in whatever workflows the organisation runs.

Resist the urge to make twenty. A profile for every job title is a job-title list, not a profile list. It reintroduces the per-person design the profiles were meant to remove. The test for a new profile is numbers. If a role arrives three or more times a year and does not fit an existing profile with one exception, it earns a card. If it arrives once, it is an exception on the nearest card. Five to eight profiles is the range I have seen work. Past ten, the list stops being read and the desk goes back to asking the manager.

Name each profile for the work, not the department. Use "office" rather than "head office staff", "field" rather than "transport". A field worker in the sales team and a field worker in transport need the same kit. A department name would put them on different cards. The department decides the shared folders and the distribution lists, which are a line on the card, not a separate profile.

The Standard Kit for Each Profile

The standard kit is the hardware and the software image for the profile, named and built the same way every time. "The office kit" at Bellweather is one model of laptop, one dock, one screen, one headset, a mouse and a bag. It is built from the current image with the office software on it. "The field kit" is one model of phone with the mobile applications, a car charger and a case. "The warehouse kit" is nothing to issue, because the terminals and scanners are shared, plus a badge that works on the warehouse doors. The point of naming the kit is that it becomes a thing that can be built on a quiet Tuesday. It can be built for a starter who has not been hired yet, and kept on the shelf.

Building ahead is the single biggest gain from standard kits, and it is what turns a two-day notice into a workable day one. If the desk keeps one office kit and one field kit built and waiting, a starter who arrives with no notice gets a standard device in the time it takes to create an account. The stock arithmetic, how many to hold, and what it costs to hold them are covered in Stock Management for a Small Desk. Here the point is that a kit can only be built ahead if it is standard. A kit that depends on the starter's preferences cannot be built until the starter has preferences.

The standard is also what ends the negotiation. The starter who would prefer a different laptop, a larger screen, or a different brand of headset is asking for an exception to a standard. The standard exists in writing with a reason. The arguments for setting equipment standards and the way to hold them politely are in Standards That End the Monitor Debate. A profile card that names the kit is the standard, applied to one role. The conversation it saves is the one that begins "but the person I'm replacing had".

The software half of the kit is the image: the operating system and the standard applications, built once and applied to every device of that profile. Anything beyond the image is a software request. The workflow for those, including which software is pre-approved for which roles, lives in Installing It: Packages, Standard Images and the One-Off. The card lists what is on the image for the profile and what the profile is pre-approved to have added. That makes a finance starter's second spreadsheet tool a tick on the card and not a request with an approver.

The Access Bundle, Approved in Advance

The access bundle is the list of groups, folders, applications and roles a profile gets. The thing that makes it a bundle rather than a wish list is that each line has been approved once, in writing. The person who owns that system has approved it for everyone in the role. The owner of the warehouse system has agreed that every warehouse starter gets a standard user account in it. The owner of the finance folder has agreed that every finance starter gets read access to it and that write access is an exception. The approval was given once, on the card, with the owner's name and the date. It does not need to be given again for each person.

This is the design decision that removes approvals from onboarding, and it is worth being precise about what it does and does not do. It does not remove the approval. It moves it from the person to the role, and from the day the request arrives to the afternoon the card was written. The manager's job at onboarding time is to confirm the profile, "yes, she is finance". It is not to approve each of the fourteen lines, which they could not evaluate anyway. The system owners' job is to review the bundle twice a year and say whether it is still right. The design of access approvals in general covers who may approve what and how to keep an approval from stalling. It is the subject of The Access Request, Done Properly and the article after it. The profile is the case where that design has been done in advance.

Most small-team help desk tools have no approval engine, and QuerySolv is one of them. The pre-agreed bundle is what makes that irrelevant for onboarding. The only approval the ticket needs is the manager's one-line confirmation of the profile, which is a reply on the ticket. Where an exception does need a separate approval, the convention for recording one without an engine is a named approver replying on the ticket. The reply includes the words "approved" and the scope. That convention is in Approvals Without a Workflow Engine. The profile card is the same convention applied once per role instead of once per person.

Write the bundle as a list of named groups wherever the directory allows it. That makes granting the bundle a matter of adding the account to a handful of groups rather than touching thirty folders. A group per profile, or a group per system per profile, is the usual shape. It also makes the leaver's removal the reverse operation. The Offboarding Checklist relies on this: remove the profile's groups and most of the access goes with them. Access granted directly to a person, outside the groups, is the exception path's territory and is tracked as such.

The Exception Path for Everyone Else

Every starter gets a profile. The ones who do not fit get the nearest profile plus a short list of differences, raised as separate requests. The sole designer gets the office profile plus the design software and a larger screen, two exceptions. The data analyst gets the finance profile plus read access to two more systems, two exceptions. The contractor on a six-month project gets the office profile minus remote access and minus the department folders, with an end date. That is a profile with subtractions rather than additions and is handled the same way. Nobody is designed from scratch. Everyone is a profile and a difference.

Each exception is a ticket of its own, linked to the onboarding's parent, with the approver named and the approval recorded in the approver's words. That keeps the profile honest, because the profile never grows to include the exception. It keeps the audit honest, because every piece of access outside the bundle has a ticket with a name on it. It keeps the leaver honest, because the exceptions are the lines that have to be removed by hand when the profile's groups come off. An exception that is not a ticket is a piece of access nobody will remember granting.

Watch the exceptions for patterns, because the pattern is how the profiles improve. If three office starters in a quarter all needed the project-tracking application, it belongs on the office card, approved once by its owner. If the warehouse manager keeps asking for the transport system for team leaders, team leader may be a profile or a line on the warehouse card. The desk is the only place that sees all the exceptions together. A quarterly count of them, by profile and by what was asked for, is a few minutes with the linked tickets. It is the most useful review the profiles get. Exceptions, left uncounted, quietly become the process.

The temporary exception needs an end date on the ticket, and a reminder, and the discipline to remove it. "Write access to the finance folder for the year-end, until the end of the month" is a fine exception. The same access eleven months later, still there because nobody set a date, is a copy of Dev in the making. The desk's own follow-up habits apply. A ticket with an end date is a ticket that is not closed until the access is removed. Follow-Up Cadences That Keep Tickets Moving is the routine that makes sure it is.

Keeping the Profiles Honest

A profile drifts the same way a person's access drifts, by one more line at a time. It is kept honest by a review with a date on it. Twice a year, the owner of each card sits down for half an hour with the system owners and one manager from the role. The card owner reads the bundle line by line, and asks of each line whether a starter in this role next month would need it. Lines that get a "no" or a "not any more" come off. Lines that have been raised as exceptions three times go on. The card's revision number goes up and the date of the review goes on the foot of the card.

The leaver audit is the other check, and it works in the opposite direction. When a person leaves, their actual access is compared against their profile's bundle. The difference is either a recorded exception, which is fine, or an accumulation, which is not. A desk that does the leaver audit properly learns, from each leaver, how far the role's real access has drifted from the card. The desk either corrects the card or corrects the drift. Dev's forty groups were an audit that nobody ran.

Keep the cards where the desk will find them and nobody else will edit them. One page per profile, in the desk's internal documentation with a named owner, is the right home. If you run QuerySolv, the knowledge base's agent-only articles are a natural place for them, next to the runbooks. There, a technician building a kit can open the card without leaving the ticket. Wherever they live, the test is the same. Can the newest technician on the desk, handed an onboarding request for a finance starter, build the kit and grant the bundle from the card alone? Can they do it without asking anyone what Dev had?

A Short War Story: The Store Manager Profile at Northgate Retail

Northgate Retail, a chain of about thirty shops with a desk of two, built its store manager profile the quick way. It copied the access of the first store manager it had onboarded after the desk was set up, a woman called Carla. She had previously been a regional manager and had kept her regional access when she moved to run a single store. For two years every new store manager was given "the same as Carla", which included the regional pricing tool. For two years thirty store managers could change prices across the whole chain. That fact came to light when an external audit asked for a list of who could do exactly that. The desk's technician, Femi, produced a list that was thirty names longer than the finance director expected. The clean-up took a weekend of removals, and a re-approval of every line on the profile by the system owners. It also took a written explanation to the audit committee of how it had happened. That was harder to write than the technical fix had been to do. Nothing had been changed maliciously and no price had been altered. The finance director described that as "fortunate", in the tone of a man who did not intend to rely on fortune again. The profile was rewritten from a blank page in an afternoon, with the pricing tool as a regional exception. The audit the following year found the list it expected. A profile built by copying inherits every accident of the person it was copied from, and the person is always Carla.

The Role Profile Card

The card below is one page per profile, filled in once with the system owners and reviewed twice a year. The kit section names the hardware and the image. The access section lists the bundle line by line with the owner who approved each line and the date. The phone and extras sections cover the rest. The exceptions section records the differences that come up often enough to be worth noting. That lets a technician see at a glance that "finance plus write access" is a known shape with a known approver. The foot carries the owner, the revision and the review date, because a card without a date is a card nobody has checked.

ROLE PROFILE CARD — ONE PAGE PER PROFILE (revision ____)
Profile name: ______________   Card owner: ______________   Last reviewed: __________
Roles that use this profile: ______________________________________________

1. STANDARD KIT
   Device: ______________________   Image: ______________________
   Dock / screen(s): ______________   Headset / peripherals: ______________
   Pre-approved extras (no request needed): ______________________________

2. ACCESS BUNDLE (each line approved once, for everyone in the role)
   Group or system                      Level          Approved by          Date
   ______________________________       __________     ______________       ________
   ______________________________       __________     ______________       ________
   ______________________________       __________     ______________       ________
   ______________________________       __________     ______________       ________
   Remote access: [ ] yes  [ ] no       Site printers: [ ] yes  [ ] no

3. MAIL AND PHONE
   Distribution lists: ______________________   Shared mailboxes: ______________
   Phone: [ ] extension  [ ] mobile  [ ] none

4. KNOWN EXCEPTIONS (raised as separate requests; approver named)
   Exception                            Usual approver       Needs end date?
   ______________________________       ______________       [ ] yes  [ ] no
   ______________________________       ______________       [ ] yes  [ ] no

5. CONFIRMATION AT ONBOARDING
   Who confirms the profile for a starter: ______________ (one reply on the ticket)
   Lines that need a separate confirmation each time: ______________________

6. REMOVAL AT LEAVING
   Groups to remove: ______________________   Exceptions to check by hand: [ ] see linked tickets

CHANGE LOG
   rev ____: __________________________________ by ______________ on __________

Noor and Jake wrote the warehouse team leader card that afternoon, from a blank page, with the warehouse manager on the phone for forty minutes. It had the warehouse system, the shift mailbox, the transport system as a read-only line because team leaders check deliveries, and nothing else. The new team leader got exactly that, eight days later. He raised one ticket in his first month, for a scanner with a cracked screen. Dev's forty groups were removed from the directory the following week. Nobody noticed, because nobody had been using them. The desk kept the card. It has not, so far, needed Dev again.

Frequently Asked Questions