You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 18 Next »

March 19, 2010 - -the CSS Billing Working Group met for the first time, to coalesce around a common vision for service objectives and a list of potential solutions to process inefficiencies that have plagued us for years.  This page is a home for the artifacts of their effort.

Setting the Stage...

Project Background -- see the wiki page tree of the CSS Billing Project

Powerpoint Deck summarizing draft Findings and interim Recommendations

Open Issues and Areas to Address

In what ways is Quickbooks useful to any of us? Will it ever be worth trying to introduce more licenses, or move the premiere or enterprise version, or both? 

would will we do in the absence of a powerful central tool that does it all?  Can we commission the building of DDM-Database-for-the-Rest-of-Us that integrates data about clients with data about our lines of business and a catalog of available transactions, to create a join table of itemized transactions to bill for, with PDF receipts and automatic JV file creation for 1-to-N of selected item-transactions?

Planning for 4/2/2010 Meeting – TNSC, DTR content

Establish group's sense on these areas:

1. Should we try to make available to teams the ability to bill directly for one-time charges of certain kinds, and for automatic billing of recurring charges?

  • via TNSC since it exists and people use it for non-telephone charges like ACD licenses easily enough, and it can automate repeated billings; there are technical matters that might affect our desire to go this way, or we could say "here it is and you can opt in if you want – it's all good"
    - Demo by Jana T and discussion with all

2. Optimizing the Client side of the Billing experience – improvements to make their lives easier

  • define precisely what DTR line item text should say for each of our transaction types.  
    Goals include a consistent feel, enough information to forestall some "what's this charge" questions
    We're changing PMATS to put out acceptable text automatically; need to make changes in other teams, establish a standard way of denoting ticket-based charges and relationship-based charges.
  • prepare CSS documentation describing our billing standards and practices, and what our charges look like in your DTRs, and who to contact for followup questions about a charge.  Circulate this to the AO-query community.
  • how can we get receipts emailed to everyone – who now hands out receipts and what are they like.
    • Should we promote a simple filemaker receipt/invoice engine to make emailable PDFs that go to them and to us
    • QuickbooksOnline's invoice machine on the web? – it's free
    • RT printed ticket – good enough?  Or do we want a BrioQuery file that prints just enough of the right stuff about a billable ticket in an attractive way to serve as a receipt-making engine?

Other ideas?  Identify research opportunities as action items, farm out, report back.
 

Planning for 4/16/2010 Meeting – CSS Cohesion, Transparency, Collective Effort

With Irina Vainstock facilitating,

set goals for quality billing behavior and outcomes (this was identified with somewhat different words in the notes, which i liked, what were they?)  If we're a cohesive group convened to make billing the best it can be, what would that be?

establish css operational standards to meet those goals.  Such as, set specific days in the month by which we'd have each line of business do its thing (to smooth out flow for quentin and ensure timely but consistent results for clients; decide whether to converge on JV uploads as the optimal method of transferring funds (move away from IPreqs); decide whether to offer a just-do-it billing method akin to PMATS or TNSC.

1. Schedule billing windows per line of business.  Let's hammer out a consistent production schedule – how often and precisely when in the month/quarter will we commit to processing the existing billables?  Goals include smoothing out volume of JV files sent to finance

2. do we all agree about now sending files to css-finance@mit.edu rather than qla,abdenna, and we'd populate css-finance with qla,abdenna and anyone else who was commissioned to help, and the material would not be lost if both anne and quentin became incapacitated in a freak accident?

3. Brainstorming on other process improvements we want to introduce to make our lives easier?

  • Shall we have a collective table like Anna described of who does what for whom and with what?
  • Shall there be a collaborative environment in which we put process documentation, master copies of useful tools, etc?  Shall it be a file server or a wiki or what?
  • Should we suggest that CSS-HQ or someone apply some administrative time to helping ensure that billing is flowing smoothly in every team, and pitch in or find solutions when more intervention or extra hands are in fact called for?  This would not remove operational responsibility for billing from the lines of business but rather make proper process flow an operational issue for HQ to help ensure.  _Like Joe Doherty in OIS does for TNIS projects.
  • What can we do about the SW Repair process's hand-built JVs -- how do we automate the generation of their JV files so Quentin doesn't have to type them out? -- TNSC?  

(Identify actionable items, assign and farm out, report back.)

Planning for a later Meeting – Improving our Tools

  • Can we get to a single powerful tool that creates nice JV Upload files from fields of data we have lying around the house? 
  • Is there value in a common client database lacking a CRM to hold it in.  Is this part of what quickbooks-for-everyone would get us?  Who would want to opt in to this?
  • How can we get the best parts of Chuck King's system into something we can all use?  What are the best parts anyhow?
  • Do we add consistent billing-oriented fields to RT queues that drive billing, to make producing JV files as easy as possible?  This would cover VSLS and SW Repair, maybe MDS for on-call SLAs (?)
  • Should there be a web-form invoice form that a team member can fill out and press send, and its billable details go somewhere and get turned into a JV by some process -- CSS Billing queue, for the moment in RT but destined to instantiate someplace else when we can do that?

Meeting Notes

2010-03-19

  • No labels