I can think of many things that could qualify at "internal tools." The question is broad and the answers depend on what your business is, who works there, and what they do (yourself included!)
Possible "internal tools" that come to mind are:
(1) Analytics
(2) CRM-y stuff for the sales and support people
(3) Deployment and testing stuff for technical people
(4) CMS-y stuff to enable non-technical people to experiment with, or even implement, things that are client-visible. And for technical people to do so more efficiently.
(5) Backup, redundancy, disaster recovery etc
If none of these seem more important than others, I guess you need to ask: where is the business now? Where will it need to be in <x> months? How are we getting there? What are the pain points? How can the above improve this (versus implementing new features)?
One cherry-picked example: should technical staff time be spent on improving sales? If sales are your company's limiting factor and you don't have enough salespeople, making them more efficient is really important. If you're still in a soft launch-ish place, then it's not. If you have enough salespeople but not enough leads, maybe mining your own data, or public data, could produce some.
You're generalizing too much. 1 and 2 are actually internal products and should be planned and budgeted out by higher-ups as projects. I have no idea what would constitute #4 the way you describe it, but it sounds like a business requirement that should also be dealt with as a project or internal feature. Lastly, #5 is business continuity and a primary function of IT in general.
This leaves #3 as a sector where the manual/automation see-saw can be improved by tooling. The others are more aspects of business that do not happen otherwise. Tooling is more concerned with easing the jobs of people who implement the thing being streamlined with the tool. In a sales context this would be something like switching to a shared address book or whiteboarding an in/out scheduling chart, both of which they can do for themselves. Interdepartmental deliverables are not tooling.
I think he was actually fair spot on, I work on an "Internal Tools" team, and we do #1 - #4, in addition to maintaining the bug tracker, finance and audit tools, and a translation/review product. #5 is definitely DevOps though.
You both may be right in terms of the semantics and divisions of labor in your respective companies/experiences, but they are more general than the historical sense of tooling in a systems context.
Possible "internal tools" that come to mind are: (1) Analytics (2) CRM-y stuff for the sales and support people (3) Deployment and testing stuff for technical people (4) CMS-y stuff to enable non-technical people to experiment with, or even implement, things that are client-visible. And for technical people to do so more efficiently. (5) Backup, redundancy, disaster recovery etc
If none of these seem more important than others, I guess you need to ask: where is the business now? Where will it need to be in <x> months? How are we getting there? What are the pain points? How can the above improve this (versus implementing new features)?
One cherry-picked example: should technical staff time be spent on improving sales? If sales are your company's limiting factor and you don't have enough salespeople, making them more efficient is really important. If you're still in a soft launch-ish place, then it's not. If you have enough salespeople but not enough leads, maybe mining your own data, or public data, could produce some.