It really depends on the size of the org.
Here's my explaination of current and past two roles in companies of different sizes.
Company 1; was an elite small team which specialised in different areas but "should' have enough skills to cover for members being off. This worked well; I had to cover everything from helpdesk to development of servers. The issue that I or we had was that the management changed and lost it's backbone, in fact I; personally felt insultanted enough to leave as my role was treated and said to be a helpdesk role then next meeting I was being moan to about a system not being developed in time.
This only really works in small orgs with less managers/VIPs and they need to understand where they are in the pecking order. The more staff that expect/get preferential treatment for incidents the more water-down the service becomes.
Company 2; there was no official dev and ops selections for my area of the IT department, we used a lot of third parties including people from different areas of the department for dev, so I guess I would be part of the ops teams who was a stake holder and had a major say in how things should work. Incidents/requests was dealt with by first and second line. My BAU was security, checking over dev implementation, writing KB/Doc/Known issues, declaring/resolving/documenting known promblems, coms with the dev members, supporting 2nd/1st line, training and CAB.
Company 3; I'm rather new, but it's split internally between dev and ops, I'm in the Ops team; we have individual roles even in the sub-sub teams but it's similar to what I do at company 2, but with other stuff like going live with new systems.
Personally; I hate the term BAU... Business as Usual for one company, IT department, Team, Person is different for another...
I would check the service catalogue; this should be the bible.. so that it's clear which person/grade deals with what request/incidents.
My believe is
1st line: Advice, hand holding, most requests (if not automated), issues that don't require admin rights or issues that are well known that do require admin rights.
2nd line: Troubleshooting/resolving, draft KBs, harder to deal with requests and some project work to help development of staff.
3rd line: Security, helping other IT staff, Documention/KBs (pref done by the service owner or the person who setup the system), Training, project work, problems, demands/new services and changes.
You may find that 3rd line has a lot less incidents/requests to deal with and more time for projects/demands.. rather than fixing the end users issue, write a kb or train the 2nd liner how to resolve the issue, so that issue should get to 3rd line again as it can be refered to the KB or person.
There needs to be a "experinced" person or people at each level for people to turn to for help; grade 1.5/2.5/leaders/manager; it's horrible for someone not to have somewhere to turn to when they need help. In large orgs; some systems (and hate to say it "local knowledge") will be available to 1st liners that 3rd liners don't have or the experince in using, so even 3rd liners will need to reach out to 1st line to check something. Those people should be identify and recognised/paid.
As for the actual OP question... how to manage 3rd line time.
It depends on your staff... I'm happy to take an hour towards the start and end of the day to resolve/refer incidents.
it may be that you have one 3rd liner per day/week/month dealing with nothing but BAU and helping staff.
Have Gnatt charts of whos working on what; to a low level.. this person is working on this part/issue of the project, and have BAU as part of the Gnatt chart.
Roadmaps to show what the team is planning to be doing in the future and the time scales that is required.
and I hate to say it... time sheets.. as long as your staff can show that they are busy and you can show your paymasters that they are busy with the time sheets and gnatt charts, if they want more doing; they need more IT staff.
