Microsoft Dynamics 365 Field Service

One of the key areas of learning curves for customers ramping up on the complex offerings of Microsoft Dynamics 365 Field Service is the vocabulary. After a bit it starts to sink in and make sense, but while you are in the learning curve the following might help. The first set are the most common items of confusion.

Bookable Resource = A person, technician, equipment, and even a room that can be scheduled. aka a Schedulable Resource.

Bookable Resource Booking = Scheduled Job

Incident Type = A set of products, services, service tasks and other details that would make up a template for a work order. aka Work Order Template.

Service Tasks = a task associated with a work order, aka a task that would most likely be completed as part of the work order.

• Work Order – The main bucket used to plan, track, and complete a set of work. Consider this the top of the tree. Could also be considered the main work that needs to be done.
• Work Order Type – Categorizes the type of service being performed, such as installation, repair, or preventive maintenance.
• Incident Type – A reusable template that defines the typical tasks, products, services, and inspections needed for a specific service scenario.
• Service Task – A specific activity or step a technician needs to complete on a work order.
• Inspection – A structured digital checklist used to capture technician observations, measurements, answers, and results. This is also called a Checklist and each item from the checklist can become a service task.
• Customer Asset – A piece of equipment or product installed at a customer location that can be serviced and tracked. Also consider that this is a product owned by the customer that you might be servicing.
• Functional Location – Represents the physical location or hierarchy where customer assets are installed, and serviced, such as a Site → Building → Floor → Room.
• Bookable Resource – A person, crew, facility, or equipment item that can be scheduled to perform work.
• Resource Requirement – Defines the skills, location, duration, and other criteria needed to complete a work order. Also considered the technician’s skills and certificates that you are tracking for each person.
• Booking – The scheduled assignment of a technician or other resource to a work order. The scheduled item, the job + Calendar, the appointment.
• Schedule Board – The visual scheduling workspace used by dispatchers to assign and manage field resources. Bookings show on the scheduled board.
• Resource Territory – Associates technicians or other resources with geographic service areas. The service territory that might be different from the sales territory. This can also be an area of complexity if your service technicians cross territories.
• Characteristic – A skill, certification, or capability associated with a resource, such as HVAC certification.
• Product – A physical item, replacement part, or material that can be used during service. Product, Part, Service – basically an item you are selling.
• Warehouse – A location where inventory and parts and products are stored.
• Inventory – The quantity and availability of products or parts at warehouses or on technician vehicles.
• Purchase Order – A record used to request products or parts from a vendor or the customer’s purchase order.
• Return Merchandise Authorization (RMA) – Tracks products or parts being returned by a customer or technician to the manufacturer.
• Agreement – Defines recurring service commitments and can automatically generate work orders on a schedule.
• Agreement Booking Setup – Defines when recurring work orders and bookings should be generated from an agreement.
• Service Level Agreement (SLA) – Defines service commitments, such as response or resolution time targets.
• Entitlement – Defines the level or amount of support a customer is eligible to receive.
• Warranty – Represents coverage that can help determine whether service, labor, or parts are covered.
• Time Entry – Records technician labor time associated with service work.
• Work Order Product – A part or material planned for or consumed on a specific work order.
• Work Order Service – A billable or non-billable service associated with a work order.
• Work Order Service Task – The individual technician task generated for a particular work order also called Service Task.
• Work Order Incident – The specific service issue or incident associated with a work order.
• Work Order Lifecycle – The progression of a job through statuses such as Open → Scheduled → Traveling → In Progress → Completed → Posted.
• Field Service Mobile App – The mobile experience technicians use to view assignments, update work, record parts/time, complete inspections, and capture service information in the field.

What my work this week across Microsoft 365 Copilot, Copilot Studio, and Copilot Cowork reinforced about practical AI governance

This week I worked across three connected areas of Microsoft AI: Copilot Studio governance, Copilot Cowork enablement, and Microsoft 365 Copilot guidance for business users and leaders. On the surface, these can look like separate conversations. In reality, they are all asking the same question: how do we help people use AI safely, confidently, and in a way that creates measurable value?

One Microsoft AI Ecosystem, Three Different Governance Conversations

My experience is that Microsoft 365 Copilot, Copilot Studio, and Copilot Cowork belong in one Microsoft AI strategy, but they should not be governed as if they are the same tool. Microsoft 365 Copilot governance starts with identity, permissions, information hygiene, responsible use, and adoption.

Copilot Studio adds the maker and solution lifecycle: environments, data-loss prevention policies, connectors, publishing, testing, approvals, monitoring, and application lifecycle management.

Copilot Cowork introduces delegated, multi-step, and recurring work. That makes clear task boundaries, human review, approved skills and plugins, consumption controls, and evidence of value even more important.

The mistake I see organizations make is treating “Copilot” as one thing. Summarizing a meeting is not the same as publishing an agent that connects to a system of record. A recurring Cowork task is different again, especially when it can continue working and consume credits. I would start with five practical questions: What experience are we enabling? What business outcome do we expect? What data is involved? What actions are allowed? Who remains accountable?

Govern by Risk and Reach, Not by a Default Template

I like using risk and reach as a practical starting point. Personal productivity scenarios usually need lighter controls and strong education. Departmental solutions need a named owner, a defined audience, approved data and connectors, support expectations, and a clear review path. Enterprise or high-impact solutions need formal security, testing, release, monitoring, continuity, and approval controls. I do not believe every organization has to force itself into exactly three zones. The model should fit the organization’s size, maturity, use cases, audience, and risk posture.

• Personal productivity: Individuals draft, summarize, research, or organize their own work using Microsoft 365 Copilot or Cowork, with the individual accountable for review.
• Business or departmental: A defined group uses a shared agent, workflow, or delegated process with a named owner, controlled access, and agreed support.
• Enterprise or high impact: An AI capability reaches a broad audience, uses sensitive information, performs consequential actions, or affects regulated and mission-critical processes.

Six Questions Every Copilot Governance Model Must Answer

1. Who owns the outcome? Every agent, workflow, and recurring task needs a business owner—not only a technical builder.
2. Who can use, build, publish, or approve it? Identity, security groups, maker roles, publishing permissions, and approval rights must be explicit.
3. What data and connections are allowed? Information access, approved knowledge sources, DLP policies, plugins, connectors, and cross-system boundaries should be designed before scale.
4. What can the AI do without another decision? Human approval is essential for privileged, irreversible, regulated, security-sensitive, or financially material actions.
5. How will quality, value, and cost be measured? Usage alone is not success. Measure outcome quality, time saved, rework, exceptions, adoption, and Copilot Credit consumption together.
6. What happens when the solution changes or fails? Define testing, promotion, monitoring, support, ownership transfer, retirement, and incident response from the beginning.

Governance and its partner FinOps

One of the biggest changes in the agentic era is that governance also has to include consumption economics. Copilot Cowork and advanced agent scenarios can move an organization from predictable per-user licensing into usage-based costs. Credit forecasting, spending limits, allocation, monitoring, and cost per outcome are now part of the solution design. I think leaders should be able to answer two questions at the same time: “Is this safe?” and “Is this worth running this way?”

Enablement Is a Governance Control

The strongest lesson for me this week was that governance and enablement cannot be separated. A policy will not solve for users who do not understand when to use Copilot Chat, Cowork, an agent, automation, or another tool. People need hands-on practice choosing work worth delegating, writing a clear brief, setting boundaries, steering the work, reviewing sources and actions, and deciding when a successful approach should become reusable guidance or a governed solution. Champions, office hours, practice, and leader role-modeling are not just change-management activities. They are part of the governance model.

This is especially important with Copilot Cowork. I am excited about the ability to delegate more advanced work and schedule recurring tasks, but delegation does not remove accountability. Scheduling does not automatically authorize unattended action. We still need people to understand the work, review the output, approve consequential steps, and capture enough evidence to improve—or stop—the workflow.

Start Small, but Design for Scale

I would not start with a massive AI center of excellence, and I would not start by restricting experimentation. Pick a small number of meaningful use cases and make the governance visible. Name the owner. Classify the risk and reach. Define the approved information and actions. Establish review points. Track quality, effort, and consumption. Then decide whether the use case should remain personal, become a shared Cowork practice, or move into Copilot Studio as a managed business solution.

The Bottom Line

My point of view is simple: AI governance should create confidence, not friction. Microsoft 365 Copilot helps people work with the information they already have. Copilot Cowork helps them delegate more complex work. Copilot Studio helps organizations build and manage agents for broader audiences and business processes. The organizations that get this right will not govern these as isolated products. They will create one adaptable operating model that connects people, data, identity, actions, lifecycle, value, and accountability—and they will keep improving it as the technology and their own maturity evolve.

Time just flies by when there is so much NEW happening!

What’s Catching My Attention in Microsoft Dynamics 365 Customer Engagement Right Now

As someone who spends a significant amount of time helping organizations transform their customer engagement capabilities, I always find it fascinating how quickly the Microsoft Dynamics 365 ecosystem continues to evolve.

This week, I have been focused on several areas that demonstrate why Dynamics 365 Customer Engagement remains such a powerful platform for sales, service, automation, and AI-driven business transformation.

One of the most exciting aspects of Dynamics 365 is its ability to bring customer information together into a unified experience. Rather than forcing users to navigate multiple systems, organizations can provide sales, service, and leadership teams with a consolidated view of accounts, contacts, opportunities, activities, and customer history.

1. Making Customer Data More Actionable

I’ve been exploring how organizations can move beyond simply storing customer data and instead use that information to drive better decisions, stronger customer relationships, and more proactive engagement strategies. We are talking bringing data to where you are working AND writing data from where you are working. Microsoft Teams, Microsoft 365 Copilot and Microsoft Outlook!!

2. Leveraging Embedded AI and Copilot Experiences

Artificial intelligence continues to be one of the most exciting developments within the Dynamics 365 platform. The ability for sellers to receive intelligent recommendations, summarize information, draft communications, and surface relationship insights is changing personal productivity AND we all know this, but what people don’t realize is how these changes impact “TRADITIONAL FORM BASED” interactions. My assistants (The Copilots, my personal AI Agents, Cowork) double my work impact.

3. Designing CRM Around Business Roles

A common challenge I see is attempting to make every user work the same way. Do you use Outlook the same as your peers? Your manager? Your assistants? Successful Dynamics 365 implementations recognize that executives, sales leaders, account managers, service representatives, and operations teams all consume information differently.

4. Balancing Configuration with Long-Term Scalability

One of the most rewarding parts of solution architecture is finding the balance between solving immediate business needs and maintaining a scalable platform for the future.

This week included discussions around configuration decisions, system walkthroughs, training approaches, and MVP-focused business scenarios designed to help organizations maximize value while avoiding unnecessary complexity. Those themes were reflected in a recent Dynamics 365 configuration and training working session focused on solution capabilities, configuration choices, and business process alignment.

Final Thoughts

What continues to impress me about Microsoft Dynamics 365 Customer Engagement is that it is no longer just a CRM platform.

#Microsoft #Dynamics365 #CustomerEngagement #CRM #PowerPlatform #Copilot #CustomerExperience #DigitalTransformation #AI #Sales #CustomerService #BusinessApplications

Every day brings a new article, webinar, product announcement, or opinion piece about agents, copilots, automation, and the future of work. The challenge isn’t finding information. The challenge is separating vision from practical execution.

That’s why Microsoft Frontier Transformation Week caught my attention.

What stands out isn’t the focus on AI itself. It’s the focus on moving from ideas to implementation. Microsoft positions the event around helping organizations understand how to put AI into practice through strategy, demonstrations, customer examples, and technical guidance. [microsoft.com]

As someone who spends most of my time helping organizations adopt Microsoft technologies, I am far less interested in hearing that AI is transformative than I am in seeing how organizations are actually using it to deliver measurable outcomes.

What I Hope to Gain

The organizations I work with are largely asking the same questions:

• Where should we start?
• How do we move beyond basic Copilot usage?
• What governance is required?
• When do agents make sense?
• How do we scale successfully?
• How do we avoid creating a collection of disconnected AI experiments?

These are implementation questions, not technology questions.

Based on the agenda, Frontier Transformation Week appears designed to address exactly these types of challenges through role-based content, demonstrations, customer stories, and practical guidance. [microsoft.com]

What Attendees Should Expect

If you’re expecting four days of product marketing, this probably isn’t the right way to think about the event.

Instead, I expect attendees to come away with a much clearer understanding of:

How Microsoft sees the evolution from Copilots to Agents

Many organizations are still figuring out Microsoft 365 Copilot. At the same time, Microsoft is rapidly expanding its focus on agents, autonomous processes, and agentic systems of work.

Frontier Transformation Week includes content focused on AI agents, Agent Builder, Copilot Studio, and Microsoft’s broader AI platform strategy.

For many organizations, understanding how these pieces fit together is becoming increasingly important.

Real-world examples from customers

One of the most valuable aspects of any Microsoft event is seeing what other organizations have already learned.

According to Microsoft, the event includes customer stories, demonstrations, live Q&A sessions, and practical examples rather than simply discussing concepts at a high level. [microsoft.com],

Often the most valuable takeaway is not a new feature. It’s hearing how someone else solved a problem you’re currently facing.

Practical guidance for builders and practitioners

Microsoft specifically calls out technical depth and implementation guidance for practitioners and developers. Topics include deploying, optimizing, and extending AI solutions within Microsoft’s ecosystem. [microsoft.com]

For those building solutions on Microsoft 365, Power Platform, Azure AI, or Copilot Studio, this should provide useful context about where Microsoft is investing and where customers are finding success.

If your organization is still asking whether AI matters…….

The more relevant question today is how to adopt AI responsibly, securely, and in a way that creates measurable business value.

What makes Frontier Transformation Week interesting is that it appears focused on answering that question.

Learn more: Microsoft Frontier Transformation Week [microsoft.com]

Did you know? There is a Microsoft 365 Copilot hierarchy and a bit of a difference between what falls under Microsoft 365 Copilot vs. Microsoft 365 Copilot Chat.

• Microsoft 365 Copilot
  • Copilot Chat
    • Web grounding
    • Work grounding
    • Agents
    • Prompt-based reasoning
  • Word (plus Copilot in Word)
  • Excel (plus Copilot in Excel)
  • PowerPoint (Plus PowerPoint Agent and Copilot in Power Point)
  • Outlook (Plus Copilot in Outlook)
  • Teams (Plus Copilot in Teams)
  • OneNote / Notebook (Plus Copilot Notebook)
  • SharePoint (plus SharePoint Agents and Copilot in SharePoint)
  • and more ..

Getting some wow out of working with “AI”

As we dive into the world of Microsoft Power Platform Coded Apps, we solve the “I want it to look different” requests.

Given we have a well written set of requirements that includes clarity, testable acceptance criteria, process understanding and alignment, we can create an app that meets those needs. Included in these needs might be the variables such as use existing Power Platform Tables, add the customers colors and branding and perhaps something creative such as choose a logo and name for the new application.

So will the depth of a well configured Microsoft Dynamics 365 AI Business Application start to fade?

No, Microsoft has many teams of developers, adding incredible feature sets and embedding multiple layers of AI into the Microsoft Dynamics 365 Customer Engagement suite. Consider this approach when it comes to the various levels of growth with AI..

Analyze → Predict → Assist → Act → Autonomously Execute

Level	Description	Dynamics 365 CE Examples
1. Descriptive AI	Surfaces information and summarizes data.	Customer summaries, case summaries, account insights, meeting summaries. [learn.microsoft.com]
2. Predictive AI	Uses historical data to forecast outcomes and recommend actions.	Lead scoring, opportunity insights, forecasting, predictive analytics, next-best actions. [learn.microsoft.com],
3. Generative AI (Copilot)	Creates content and assists users using natural language.	Email drafts, case responses, record summaries, knowledge article generation, customer journey content creation. [learn.microsoft.com], [microsoft.com]
4. Agentic AI	AI agents perform multi-step tasks with human oversight.	Sales qualification agents, service agents, agent feed, Copilot Studio agents working within Dynamics 365 processes. [learn.microsoft.com],
5. Autonomous AI	Agents execute business processes with minimal human intervention while following governance controls.	Automated customer engagement, proactive outreach, intelligent routing, end-to-end workflow execution across Dataverse, Power Platform, and Dynamics 365. [microsoft.com],

How this maps to the Dynamics 365 CE roadmap

For most organizations using Dynamics 365 CE today, the maturity path looks like:

1. Insights → See what’s happening.
2. Predictions → Anticipate what will happen.
3. Copilot Assistance → Help users work faster.
4. Agents → Complete tasks for users.
5. Autonomous Processes → Run portions of the business process automatically.

Where are you along this path??

Do you have the right team?

As you grow into the world of “AI” Enabled and tight cost constraints have you considered if you really have the right team for your needs?

“Business Think” has never been the top skill of your heavy technical developer teams and yet, “Business Think” is critical in this age of communicating with all of the newer technical options. Microsoft provides a huge number of choices in their AI Business Application Suite which means that you want to make sure that you have the team that can support you with those choices.

Pick Senior Resources, who have experience delivering business applications and who can support you in how to think about the choices.

Include Business Analysts who know the applications so that Fit/Gap is part of every conversation.

Keep an Open Mind to all that is not only new, but also on the horizon. The horizon tends to be next month, not next year.

Define the Business Goal so that all can contribute to the potential options for delivery.

Understand that maintainability continues to be a variable.

Writing Effective Business Requirements

Product Ownership and Technical Translations

A Feature (Business Requirement) should focus on the business outcome and value, not the technical solution. The goal is for it to clearly describe the business need, the user role, and the expected benefit using a format such as “As a Sales Representative, I need a consistent lead qualification process so that only sales-ready leads become opportunities and forecast accuracy improves.”

The Feature should include business scenarios and measurable acceptance criteria that define what success looks like. For example, in Dynamics 365 Sales, a qualified lead must result in the creation of an Account, Contact, and Opportunity, while non-qualified leads remain in the lead management process.

A Technical Product Backlog Item (User Story) defines how the approved Feature will be delivered through configuration, customization, extension, security, automation, reporting, or AI capabilities. For a lead qualification Feature, technical user stories may include configuring either the Sales Qualification Agent for AI-assisted qualification or a traditional Business Process Flow-based qualification process.

Each technical user story must trace directly to the originating Feature, contain detailed technical acceptance criteria, and be broken into implementation tasks.

Business Requirement / Feature Standards

A good Business Requirement (Feature) should:

• Follow the format:
  • As a [Business Role] (clearly define the expected access, and/or role-based entitlements for this requirement)
  • I need [Capability] (what are you trying to do?, scenario)
  • So that [Business Value] (Always provide the goal!)
• Focus on the desired business outcome.
• Avoid technical design decisions or details
• Include one or more business scenarios.
• Define clear, measurable, and testable acceptance criteria.
• Align to User Acceptance Test scripts
• Be clearly understandable by business stakeholders, product owners, testers, and the delivery team.

Example Business Requirement (Feature)

Feature

As a Sales Representative, I need a consistent lead qualification process so that only sales-ready leads become opportunities and forecast accuracy improves.

Business Scenario

• Leads are generated from events, marketing campaigns, referrals, and web forms.
• Sales representatives review lead information.
• Qualified leads are converted into an Prospective Accounts, Contact, and Opportunities.
• The organization may choose:
  • AI-assisted qualification using the Sales Qualification Agent, or
  • Traditional manual qualification using standard Dynamics 365 Sales capabilities.

Business Acceptance Criteria

• Given I am a sales person and a lead exists, when qualification criteria are met, then the lead can be manually or automatically qualified.
• Given a qualified lead, when qualification is completed, then a prospective Account, Contact, and Opportunity are created or an Account and Contact are created (Opportunity is optional)
• Given that the account and/or contact already exists when qualifying the lead then a new account and/or contact will NOT be created but the new opportunity will be associated to the existing account and/or contact
• Given a lead does not meet qualification criteria, when reviewed, then it remains unqualified.
• Given a completed qualification, when management reviews the lead, then qualification history is available for reporting and audit purposes.

Technical Product Backlog Item (User Story) Standards

Technical Product Backlog Items (PBIs) or Technical User Stories should:

• Support an approved Business Requirement (Feature).
• Describe how the solution will be configured or built.
• Include configuration decisions, security, automation, integration, reporting, or AI capabilities.
• Do not introduce NEW business requirements.
• Be traceable to the originating Feature.
• Include detailed, testable technical acceptance criteria.

Technical Product Backlog Item (User Story)

Parent Feature

As a Sales Representative, I need a consistent lead qualification process so that only sales-ready leads become opportunities and forecast is accurate or accuracy improves.

Technical Product Backlog Item / User Story

As a sales representative I need the sales app to be configured to support manual lead qualification capabilities leveraging the new Sales Qualification AI-assisted agent so that I can leverage the most efficient process for qualifying my leads and so that I can create more than one opportunity from any given lead and so that I can see a summary of my lead qualifying efforts.

Option 1: Sales Qualification Agent Configuration

Configuration Scope

• Enable Sales Qualification Agent.
• Configure qualification criteria.
• Configure lead scoring thresholds.
• Enable AI-generated lead research and recommendations.
• Configure seller review and approval process.
• Configure security roles.
• Configure qualification reporting and audit tracking.

Technical Acceptance Criteria

• Given the Sales Qualification Agent is enabled, when a new lead is created, then the agent evaluates the lead using configured qualification criteria.
• Given qualifying information is available, when analysis is completed, then recommendations are presented to the salesperson.
• Given qualification thresholds are met, when seller approval is provided, then the lead can be qualified.
• Given a lead is qualified, when qualification is executed, then an Account, Contact, and Opportunity are automatically created.
• Given qualification activities occur, when reports are reviewed, then agent actions are available for auditing and analysis.

Option 2: Traditional Qualification Process Configuration

Configuration Scope

• Configure Lead table fields.
• Configure Business Process Flow.
• Configure qualification checklist.
• Configure business rules and validations.
• Configure lead scoring fields.
• Configure security model.
• Configure reporting and dashboards.

Technical Acceptance Criteria

• Given a sales representative opens a lead, when required fields are completed, then the lead can advance through the qualification process.
• Given qualification criteria are met, when the user selects Qualify Lead, then an Account, Contact, and Opportunity are created.
• Given required data is missing, when qualification is attempted, then the process is blocked and validation messages are displayed.
• Given qualification is completed, when records are created, then data mapping follows approved business requirements.
• Given security restrictions exist, when an unauthorized user attempts qualification, then access is denied.

Agile Requirement Hierarchy example

Recommended Traceability Model

• Epic → Lead Management and Qualification
  • Feature (Business Requirement) → Consistent Lead Qualification Process
    • Technical Product Backlog Items (User Stories) → Configure Sales Qualification Agent
      → Configure Traditional Lead Qualification Process
      → Configure Lead Scoring
      → Configure Security Roles
      → Configure Data Mapping
      → Configure Reporting and Analytics
      • Tasks → Configuration, Testing, Documentation, Deployment, and Training activities required to complete each Technical Product Backlog Item.

This approach provides clear business-to-technical traceability while aligning with common Agile and Scrum practices of Epic → Feature → User Story → Task.

M365 Copilot Has made huge leaps in its ability to generate great pictures and given that the world is very visual, and a lot of people appreciate a good diagram. I thought I would share a few.

Microsoft Power Platform and Dynamics 365 CE PowerApps

We try out AI, we hear about AI, we layer on AI tools, but what needs to be considered is how the whole infrastructure aligns with the business application feature sets such as the features in Microsoft Dynamics 365 Customer Engagement (Configured for your industry) layered on top of common features such as Sales, Customer Service, Contact Center, Field Service and more..

For the last few years Microsoft has been quietly (or perhaps not so quietly) adding Copilots to every feature within every business application and within the development tools that feed those applications. The last I counted there were at least 150 different Copilots and they add the steroids to the features (sometimes more, sometimes less). Sure, we could search on activity history, but now we have a Copilot that summarizes that history for us and that is just one example of many.

It is not getting people to “Add Data” into their CRM system, it is providing the ability for people to get data out when they need it and from where they need it from.

The Visual Reporting (Power BI) and the Dynamics Views that tie easily to Excel (for people who just do not want to give up Excel), the Dashboards that pull from the Dataverse and sometimes from many other sources of data and the power of predictive data.

For those living on the bleeding edge, Copilots are just part of their every day productivity and now they are embracing all of the new Agents and Agents that talk to other Agents. The Sales Research Agent in Microsoft Dynamics 365 is just “there” and part of your Spring menu. As a development team, we don’t have to work magic to get multiple vendor offerings aligned to provide you with Agent power and clients don’t have to juggle multiple vendor pricing and as a +1 Copilot Studio allows us to quickly configure agents based on your needs.

Sales Research running in Microsoft Dynamics 365 Sales with the Microsoft Teams Embedded open.

The Sales Research Agent Menu Item in Microsoft Dynamics 365 Sales

As much as we all love to hate Microsoft when any gap is stepped into. They are pushing the envelope hard with all of their development and product teams. The key is to work with teams who know the FIT/GAPs and although GAPS disappear as fast as the technology changes knowing and listening to the key variables is a critical way to avoid frustrations.