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

Compare with Current View Page History

« Previous Version 7 Current »

No files shared here yet.


CSS Billing Working Group – 3/19/2010, 10-11:30
Invited: Rashard Bryan, Jeff Reed, Chuck King, Cynthia Finney, Chris Gresham (missed), Mark Wiklund, Anna Pope, Rob Smyser

Proposed Agenda-- Getting to Know Each Other; Goal-Setting; Fleshing out the Problems; Imagining some Solutions; Next steps.

Proposed Goals-- a working set of issues listed and solutions suggested that we can stand behind.  For early April.  That we'd be prepared to adopt if they were approved and prototyped successfully.
-- a bigger picture of desirable end-states for billing environment -- features, workflow, systems, etc.


Brainstorming sheet Rob labelled as "Best Practices"

printed estimate; signature acknowledging acceptance of future charge; collect cost object at the outset

CSS Finance smooths out the JV process when given the best effort product (JV upload spreadsheet) by a TL.

the people involved in billing are efficient and friendly and effective

Time-tracking should exist and be able to feed directly into some effort-aggregator that then computes hours to bill.

The frequency and more importantly the rhythm of issuing bills -- avoid month-end, spread transactions out -- less clumping is better, how about a common schedule?

(green star) database driven is ideal, where the tool prebuilds and automates the production of upload files and other parts of the business process. 


Proposing / Brainstorming Solutions

(white board notes; pdf attached to this page)

Filemaker DB features that we like -- creates finished JV files to email Finance automatically;  Common customer list from DataWarehouse, with cost objects; automates much of known process workflows; emailable PDF output

Do monthly billing on the 15th for the 30 days previous; avoid month-end in order to be sure of booking before the end of the month; use JV uploads accumulated for that period.
implies this group can create and adopt changes to Policies and Procedures, vetting them within the group.
Goal is consistent processes across CSS using the tools we have.  E.g., we can decide that JV Upload is is the chosen standard and then optimize for that.

A "My Account" view of activity per individual or per DLC, across all the lines of CSS business.  ← depend on CRM features of ticketing tool or whatever tool it is that chooses to own this application area.  → implies exploring SaaS or other CRM tools again.  (Jeff reed was on the CRM study team whose findings went into a report that was filed.)
- implies creating a consolidated list of what each group bills for, when and how.  That would be for our own consumption first, but would be the basis for client communication at some time.

(green star) LIST OF SERVICE OBJECTIVES WE'D LIKE TO ACHIEVE
(green star) IDEAS FOR Specific Ways We Can Get To It – reflect and expand on the list already in the powerpoint deck.

Hot Topics from opening Round-Table Sharing

(white board notes; pdf attached to this page)

Mark: Training plans to move off its old and painful process of IP Preqs and JVs after the fact to JV pre-billing.  Looking for a replacement for TEM (implementing this October) to have a field for bill-to: cost object.

Anna: wanting to get off of paper in every way to a more efficient process.  Can we take credit cards?  I get a lot of questions about that.

Chuck: database-driven billing driving process steps to which billing is almost a side-effect; weekly cycle of submit-what-we-have; huge volume of individual files that quentin accomodates as he receives them.

Jeff: his billing generation is very time-consuming; 80 lines of JVs per quarter, built from detailed time estimates filtered through Quickbooks.

Cynthia -- "smart" spreadsheet builds JV upload files from RT-to-Excel exports.  It was all Sharon Grant doing it, and she's gone; it will be someone else doing it as soon as they're on board.

Anna -- why can't I do my own JV uploads?
Everyone else -- why would I want to??

All: need a one-to-one correspondence between billable event and the payment for it.

Rashard: hasn't done a billing cycle yet, but the annual contracts are billed quarterly, while the one-off charges are accumulated and done monthly.

Issue Areas for CSS Billing

(white board notes; pdf attached to this page)

Rob's list -- do we have the right issue areas?

  1. What the DTR Statements Say
  2. Receipts and Invoice "Backup" for DLC financiers
  3. Channeling work to quentin -- what and how
  4. Who makes the JV files, and from what?
  5. More direct/instant billing, rather than accumulated JV uploads?
  6. What systems hold the billing records? (vs the work-order-related transactional systems)
  7. Converting a workorder to a bill, process of
  8. Reporting out on receivables to date
  9. Scheduling of billing events -- communal agreement on a schedule
  10. Can we have a common system that knows about the billing interactions of all of us, and who they are with, in one big database join table of client / cost object / service delivered / etc.

Team-specific

  1. how to get cost object numbers "on file" before attempting billing
  2. handling returns and refunds -- via JV (no one else does this except trainng (and perhaps PC Service)
  3. individual invoices deriving from contracts
  4. handling of tools, when they are idiosyncratic (like QBooks), leads to single points of failure
  5. Reconciling payment againts the billable entity (putting the JV number into the generating transactional system)
  6. How often to convert transactions to bills (weekly, why not?)
  7. expired cost object exceptions (quentin catching them (minimize) vs having it right before you start (maximize))
  8. what to kow about out customers and how to hold it all in common
  9. splitting charges across several accounts remains an issue
  10. reporting billables by line of business after money has flowed
  11. DLC financial contact asking for backup (i.e., not the customer but their FA or AO)
  12. IP reqs are too much work for the client to do.
  • No labels