AI-Assisted Consulting Operations

The question is why a consulting team should spend this much attention on time tracking, ticket extraction, and ERP context. These are not glamorous systems. They are the connective tissue between work performed, work understood, and work billed.

What is at stake is not only administrative efficiency. It is the ability to see client work as it is happening, while there is still time to correct priorities, clarify scope, and prepare the client for decisions. From first principles, a consulting workflow should reduce translation. The work should move from email, ticket, meeting, ERP record, time entry, and client report with as little retyping as possible.

A recent working session showed what this can look like in practice. It began with a small NetSuite clarification and became a walkthrough of an AI-assisted operating system for daily consulting work.

Start with the record of truth

The first item was narrow: where to find the right bill payment number in NetSuite.

On the bill payment record, the check number field being discussed maps to the transaction document number, with the field ID tranid. That is not always the same thing as the physical check printing number. The actual check printing sequence is managed elsewhere, under Transactions, Management, Print Checks and Forms.

This distinction matters because automation fails when it treats similar labels as identical facts. A document number, a check number, and a printed check sequence can look interchangeable to a user. To an integration, they are different data points with different lifecycle rules.

That small clarification set the tone for the rest of the session. Good AI-assisted operations do not start with a model. They start with field definitions, source systems, and the discipline to preserve meaning as work moves across tools.

The persistent assistant as a daily control loop

The core workflow used a persistent AI assistant tab running through the day. It was not used as an occasional chat window. It functioned more like an hourly operations loop.

On each pass, the assistant pulled fresh support ticket exports and unread email across active clients. It then correlated the inputs and produced a prioritized task list. The goal was not to replace judgment. The goal was to reduce the time spent collecting fragments before judgment could begin.

The loop performed several practical jobs:

• Read new ticket extracts from the support system
• Parse unread email for client requests, follow-ups, and blockers
• Match email threads to existing tickets where possible
• Detect new work that did not yet have a ticket
• Apply client-specific aliases and known ticket overrides
• Produce a current priority list for review

This is a useful pattern. AI is strongest when it is placed between noisy inputs and a structured decision point. The consultant still chooses what matters. The system makes the queue visible.

Client workspaces reduce context leakage

Each client had its own assistant tab and working directory. That separation was operationally important.

Within each client workspace, there was an ERP list folder containing reference data such as:

• Chart of accounts
• Customers
• Vendors
• Subsidiaries
• Departments, classes, locations, and other segments
• Sandbox data
• Production data

The workspace also included a client-specific markdown file. This file captured learned context that should persist across sessions: ticket aliases, naming overrides, recurring exceptions, and known terminology differences.

This is a simple but powerful design choice. Instead of asking the assistant to infer everything from scratch, the system gives it a local memory that is scoped to the client. It avoids mixing terminology between clients. It also makes the memory inspectable. A consultant can open the markdown file and correct it.

The result is not autonomous consulting. It is assisted recall with boundaries.

Time tracking from work evidence

The next layer was time tracking. Rather than relying only on manual timers or end-of-day reconstruction, the workflow used activity evidence from the working directory.

File timestamps from both human activity and AI-generated updates were used to approximate time spent by topic. If a consultant worked on ticket notes, ERP extracts, analysis files, or client artifacts, the timestamps helped build a timeline. The assistant could then group related activity and suggest time entries.

This does not remove the need for review. Approximation is not accounting. But it changes the starting point. Instead of asking, what did I do today, the system asks, does this reconstructed work log look right?

That is a better question. It is easier to correct evidence than to recreate a day from memory.

The accordion time tracker

The time data flowed into a workspace-database-connected artifact described as an accordion time tracker. Its job was to turn scattered activity into reviewable entries.

The tracker mapped each proposed entry to:

• Client
• Ticket or workstream
• Description
• Start and end context
• Rounded duration
• Billing category
• Review status

A checkbox-based timesheet view allowed the consultant to confirm which entries were ready for final submission. From there, the entries fed the formal time-entry system.

This is the right level of automation for many professional services teams. The system drafts. The consultant approves. The official system remains the system of record.

It also creates a useful audit trail. If a client asks why time was logged to a topic, the consultant can trace the entry back to tickets, emails, files, and meeting recordings.

Meetings become structured time and context

A separate studio log database captured meeting recordings. Meeting duration was used to backfill time, rounded to the nearest quarter hour. Those entries were then routed into the same time tracker.

This matters because meetings often disappear into calendars and recordings. They are attended, discussed, and forgotten until billing time. By placing recordings into the same operational flow as tickets and files, meetings become part of the work record.

The meeting layer can also support better follow-through. A recorded client session can produce action items, open questions, time entries, and status report inputs. The same source event can serve several downstream needs, provided the workflow keeps the outputs distinct.

That distinction is important. A meeting summary is not a time entry. A time entry is not a client commitment. A client commitment is not an internal task. AI can help derive each from the same source, but the system must keep their meanings separate.

Weekly status decks from operating data

The final layer was client reporting. The workflow generated weekly client status decks as presentation files from a master prompt.

The deck process pulled from the same operational data used during the week:

• Hours by client and category
• Ticket groupings and status
• Recently completed work
• Active blockers
• Open decisions
• Contract boundary dates
• Scope indicators

This is where the system becomes more than administration. Weekly reporting is often written from memory or assembled manually from multiple systems. That creates delay and inconsistency. By generating the first draft from operating data, the consultant can spend time on interpretation rather than collection.

A good status deck should answer practical questions:

• What changed this week?
• What is blocked?
• What needs a client decision?
• What is approaching a scope or contract boundary?
• What work is planned next?

The AI-assisted workflow does not guarantee those answers are right. It gives the consultant a structured draft with links back to the work. Review remains essential.

The system pattern

The walkthrough revealed a broader pattern that other teams can adapt.

First, identify the source systems. For this workflow, the sources included email, tickets, ERP exports, file activity, recordings, and time systems.

Second, create client-scoped working memory. Keep reference data, aliases, overrides, and learned context close to the work, but separated by client.

Third, run a periodic intake loop. Pull new information on a schedule. Do not wait until the end of the day to reconstruct reality.

Fourth, convert activity into drafts. Draft task lists, time entries, meeting notes, and status reports. Do not skip human review.

Fifth, send approved outputs into systems of record. Time systems, ERP systems, and client-facing reports should receive reviewed information, not raw model output.

The design is less about one tool and more about handoffs. Each handoff should reduce copying while preserving accountability.

Risks to manage

There are clear risks.

Client data must be scoped carefully. Assistants should not blend context across clients. Access to ERP extracts and email should follow the same permissions expected in any consulting environment.

Time suggestions should be treated as drafts. File timestamps can imply work, but they cannot fully understand intent. A consultant may open a file without working on it, or work offline without leaving evidence.

ERP fields need exact definitions. The opening NetSuite example is a reminder that automation can move quickly in the wrong direction if a field label is misunderstood.

Prompts and markdown memory files should be versioned or at least inspectable. If the system learns an incorrect alias or override, the team needs a way to find and fix it.

These are manageable risks, but only if the workflow is designed as an operating system, not a shortcut.

What this changes

Ultimately, the value of this workflow is not that AI writes notes or fills timesheets. The value is that the consulting day becomes more observable. Work moves through a clearer chain: intake, interpretation, action, time capture, and client reporting.

What this means for teams is practical. Start with one client, one recurring report, or one daily time reconstruction process. Keep the sources explicit. Keep human approval in the loop. Make the memory files readable. Treat ERP field definitions as part of the design, not as afterthoughts.

The takeaway is simple: AI-assisted consulting operations work best when they are grounded in the ordinary details of the work. Tickets, emails, recordings, timestamps, ERP lists, and field IDs are not minor details. They are the structure that lets automation help without taking control away from the practitioner.